Add Argo and k8s questions
Also updated Datadog questions.
This commit is contained in:
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
|
||||
|
||||
: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
|
||||
|
||||
|
@ -5,7 +5,8 @@
|
||||
- [ArgoCD 101](#argocd-101)
|
||||
- [ArgoCD Secrets](#argocd-secrets)
|
||||
- [ArgoCD Helm](#argocd-helm)
|
||||
- [Argo Questions](#argo-questions)
|
||||
- [Argo Rollouts](#argo-rollouts)
|
||||
- [ArgoCD Questions](#argocd-questions)
|
||||
- [ArgoCD 101](#argocd-101-1)
|
||||
- [Practical ArgoCD 101](#practical-argocd-101)
|
||||
- [CLI](#cli)
|
||||
@ -14,6 +15,9 @@
|
||||
- [ArgoCD Application Health](#argocd-application-health)
|
||||
- [ArgoCD Syncs](#argocd-syncs)
|
||||
- [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
|
||||
|
||||
@ -37,7 +41,14 @@
|
||||
|--------|--------|------|----|----|
|
||||
| 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
|
||||
|
||||
@ -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.
|
||||
</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)
|
||||
- [Questions](#questions)
|
||||
- [Basics](#basics)
|
||||
- [Datadog Agent](#datadog-agent)
|
||||
- [Datadog Integrations](#datadog-integrations)
|
||||
|
||||
## Questions
|
||||
|
||||
@ -41,8 +43,37 @@ Basically any device or location that has Datadog agent installed and running on
|
||||
|
||||
<details>
|
||||
<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>
|
||||
|
||||
<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>
|
@ -17,6 +17,7 @@ What's your goal?
|
||||
- [ReplicaSet](#replicaset)
|
||||
- [Labels and Selectors](#labels-and-selectors)
|
||||
- [Scheduler](#scheduler)
|
||||
- [Kustomize](#kustomize)
|
||||
- [Kubernetes Questions](#kubernetes-questions)
|
||||
- [Kubernetes 101](#kubernetes-101)
|
||||
- [Cluster and Architecture](#cluster-and-architecture)
|
||||
@ -64,6 +65,8 @@ What's your goal?
|
||||
- [Resource Limits](#resource-limits)
|
||||
- [Resources Limits - Commands](#resources-limits---commands)
|
||||
- [Monitoring](#monitoring)
|
||||
- [Kustomize](#kustomize-1)
|
||||
- [Deployment Strategies](#deployment-strategies)
|
||||
- [Scenarios](#scenarios)
|
||||
|
||||
## 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)
|
||||
|
||||
### 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 101
|
||||
@ -3006,6 +3015,103 @@ TODO: add more monitoring solutions
|
||||
|
||||
</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
|
||||
|
||||
|
@ -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