🥇Canary Deployment in Kubernetes #2: Argo Rollouts

We zullen de k8s-native Argo Rollouts deployment controller en GitlabCI gebruiken om een Canary deployment in Kubernetes te starten.

https://unsplash.com/photos/V41PulGL1z0

Artikelen in deze cyclus

Canary Deployment in Kubernetes #1: Gitlab CI
(Dit artikel)
Canary Deployment met Istio
Canary Deployment met Jenkins-X Istio Flagger

Canary Deployment

We hopen dat u heeft gelezen eerste deel, waar we kort uitlegden wat Canary Deployments zijn. We toonden ook hoe het te implementeren met standaard Kubernetes-resources.

Argo Rollouts

Argo Rollouts is een Kubernetes-native deployment controller. Het biedt CRD (Custom Resource Definition) voor Kubernetes. Hierdoor kunnen we een nieuwe entiteit gebruiken: Rollout, die blue-green en canary deployments beheert met verschillende configuratie-opties.

De Argo Rollouts controller, die wordt gebruikt door de aangepaste resource Rollout, maakt het mogelijk om extra deploymentstrategieën te gebruiken, zoals blue-green en canary voor Kubernetes. De resource Rollout biedt functionaliteit die gelijkwaardig is aan Deployment, maar met extra deploymentstrategieën.
Hulpbron Deployments heeft twee strategieën voor deployment: RollingUpdate en Recreate. Hoewel deze strategieën geschikt zijn voor de meeste gevallen, worden voor deployments naar servers op een zeer grote schaal extra strategieën, zoals blue-green of canary, gebruikt die niet in de Deployment controller aanwezig zijn. Om deze strategieën in Kubernetes te gebruiken, moesten gebruikers scripts bovenop hun Deployments schrijven. De Argo Rollouts controller biedt deze strategieën als simples declaratieve configureerbare parameters.
https://argoproj.github.io/argo-rollouts

Er is ook Argo CI, dat een gebruiksvriendelijke webinterface biedt voor gebruik met Rollouts; we zullen erop ingaan in het volgende artikel.

Installatie van Argo Rollouts

Aan de serverzijde

kubectl create namespace argo-rollouts; kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

In onze infrastructuur repository (zie hieronder) hebben we al install.yaml toegevoegd als i/k8s/argo-rollouts/install.yaml. Hierdoor zal GitlabCI het in de cluster installeren.

Aan de klantzijde (kubectl-plugin)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Voorbeeldapplicatie

Een goede praktijk is om aparte repositories te hebben voor de applicatiecode en voor de infrastructuur.

Repository voor de applicatie

Kim Wuestkamp / k8s-deployment-example-app

Dit is een zeer eenvoudige API in Python+Flask, die een JSON-respons retourneert. We zullen een pakket samenstellen met behulp van GitlabCI en het resultaat naar de Gitlab Registry pushen. In de registry hebben we twee verschillende versies van de releases:

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

Het enige verschil tussen hen is het geretourneerde JSON-bestand. We gebruiken deze applicatie voor een maximaal eenvoudige visualisatie van welke versie we communiceren.

Infrastructuurrepository

In deze repository gaan we GitlabCI gebruiken voor de deployment naar Kubernetes, .gitlab-ci.yml ziet er als volgt uit:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

Om het zelf te starten heeft u een cluster nodig, u kunt Gcloud gebruiken:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

U moet een fork maken https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure en een variabele aanmaken KUBECONFIG in GitlabCI, die de configuratie voor toegang bevat kubectl tot uw cluster.

Hier je kunt lezen hoe je de inloggegevens voor de cluster (Gcloud) krijgt.

Infrastructuur Yaml

Binnen de infrastructuurrepository hebben we service:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

en rollout.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts kunnen handmatig worden hervat door `kubectl argo rollouts promote ROLLOUT` te draaien
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # twee minuten

Rollout werkt op dezelfde manier als de Deployment. Als we geen update-strategie opgeven (zoals canary hier), zal het zich gedragen als de standaard rolling-update Deployment.

We definiëren twee stappen in yaml voor canary deployment:

10% verkeer naar canary (wacht op handmatige OK)
50% verkeer naar canary (wacht 2 minuten en ga dan door naar 100%)

Uitvoeren van de initiële deployment

Na de initiële deployment zullen onze middelen er als volgt uitzien:

En we krijgen alleen een reactie van de eerste versie van de applicatie:

We voeren de Canary Deployment uit

Stap 1: 10% verkeer

Om de canary deployment te starten, hoeven we alleen de versie van de afbeelding te wijzigen zoals we normaal doen met deployments:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

En we pushen de wijzigingen, zodat Gitlab CI de deployment doet en we de wijzigingen zien:

Nu als we de service aanroepen:

Geweldig! We zijn halverwege onze canary deployment. We kunnen de voortgang zien door het volgende uit te voeren:

kubectl argo rollouts get rollout rollout-canary

Stap 2: 50% verkeer:

Laten we nu doorgaan naar de volgende stap: het omleiden van 50% van het verkeer. We hebben dit zo ingesteld dat deze stap handmatig wordt uitgevoerd:

kubectl argo rollouts promote rollout-canary # ga door naar stap 2

En onze applicatie heeft 50% van de antwoorden van de nieuwe versies teruggegeven:

En een overzicht van de rollout:

Prachtig.

Stap 3: 100% verkeer:

We configured it so that after 2 minutes, the step with 50% automatically completes and the step with 100% starts:

And the application output:

En een overzicht van de rollout:

Canary deployment completed.

More examples with Argo Rollouts

Here are more examples, such as how to set up environment previews and comparisons based on canary:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Video about Argo Rollouts and Argo CI

I really recommend this video; it shows how Argo Rollouts and Argo CI work together:

Conclusie

I really like the idea of using CRDs that manage the creation of additional types of deployments or replicasets, redirect traffic, etc. Working with them is smooth. Next, I would like to test integration with Argo CI.

However, it seems that a major merge of Argo CI and Flux CI is coming, so I might wait for the new release: Argo Flux.

Have you had experience with Argo Rollouts or Argo CI?

Lees ook andere artikelen op onze blog:

Bron: habr.com