🥇Canary Deployment i Kubernetes #2: Argo Rollouts

Vi vil bruke en k8s-nativ distribusjonskontroller, Argo Rollouts, og GitlabCI for å implementere Canary-deploy i Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artiklene i denne serien

Canary Deployment i Kubernetes #1: Gitlab CI
(Denne artikkelen)
Canary-distribusjon ved hjelp av Istio
Canary-distribusjon ved hjelp av Jenkins-X Istio Flagger

Canary Deployment

Vi håper du har lest den første delen, hvor vi kort forklarte hva Canary-distribusjoner er. Vi viste også hvordan man kan implementere dette ved å bruke standardressurser fra Kubernetes.

Argo Rollouts

Argo Rollouts er en Kubernetes-nativ distribusjonskontroller. Den gir CRD (Custom Resource Definition) for Kubernetes. Med den kan vi bruke en ny enhet: Rollout, som administrerer blue-green og canary-distribusjoner med ulike konfigurasjonsalternativer.

Argo Rollouts-kontrolleren, som bruker den tilpassede ressursen Rollout, gjør det mulig å bruke ekstra distribusjonsstrategier som blue-green og canary for Kubernetes. Ressursen Rollout tilbyr funksjonalitet lik Deployment, bare med ekstra distribusjonsstrategier.
Ressurs Deployments har to strategier for distribusjon: RollingUpdate og Recreate. Selv om disse strategiene passer for de fleste tilfeller, brukes ekstra strategier som blue-green eller canary for distribusjoner til servere i svært stor skala, som ikke finnes i distribusjonskontrolleren. For å bruke disse strategiene i Kubernetes måtte brukerne skrive skript over sine distribusjoner. Argo Rollouts-kontrolleren gir disse strategiene i form av enkle deklarative konfigurerbare parametere.
https://argoproj.github.io/argo-rollouts

Det finnes også Argo CI, som gir et brukervennlig webgrensesnitt for å brukes sammen med Rollouts; vi vil se på det i neste artikkel.

Installer 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 vårt infrastrukturnotat (se nedenfor) har vi allerede lagt til install.yaml som i/k8s/argo-rollouts/install.yaml. Dermed vil GitlabCI installere det i klyngen.

På klientsiden (kubectl-plugin)

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

Eksempelapplikasjonen

Det er god praksis å ha separate repositoryer for applikasjonskoden og for infrastrukturen.

Repository for applikasjonen

Kim Wuestkamp / k8s-deployment-example-app

Dette er et veldig enkelt API bygget med Python+Flask som returnerer et svar i JSON-format. Vi vil bygge pakken ved hjelp av GitlabCI og laste opp resultatet til Gitlab Registry. I registeret har vi to forskjellige versjoner av utgivelsene:

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

Den eneste forskjellen mellom dem er JSON-filen som returneres. Vi bruker denne applikasjonen for en maksimal enkel visualisering av hvilken versjon vi kommuniserer med.

Infrastrukturrepository

I denne repositoriet vil vi bruke GitlabCI for distribusjon til Kubernetes, .gitlab-ci.yml ser slik ut:

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 å kjøre det selv trenger du et klynge, du kan bruke Gcloud:

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

Du må gjøre en fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure og opprette en variabel KUBECONFIG i GitlabCI, som vil inneholde konfigurasjonen for tilgang kubectl til klyngen din.

Her Du kan lese om hvordan du får legitimasjon for klyngen (Gcloud).

Infrastruktur-YAML

Inne i infrastruktur-repositoriet har vi 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 gjenopptas ved å kjøre `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # to minutter

Rollout fungerer på samme måte som Deployment. Hvis vi ikke angir oppdateringsstrategi (som canary her) vil det oppføre seg som en standard rolling-update Deployment.

Vi definerer to trinn i yaml for canary distribusjon:

10% av trafikken på canary (vent på manuell OK)
50% av trafikken på canary (vent 2 minutter før vi går videre til 100%)

Utføring av initial deployment

Etter den første distribusjonen vil ressursene våre se slik ut:

Og vi får svar kun fra den første versjonen av applikasjonen:

Utfører Canary Deployment

Trinn 1: 10% trafikk

For å starte canary distribusjonen må vi bare endre versjonen av bildet, som vi vanligvis gjør med distribusjoner:

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 pusher endringene, så Gitlab CI gjør distribusjonen og vi ser endringene:

Nå, hvis vi henvender oss til tjenesten:

Flott! Vi er i midten av vår canary-distribusjon. Vi kan se fremdriften ved å kjøre:

kubectl argo rollouts get rollout rollout-canary

Trinn 2: 50% trafikk:

Nå går vi videre til neste trinn: omdirigere 50% av trafikken. Vi har satt opp dette trinnet til å bli startet manuelt:

kubectl argo rollouts promote rollout-canary # fortsett til trinn 2

Og applikasjonen vår returnerte 50% svar fra de nye versjonene:

Og oversikt over rollout:

Flott.

Trinn 3: 100% trafikk:

Vi har satt opp slik at etter 2 minutter avsluttes trinnet med 50% automatisk og trinnet med 100% startes:

Og utskriften av applikasjonen:

Og oversikt over rollout:

Canary distribusjon fullført.

Flere eksempler med Argo Rollouts

Her er flere eksempler, som hvordan man kan sette opp forhåndsvisning av miljøer og sammenligninger basert på canary:

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

Video om Argo Rollouts og Argo CI

Jeg anbefaler virkelig denne videoen, den viser hvordan Argo Rollouts og Argo CI fungerer sammen:

Resultat

Jeg liker veldig godt ideen om å bruke CRD-er som styrer opprettingen av flere typer deployments eller replicasets, omdirigerer trafikk osv. Jobben med dem går smertefritt. Jeg vil gjerne teste integrasjonen med Argo CI.

Men det ser ut til at en stor fusjon mellom Argo CI og Flux CI nærmer seg, så jeg kan vente til den nye versjonen kommer: Argo Flux.

Har du hatt erfaring med Argo Rollouts eller Argo CI?

Les også andre artikler i bloggen vår:

Kilde: habr.com