🥇Canary-distribusjon i Kubernetes #2: Argo-utrulling

Vi vil bruke k8s-native Argo Rollouts-distribusjonskontrolleren og GitlabCI for å kjøre Canary-distribusjoner til Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artikler i denne serien

Canary Deployment i Kubernetes #1: Gitlab CI
(Denne artikkelen)
Canary Deployment med Istio
Canary Deployment med Jenkins-X Istio Flagger

Kanariøyeutplassering

Vi håper du leser første del, hvor vi kort forklarte hva Canary Deployments er. Vi viste også hvordan du implementerer det ved å bruke standard Kubernetes-ressurser.

Argo-utrullinger

Argo Rollouts er en innebygd Kubernetes-distribusjonskontroller. Den gir en CRD (Custom Resource Definition) for Kubernetes. Takket være det kan vi bruke en ny enhet: Rollout, som administrerer blågrønne og kanarifugl-utplasseringer med ulike konfigurasjonsalternativer.

Argo Rollouts-kontroller brukt av en tilpasset ressurs Rollout, Tillater ytterligere distribusjonsstrategier som blågrønn og kanarifugl for Kubernetes. Ressurs Rollout gir funksjonalitet tilsvarende Deployment, bare med ytterligere distribusjonsstrategier.
ressurs Deployments har to strategier for distribusjon: RollingUpdate и Recreate. Selv om disse strategiene er egnet for de fleste tilfeller, for distribusjon til servere i svært stor skala, brukes tilleggsstrategier, for eksempel blågrønn eller kanarifugl, som ikke er tilgjengelig i distribusjonskontrolleren. For å bruke disse strategiene i Kubernetes, måtte brukere skrive skript på toppen av sine distribusjoner. Argo Rollouts-kontrolleren viser disse strategiene som enkle, deklarative, konfigurerbare parametere.
https://argoproj.github.io/argo-rollouts

Det er også Argo CI, som gir et praktisk webgrensesnitt for bruk med utrullinger, det skal vi ta en titt på i neste artikkel.

Installere Argo Rollouts

Serverside

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

I vår infrastruktur turnip (se nedenfor) har vi allerede lagt til install.yaml som i/k8s/argo-rollouts/install.yaml. På denne måten vil GitlabCI installere den i klyngen.

Klientside (kubectl-plugin)

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

Eksempelapplikasjon

Det er god praksis å ha separate repositories for applikasjonskode og infrastruktur.

Repository for applikasjonen

Kim Wuestkamp/k8s-deployment-example-app

Dette er en veldig enkel Python+Flask API som returnerer et svar som JSON. Vi vil bygge pakken ved å bruke GitlabCI og sende resultatet til Gitlab-registeret. I registret har vi to forskjellige utgivelsesversjoner:

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 å visualisere så enkelt som mulig hvilken versjon vi kommuniserer med.

Infrastrukturlager

I dette depotet 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 en 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å gaffel https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure og lag 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 en klynge (Gcloud).

Infrastruktur Yaml

Inne i infrastrukturlageret har vi tjenesten:

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 can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout fungerer på samme måte som Deployment. Hvis vi ikke angir en oppdateringsstrategi (som Canary her) vil den oppføre seg som standard rullende oppdateringsimplementering.

Vi definerer to trinn i yaml for kanari-utplassering:

10 % av trafikken til Kanariøyene (vent på manuell OK)
50 % trafikk til Kanariøyene (vent 2 minutter og fortsett til 100 %)

Utfører innledende distribusjon

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

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

Utfører Canary Deployment

Trinn 1: 10 % trafikk

For å starte en kanari-distribusjon, trenger vi bare å endre bildeversjonen 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 presser endringer, så Gitlab CI distribuerer og vi ser endringene:

Nå hvis vi får tilgang til tjenesten:

Flott! Vi er midt i vår kanari-utplassering. Vi kan se fremgangen ved å kjøre:

kubectl argo rollouts get rollout rollout-canary

Trinn 2: 50 % trafikk:

La oss nå gå videre til neste trinn: omdirigere 50 % av trafikken. Vi konfigurerte dette trinnet til å kjøres manuelt:

kubectl argo rollouts promote rollout-canary # continue to step 2

Og applikasjonen vår returnerte 50 % av svarene fra nye versjoner:

Og utrullingsgjennomgang:

Herlig.

Trinn 3: 100 % trafikk:

Vi setter det opp slik at etter 2 minutter avsluttes 50 %-trinnet automatisk og 100 %-trinnet starter:

Og applikasjonsutgangen:

Og utrullingsgjennomgang:

Kanariøyeutplasseringen er fullført.

Flere eksempler med Argo Rollouts

Det er flere eksempler her, for eksempel hvordan du setter opp miljøforhåndsvisninger og sammenligninger basert på kanarifugl:

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:

Total

Jeg liker virkelig ideen om å bruke CRD-er som administrerer opprettelsen av flere typer distribusjoner eller replikasett, omdirigere trafikk, etc. Arbeidet med dem går greit. Deretter vil jeg teste integrasjonen med Argo CI.

Imidlertid ser det ut til at det kommer en stor sammenslåing av Argo CI og Flux CI, så jeg kan vente til den nye utgivelsen kommer ut: Argo Flux.

Har du hatt noen erfaring med Argo Rollouts eller Argo CI?

Les også andre artikler på bloggen vår:

Kilde: www.habr.com

Canary-distribusjon i Kubernetes #2: Argo-utrullinger