Add Argo and k8s questions
Also updated Datadog questions.
This commit is contained in:
abregman
parent
cbdcfa3e4f
commit
c469c84a26
@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
:information_source: This repo contains questions and exercises on various technical topics, sometimes related to DevOps and SRE
|
:information_source: This repo contains questions and exercises on various technical topics, sometimes related to DevOps and SRE
|
||||||
|
|
||||||
:bar_chart: There are currently **2466** exercises and questions
|
:bar_chart: There are currently **2487** exercises and questions
|
||||||
|
|
||||||
:warning: You can use these for preparing for an interview but most of the questions and exercises don't represent an actual interview. Please read [FAQ page](faq.md) for more details
|
:warning: You can use these for preparing for an interview but most of the questions and exercises don't represent an actual interview. Please read [FAQ page](faq.md) for more details
|
||||||
|
|
||||||
|
|||||||
@ -5,7 +5,8 @@
|
|||||||
- [ArgoCD 101](#argocd-101)
|
- [ArgoCD 101](#argocd-101)
|
||||||
- [ArgoCD Secrets](#argocd-secrets)
|
- [ArgoCD Secrets](#argocd-secrets)
|
||||||
- [ArgoCD Helm](#argocd-helm)
|
- [ArgoCD Helm](#argocd-helm)
|
||||||
- [Argo Questions](#argo-questions)
|
- [Argo Rollouts](#argo-rollouts)
|
||||||
|
- [ArgoCD Questions](#argocd-questions)
|
||||||
- [ArgoCD 101](#argocd-101-1)
|
- [ArgoCD 101](#argocd-101-1)
|
||||||
- [Practical ArgoCD 101](#practical-argocd-101)
|
- [Practical ArgoCD 101](#practical-argocd-101)
|
||||||
- [CLI](#cli)
|
- [CLI](#cli)
|
||||||
@ -14,6 +15,9 @@
|
|||||||
- [ArgoCD Application Health](#argocd-application-health)
|
- [ArgoCD Application Health](#argocd-application-health)
|
||||||
- [ArgoCD Syncs](#argocd-syncs)
|
- [ArgoCD Syncs](#argocd-syncs)
|
||||||
- [ArgoCD and Helm](#argocd-and-helm)
|
- [ArgoCD and Helm](#argocd-and-helm)
|
||||||
|
- [Argo Rollouts Questions](#argo-rollouts-questions)
|
||||||
|
- [Argo Rollouts 101](#argo-rollouts-101)
|
||||||
|
- [Argo Rollouts Commands](#argo-rollouts-commands)
|
||||||
|
|
||||||
## ArgoCD Exercises
|
## ArgoCD Exercises
|
||||||
|
|
||||||
@ -37,7 +41,14 @@
|
|||||||
|--------|--------|------|----|----|
|
|--------|--------|------|----|----|
|
||||||
| Helm ArgoCD App | Secrets | [Exercise](exercises/argocd_helm_app/exercise.md) | [Solution](exercises/argocd_helm_app/solution.md)
|
| Helm ArgoCD App | Secrets | [Exercise](exercises/argocd_helm_app/exercise.md) | [Solution](exercises/argocd_helm_app/solution.md)
|
||||||
|
|
||||||
## Argo Questions
|
### Argo Rollouts
|
||||||
|
|
||||||
|
|Name|Topic|Objective & Instructions|Solution|Comments|
|
||||||
|
|--------|--------|------|----|----|
|
||||||
|
| Blue/Green Rollout | Rollouts | [Exercise](exercises/blue_green_rollout/exercise.md) | [Solution](exercises/blue_green_rollout/solution.md)
|
||||||
|
| Canary Rollout | Rollouts | [Exercise](exercises/canary_rollout/exercise.md) | [Solution](exercises/canary_rollout/solution.md)
|
||||||
|
|
||||||
|
## ArgoCD Questions
|
||||||
|
|
||||||
### ArgoCD 101
|
### ArgoCD 101
|
||||||
|
|
||||||
@ -341,3 +352,61 @@ ArgoCD is able to track packaged Helm chart in a sense where it will monitor for
|
|||||||
|
|
||||||
True. Trying to execute commands like `helm ls` will fail because helm metadata doesn't exist anymore and the application is tracked as ArgoCD app.
|
True. Trying to execute commands like `helm ls` will fail because helm metadata doesn't exist anymore and the application is tracked as ArgoCD app.
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
|
## Argo Rollouts Questions
|
||||||
|
|
||||||
|
### Argo Rollouts 101
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What is Argo Rollouts?</summary><br><b>
|
||||||
|
|
||||||
|
A controller for Kubernetes to perform application deployments using different strategies like Blue/Green deployments, Canary deployments, etc.
|
||||||
|
|
||||||
|
In addition, it supports A/B tests, automatic rollbacks and integrated metric analysis.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What happens when you rollout a new version of your app with argo rollouts?</summary><br><b>
|
||||||
|
|
||||||
|
- Argo Rollouts creates a new replicaset (that is the new app version)
|
||||||
|
- Old version is still alive
|
||||||
|
- ArgoCD marks the app as out-ofsync
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
### Argo Rollouts Commands
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How to list rollouts?</summary><br><b>
|
||||||
|
|
||||||
|
`kubectl argo rollouts list rollouts`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How to list the rollouts of a given application?</summary><br><b>
|
||||||
|
|
||||||
|
`kubectl argo rollouts get rollout SOME-APP`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How to check the status of a rollout?</summary><br><b>
|
||||||
|
|
||||||
|
`kubectl argo rollouts status SOME-APP`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How to rollout a new version (with new container tag)?</summary><br><b>
|
||||||
|
|
||||||
|
`kubectl argo rollouts set image SOME-APP web-app=some/registry/and/image:v2.0`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How to manually promote to new app version?</summary><br><b>
|
||||||
|
|
||||||
|
`kubectl argo rollouts promote SOME-APP`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How do you monitor a rollout?</summary><br><b>
|
||||||
|
|
||||||
|
`kubectl argo rollouts get rollout SOME-APP --watch`
|
||||||
|
</b></details>
|
||||||
21
topics/argo/exercises/blue_green_rollout/exercise.md
Normal file
21
topics/argo/exercises/blue_green_rollout/exercise.md
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
# Argo Rollouts - Blue/Green
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. Argo Rollouts CLI
|
||||||
|
3. Deployed app in specific version
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Install Argo Rollouts controller
|
||||||
|
2. Write a rollout manifest that use blue/green deployment and apply it
|
||||||
|
1. Set it to 3 replicas
|
||||||
|
2. Disable auto-promotions
|
||||||
|
3. Check the rollout list
|
||||||
|
4. Rollout a new version of your app in any way you prefer
|
||||||
|
1. Check the status of the rollout
|
||||||
|
|
||||||
|
## Solutions
|
||||||
|
|
||||||
|
Click [here](solution.md) to view the solution.
|
||||||
58
topics/argo/exercises/blue_green_rollout/solution.md
Normal file
58
topics/argo/exercises/blue_green_rollout/solution.md
Normal file
@ -0,0 +1,58 @@
|
|||||||
|
# Argo Rollouts - Blue/Green
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. Argo Rollouts CLI
|
||||||
|
3. Deployed app in specific version
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Install Argo Rollouts controller
|
||||||
|
2. Write a rollout manifest that use blue/green deployment and apply it
|
||||||
|
1. Set it to 3 replicas
|
||||||
|
2. Disable auto-promotions
|
||||||
|
3. Check the rollout list
|
||||||
|
4. Rollout a new version of your app in any way you prefer
|
||||||
|
1. Check the status of the rollout
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
Installation:
|
||||||
|
|
||||||
|
1. `kubectl create namespace argo-rollouts`
|
||||||
|
1. `kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml`
|
||||||
|
|
||||||
|
2. Rollout resource:
|
||||||
|
|
||||||
|
```
|
||||||
|
---
|
||||||
|
apiVersion: argoproj.io/v1alpha1
|
||||||
|
kind: Rollout
|
||||||
|
metadata:
|
||||||
|
name: some-app
|
||||||
|
spec:
|
||||||
|
replicas: 3
|
||||||
|
strategy:
|
||||||
|
blueGreen:
|
||||||
|
autoPromotionEnabled: false
|
||||||
|
selector:
|
||||||
|
matchLabels:
|
||||||
|
app: some-web-app
|
||||||
|
template:
|
||||||
|
metadata:
|
||||||
|
labels:
|
||||||
|
app: some-web-app
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: web-app
|
||||||
|
image: some/registry/and/image:v1.0
|
||||||
|
ports:
|
||||||
|
- name: http
|
||||||
|
containerPort: 8080
|
||||||
|
protocol: TCP
|
||||||
|
```
|
||||||
|
|
||||||
|
3. `kubectl argo rollouts list rollouts`
|
||||||
|
4. `kubectl argo rollouts set image SOME-APP web-app=some/registry/and/image:v2.0`
|
||||||
|
1. `kubectl argo rollouts get rollout some-app --watch`
|
||||||
21
topics/argo/exercises/canary_rollout/exercise.md
Normal file
21
topics/argo/exercises/canary_rollout/exercise.md
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
# Argo Rollouts - Canary
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. Argo Rollouts CLI
|
||||||
|
3. Deployed app in a specific version
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Install Argo Rollouts controller
|
||||||
|
2. Write a rollout manifest that use canary rollout strategy and apply it
|
||||||
|
1. Set it to 3 replicas
|
||||||
|
2. Disable auto-promotions
|
||||||
|
3. Check the rollout list
|
||||||
|
4. Rollout a new version of your app in any way you prefer
|
||||||
|
1. Check the status of the rollout
|
||||||
|
|
||||||
|
## Solutions
|
||||||
|
|
||||||
|
Click [here](solution.md) to view the solution.
|
||||||
70
topics/argo/exercises/canary_rollout/solution.md
Normal file
70
topics/argo/exercises/canary_rollout/solution.md
Normal file
@ -0,0 +1,70 @@
|
|||||||
|
# Argo Rollouts - Canary
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. Argo Rollouts CLI
|
||||||
|
3. Deployed app in a specific version
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Install Argo Rollouts controller
|
||||||
|
2. Write a rollout manifest that use canary rollout strategy and apply it
|
||||||
|
1. Set it to 6 replicas
|
||||||
|
2. Disable auto-promotions
|
||||||
|
3. Check the rollout list
|
||||||
|
4. Rollout a new version of your app in any way you prefer
|
||||||
|
1. Check the status of the rollout
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
Installation:
|
||||||
|
|
||||||
|
1. `kubectl create namespace argo-rollouts`
|
||||||
|
1. `kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml`
|
||||||
|
|
||||||
|
2. Rollout resource:
|
||||||
|
|
||||||
|
```
|
||||||
|
---
|
||||||
|
apiVersion: argoproj.io/v1alpha1
|
||||||
|
kind: Rollout
|
||||||
|
metadata:
|
||||||
|
name: some-app
|
||||||
|
spec:
|
||||||
|
replicas: 6
|
||||||
|
strategy:
|
||||||
|
canary:
|
||||||
|
stableService: k8s-service-stable
|
||||||
|
canaryService: k8s-service-canary
|
||||||
|
trafficRouting:
|
||||||
|
ambassador:
|
||||||
|
mappings:
|
||||||
|
- k8s-mapping
|
||||||
|
steps:
|
||||||
|
- setWeight: 30
|
||||||
|
- pause: {}
|
||||||
|
- setWeight: 60
|
||||||
|
- pause: {}
|
||||||
|
- setWeight: 100
|
||||||
|
- pause: {}
|
||||||
|
selector:
|
||||||
|
matchLabels:
|
||||||
|
app: some-web-app
|
||||||
|
template:
|
||||||
|
metadata:
|
||||||
|
labels:
|
||||||
|
app: some-web-app
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: web-app
|
||||||
|
image: some/registry/and/image:v1.0
|
||||||
|
ports:
|
||||||
|
- name: http
|
||||||
|
containerPort: 8080
|
||||||
|
protocol: TCP
|
||||||
|
```
|
||||||
|
|
||||||
|
3. `kubectl argo rollouts list rollouts`
|
||||||
|
4. `kubectl argo rollouts set image SOME-APP web-app=some/registry/and/image:v2.0`
|
||||||
|
1. `kubectl argo rollouts get rollout some-app --watch`
|
||||||
@ -3,6 +3,8 @@
|
|||||||
- [DataDog](#datadog)
|
- [DataDog](#datadog)
|
||||||
- [Questions](#questions)
|
- [Questions](#questions)
|
||||||
- [Basics](#basics)
|
- [Basics](#basics)
|
||||||
|
- [Datadog Agent](#datadog-agent)
|
||||||
|
- [Datadog Integrations](#datadog-integrations)
|
||||||
|
|
||||||
## Questions
|
## Questions
|
||||||
|
|
||||||
@ -41,8 +43,37 @@ Basically any device or location that has Datadog agent installed and running on
|
|||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>What is a Datadog agent?</summary><br><b>
|
<summary>What is a Datadog agent?</summary><br><b>
|
||||||
|
|
||||||
|
A software runs on a Datadog host. Its purpose is to collect data from the host and sent it to Datadog (data like metrics, logs, etc.)
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>What are Datadog agents?</summary><br><b>
|
<summary>What are Datadog tags?</summary><br><b>
|
||||||
|
|
||||||
|
Datadog tags are used to mark different information with unique properties. For example, you might want to tag some data with "environment: production" while tagging information from staging or dev environment with "environment: staging".
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
## Datadog Agent
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What are the component of a Datadog agent?</summary><br><b>
|
||||||
|
|
||||||
|
* Collector: its role is to collect data from the host on which it's installed. The default period of time as of today is every 15 seconds.
|
||||||
|
* Forwarder: responsible for sending the data to Datadog over HTTPS
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
## Datadog Integrations
|
||||||
|
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What can you tell about Datadog integrations?</summary><br><b>
|
||||||
|
|
||||||
|
- Datadog has many supported integrations with different services, platforms, etc.
|
||||||
|
- Each integration includes information on how to apply it, how to use it and what configuration options it supports
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What opening some of the integrations windows/pages, there is a ection called "Monitors". What can be found there?</summary><br><b>
|
||||||
|
|
||||||
|
Usually you can find there some anomaly types that Datadog suggests to monitor and track.
|
||||||
</b></details>
|
</b></details>
|
||||||
@ -17,6 +17,7 @@ What's your goal?
|
|||||||
- [ReplicaSet](#replicaset)
|
- [ReplicaSet](#replicaset)
|
||||||
- [Labels and Selectors](#labels-and-selectors)
|
- [Labels and Selectors](#labels-and-selectors)
|
||||||
- [Scheduler](#scheduler)
|
- [Scheduler](#scheduler)
|
||||||
|
- [Kustomize](#kustomize)
|
||||||
- [Kubernetes Questions](#kubernetes-questions)
|
- [Kubernetes Questions](#kubernetes-questions)
|
||||||
- [Kubernetes 101](#kubernetes-101)
|
- [Kubernetes 101](#kubernetes-101)
|
||||||
- [Cluster and Architecture](#cluster-and-architecture)
|
- [Cluster and Architecture](#cluster-and-architecture)
|
||||||
@ -64,6 +65,8 @@ What's your goal?
|
|||||||
- [Resource Limits](#resource-limits)
|
- [Resource Limits](#resource-limits)
|
||||||
- [Resources Limits - Commands](#resources-limits---commands)
|
- [Resources Limits - Commands](#resources-limits---commands)
|
||||||
- [Monitoring](#monitoring)
|
- [Monitoring](#monitoring)
|
||||||
|
- [Kustomize](#kustomize-1)
|
||||||
|
- [Deployment Strategies](#deployment-strategies)
|
||||||
- [Scenarios](#scenarios)
|
- [Scenarios](#scenarios)
|
||||||
|
|
||||||
## Kubernetes Exercises
|
## Kubernetes Exercises
|
||||||
@ -103,6 +106,12 @@ What's your goal?
|
|||||||
|--------|--------|------|----|----|
|
|--------|--------|------|----|----|
|
||||||
| Taints 101 | Taints | [Exercise](exercises/taints_101/exercise.md) | [Solution](exercises/taints_101/solution.md)
|
| Taints 101 | Taints | [Exercise](exercises/taints_101/exercise.md) | [Solution](exercises/taints_101/solution.md)
|
||||||
|
|
||||||
|
### Kustomize
|
||||||
|
|
||||||
|
|Name|Topic|Objective & Instructions|Solution|Comments|
|
||||||
|
|--------|--------|------|----|----|
|
||||||
|
| common labels | Kustomize | [Exercise](exercises/kustomize_common_labels/exercise.md) | [Solution](exercises/kustomize_common_labels/solution.md)
|
||||||
|
|
||||||
## Kubernetes Questions
|
## Kubernetes Questions
|
||||||
|
|
||||||
### Kubernetes 101
|
### Kubernetes 101
|
||||||
@ -3006,6 +3015,103 @@ TODO: add more monitoring solutions
|
|||||||
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
|
### Kustomize
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What is Kustomize?</summary><br><b>
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Explain the need for Kustomize by describing actual use cases</summary><br><b>
|
||||||
|
|
||||||
|
* You have an helm chart of an application used by multiple teams in your organization and there is a requirement to add annotation to the app specifying the name of the of team owning the app
|
||||||
|
* Without Kustomize you would need to copy the files (chart template in this case) and modify it to include the specific annotations we need
|
||||||
|
* With Kustomize you don't need to copy the entire repo or files
|
||||||
|
* You are asked to apply a change/patch to some app without modifying the original files of the app
|
||||||
|
* With Kustomize you can define kustomization.yml file that defines these customizations so you don't need to touch the original app files
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Describe in high-level how Kustomize works</summary><br><b>
|
||||||
|
|
||||||
|
1. You add kustomization.yml file in the folder of the app you would like to customize.
|
||||||
|
1. You define the customizations you would like to perform
|
||||||
|
2. You run `kustomize build APP_PATH` where your kustomization.yml also resides
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
### Deployment Strategies
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What rollout/deployment strategies are you familiar with?</summary><br><b>
|
||||||
|
|
||||||
|
* Blue/Green Deployments: You deploy a new version of your app, while old version still running, and you start redirecting traffic to the new version of the app
|
||||||
|
* Canary Deployments: You deploy a new version of your app and start redirecting **portion** of your users/traffic to the new version. So you the migration to the new version is much more gradual
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Explain Blue/Green deployments/rollouts in detail</summary><br><b>
|
||||||
|
|
||||||
|
Blue/Green deployment steps:
|
||||||
|
|
||||||
|
1. Traffic coming from users through a load balancer to the application which is currently version 1
|
||||||
|
|
||||||
|
Users -> Load Balancer -> App Version 1
|
||||||
|
|
||||||
|
2. A new application version 2 is deployed (while version 1 still running)
|
||||||
|
|
||||||
|
Users -> Load Balancer -> App Version 1
|
||||||
|
App Version 2
|
||||||
|
|
||||||
|
3. If version 2 runs properly, traffic switched to it instead of version 1
|
||||||
|
|
||||||
|
User -> Load Balancer App version 1
|
||||||
|
-> App Version 2
|
||||||
|
|
||||||
|
4. Whether old version is removed or keep running but without users being redirected to it, is based on team or company decision
|
||||||
|
|
||||||
|
Pros:
|
||||||
|
* We can rollback/switch quickly to previous version at any point
|
||||||
|
Cons:
|
||||||
|
* In case of an issue with new version, ALL users are affected (instead of small portion/percentage)
|
||||||
|
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Explain Canary deployments/rollouts in detail</summary><br><b>
|
||||||
|
|
||||||
|
Canary deployment steps:
|
||||||
|
|
||||||
|
1. Traffic coming from users through a load balancer to the application which is currently version 1
|
||||||
|
|
||||||
|
Users -> Load Balancer -> App Version 1
|
||||||
|
|
||||||
|
2. A new application version 2 is deployed (while version 1 still running) and part of the traffic is redirected to the new version
|
||||||
|
|
||||||
|
Users -> Load Balancer ->(95% of the traffic) App Version 1
|
||||||
|
->(5% of the traffic) App Version 2
|
||||||
|
|
||||||
|
3. If the new version (2) runs well, more traffic is redirected to it
|
||||||
|
|
||||||
|
Users -> Load Balancer ->(70% of the traffic) App Version 1
|
||||||
|
->(30% of the traffic) App Version 2
|
||||||
|
|
||||||
|
3. If everything runs well, at some point all traffic is redirected to the new version
|
||||||
|
|
||||||
|
Users -> Load Balancer -> App Version 2
|
||||||
|
|
||||||
|
|
||||||
|
Pros:
|
||||||
|
* If there is any issue with the new deployed app version, only some portion of the users affected, instead of all of them
|
||||||
|
Cons:
|
||||||
|
* Testing of new version is neccesrialy in the production environment (as the user traffic is exists only there)
|
||||||
|
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What ways are you familiar with to implement deployment strategies (like canary, blue/green) in Kubernetes?</summary><br><b>
|
||||||
|
|
||||||
|
There are multiple ways. One of them is Argo Rollouts.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
### Scenarios
|
### Scenarios
|
||||||
|
|
||||||
|
|||||||
@ -0,0 +1,17 @@
|
|||||||
|
# Kustomize - Common Labels
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. Kustomize binary installed
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
In the current directory there is an app composed of a Deployment and Service.
|
||||||
|
|
||||||
|
1. Write a kustomization.yml file that will add to both the Service and Deployment the label "team-name: aces"
|
||||||
|
2. Execute a kustomize command that will generate the customized k8s files with the label appended
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
Click [here](solution.md) to view the solution
|
||||||
@ -0,0 +1,31 @@
|
|||||||
|
# Kustomize - Common Labels
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. Kustomize binary installed
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
In the current directory there is an app composed of a Deployment and Service.
|
||||||
|
|
||||||
|
1. Write a kustomization.yml file that will add to both the Service and Deployment the label "team-name: aces"
|
||||||
|
2. Execute a kustomize command that will generate the customized k8s files with the label appended
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
1. Add the following to kustomization.yml in someApp directory:
|
||||||
|
|
||||||
|
```
|
||||||
|
apiVersion: kustomize.config.k8s.io/v1beta1
|
||||||
|
kind: Kustomization
|
||||||
|
|
||||||
|
commonLabels:
|
||||||
|
team-name: aces
|
||||||
|
|
||||||
|
resources:
|
||||||
|
- service.yml
|
||||||
|
- deployment.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
2. Run `kustomize build someApp`
|
||||||
@ -0,0 +1,21 @@
|
|||||||
|
apiVersion: apps/v1
|
||||||
|
kind: Deployment
|
||||||
|
metadata:
|
||||||
|
name: nginx-deployment
|
||||||
|
labels:
|
||||||
|
app: nginx
|
||||||
|
spec:
|
||||||
|
replicas: 3
|
||||||
|
selector:
|
||||||
|
matchLabels:
|
||||||
|
app: nginx
|
||||||
|
template:
|
||||||
|
metadata:
|
||||||
|
labels:
|
||||||
|
app: nginx
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: nginx
|
||||||
|
image: nginx:1.14.2
|
||||||
|
ports:
|
||||||
|
- containerPort: 80
|
||||||
@ -0,0 +1,11 @@
|
|||||||
|
apiVersion: v1
|
||||||
|
kind: Service
|
||||||
|
metadata:
|
||||||
|
name: my-service
|
||||||
|
spec:
|
||||||
|
selector:
|
||||||
|
app: nginx
|
||||||
|
ports:
|
||||||
|
- protocol: TCP
|
||||||
|
port: 80
|
||||||
|
targetPort: 9376
|
||||||
Loading…
Reference in New Issue
Block a user