🥇Canary Deployment i Kubernetes #2: Argo Rollouts

Vi vil bruge den k8s-native deploymentscontroller Argo Rollouts og GitlabCI til at køre Canary-deployments i Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artikler i denne cyklus

Canary Deployment i Kubernetes #1: Gitlab CI
(Denne artikel)
Canary Deployment ved hjælp af Istio
Canary Deployment ved hjælp af Jenkins-X Istio Flagger

Canary Deployment

Vi håber, at du har læst første del, hvor vi kort forklarede, hvad Canary Deployments er. Vi viste også, hvordan man implementerer det ved hjælp af standard Kubernetes-ressourcer.

Argo Rollouts

Argo Rollouts er en Kubernetes-native deploymentscontroller. Den tilbyder CRD (Custom Resource Definition) for Kubernetes. Dette gør, at vi kan bruge en ny enhed: Rollout, som administrerer blue-green og canary deployments med forskellige konfigurationsmuligheder.

Kontrolleren Argo Rollouts, der anvender den tilpassede ressource Rollout, giver mulighed for at implementere yderligere deploymentsstrategier såsom blue-green og canary for Kubernetes. Ressourcen Rollout tilbyder funktionalitet, der er lig med Deployment, kun med ekstra deploymentsstrategier.
Platformen Deployments har to strategier til implementering: RollingUpdate og Recreate. Selvom disse strategier passer til de fleste scenarier, anvendes der yderligere strategier som blue-green eller canary til implementering på servere i meget stor skala, som ikke findes i Deployment-controlleren. For at bruge disse strategier i Kubernetes var brugerne nødt til at skrive scripts oven på deres Deployments. Kontrolleren Argo Rollouts tilbyder disse strategier som enkle deklarative konfigurerbare parametre.
https://argoproj.github.io/argo-rollouts

Der findes også Argo CI, som tilbyder et brugervenligt webinterface til brug sammen med Rollouts, vi vil se nærmere på det i den næste artikel.

Installation af Argo Rollouts

På serversiden

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

I vores infrastrukturrepo (se nedenfor) har vi allerede tilføjet install.yaml som i/k8s/argo-rollouts/install.yaml. Således vil GitlabCI installere det i klyngen.

På klientsiden (kubectl plugin)

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

Eksempelapplikation

En god praksis er at have adskilte repositories til applikationskoden og til infrastrukturen.

Repository til applikationen

Kim Wuestkamp / k8s-deployment-example-app

Dette er en meget simpel API skrevet i Python+Flask, der returnerer et svar i JSON-format. Vi vil bygge pakken ved hjælp af GitlabCI og uploade resultatet til Gitlab Registry. I registreringen har vi to forskellige versioner af udgivelserne:

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

Den eneste forskel mellem dem er den returnerede JSON-fil. Vi bruger denne applikation til at visualisere, hvilken version vi interagerer med, på den nemmeste måde.

Infrastruktur repository

I dette repository vil vi bruge GitlabCI til deployment til Kubernetes, .gitlab-ci.yml ser således ud:

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

For at køre det selv skal du bruge et cluster, du kan bruge Gcloud:

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

Du skal lave en fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure og oprette en variabel KUBECONFIG i GitlabCI, som vil indeholde konfigurationen til adgang kubectl til dit cluster.

Her man kan læse om, hvordan man får legitimationsoplysninger til klyngen (Gcloud).

Infrastruktur Yaml

Inden for infrastrukturrepositoryet har vi en 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

og 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 kan manuelt genoptages ved at køre `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # to minutter

Rollout fungerer på samme måde som Deployment. Hvis vi ikke angiver en opdateringsstrategi (som canary her), vil den opføre sig som en standard rolling-update Deployment.

Vi definerer to trin i yaml til canary deployment:

10% trafik til canary (vent på manuel OK)
50% trafik til canary (vent 2 minutter og fortsæt til 100%)

Udførelse af den indledende deployment

Efter den indledende deployment vil vores ressourcer se således ud:

Og vi modtager kun svar fra den første version af applikationen:

Udfører Canary Deployment

Trin 1: 10% trafik

For at starte canary deployment skal vi blot ændre versionen af billedet, som vi normalt gør med deployment:

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
...

Og vi push'er ændringerne, så Gitlab CI udfører deployment, og vi ser ændringerne:

Nu, hvis vi henvender os til servicen:

Fantastisk! Vi er midt i vores canary deployment. Vi kan se fremskridtene ved at køre:

kubectl argo rollouts get rollout rollout-canary

Trin 2: 50% trafik:

Nu går vi videre til næste trin: omdirigering af 50% trafik. Vi har indstillet dette trin til at blive udført manuelt:

kubectl argo rollouts promote rollout-canary # fortsæt til trin 2

Og vores applikation har returneret 50% svar fra de nye versioner:

Og oversigt over rollout:

Fremragende.

Trin 3: 100% trafik:

Vi har indstillet det, så trinnet med 50% automatisk afsluttes efter 2 minutter, og trinnet med 100% starter.

Og applikationsoutput:

Og oversigt over rollout:

Canary-deployeringen er afsluttet.

Flere eksempler med Argo Rollouts

Her er flere eksempler, for eksempel hvordan man konfigurerer miljøforhåndsvisninger og sammenligninger baseret på canary:

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

Video om Argo Rollouts og Argo CI

Jeg anbefaler virkelig denne video, der viser, hvordan Argo Rollouts og Argo CI arbejder sammen:

Resultat

Jeg er virkelig glad for ideen om at bruge CRD'er, der styrer oprettelsen af ekstra typer deployment eller replicasets, omdirigerer trafik osv. Arbejdet med dem forløber glat. Herefter vil jeg gerne teste integrationen med Argo CI.

Men åbenbart er der en stor fusion af Argo CI og Flux CI på vej, så jeg kunne vente på, at den nye version kommer ud: Argo Flux.

Har du haft erfaring med Argo Rollouts eller Argo CI?

Læs også andre artikler på vores blog:

Kilde: habr.com