🥇Canary-distribution i Kubernetes #2: Argo-utrullningar

Vi kommer att använda den k8s-baserade Argo Rollouts distributionskontroller och GitlabCI för att köra Canary-distributioner till Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artiklar i denna serie

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

Kanarieöarnas utbyggnad

Vi hoppas att du läser första delen, där vi kort förklarade vad Canary Deployments är. Vi visade också hur man implementerar det med standard Kubernetes-resurser.

Argo utrullningar

Argo Rollouts är en inbyggd Kubernetes-distributionskontroller. Den tillhandahåller en CRD (Custom Resource Definition) för Kubernetes. Tack vare det kan vi använda en ny enhet: Rollout, som hanterar blågröna och kanariefågelinstallationer med olika konfigurationsalternativ.

Argo Rollouts-kontroller som används av en anpassad resurs Rollout, Tillåter ytterligare distributionsstrategier som blågrön och kanariefågel för Kubernetes. Resurs Rollout ger funktionalitet motsvarande Deployment, endast med ytterligare distributionsstrategier.
resurs Deployments har två strategier för implementering: RollingUpdate и Recreate. Även om dessa strategier är lämpliga för de flesta fall används ytterligare strategier för distribution till servrar i mycket stor skala, som blågrön eller kanariefågel, som inte är tillgängliga i distributionskontrollern. För att använda dessa strategier i Kubernetes, var användarna tvungna att skriva skript ovanpå sina implementeringar. Argo Rollouts Controller exponerar dessa strategier som enkla, deklarativa, konfigurerbara parametrar.
https://argoproj.github.io/argo-rollouts

Det finns också Argo CI, som ger ett bekvämt webbgränssnitt för användning med utrullningar, det ska vi ta en titt på i nästa artikel.

Installera Argo Rollouts

Serversidan

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 nedan) har vi redan lagt till install.yaml som i/k8s/argo-rollouts/install.yaml. På så sätt kommer GitlabCI att installera det i klustret.

Klientsida (kubectl-plugin)

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

Exempelapplikation

Det är god praxis att ha separata arkiv för programkod och infrastruktur.

Repository för applikationen

Kim Wuestkamp/k8s-deployment-example-app

Detta är ett mycket enkelt Python+Flask API som returnerar ett svar som JSON. Vi kommer att bygga paketet med GitlabCI och skicka resultatet till Gitlab-registret. I registret har vi två olika versioner:

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

Den enda skillnaden mellan dem är JSON-filen som returneras. Vi använder denna applikation för att så enkelt som möjligt visualisera vilken version vi kommunicerar med.

Infrastrukturförråd

I det här arkivet kommer vi att använda GitlabCI för distribution till Kubernetes, .gitlab-ci.yml ser ut så här:

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

För att köra det själv behöver du ett kluster, du kan använda 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åste gaffel https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure och skapa en variabel KUBECONFIG i GitlabCI, som kommer att innehålla konfigurationen för åtkomst kubectl till ditt kluster.

Här Du kan läsa om hur du får inloggningsuppgifter för ett kluster (Gcloud).

Infrastruktur Yaml

Inuti infrastrukturförvaret har vi tjänsten:

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

och 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 fungerar på samma sätt som Deployment. Om vi inte ställer in en uppdateringsstrategi (som Canary här) kommer den att bete sig som standard rullande uppdatering Deployment.

Vi definierar två steg i yaml för kanariefågel:

10 % av trafiken till kanarieöarna (vänta på manuellt OK)
50 % trafik till kanarieöarna (vänta 2 minuter och fortsätt sedan till 100 %)

Utför inledande driftsättning

Efter den första implementeringen kommer våra resurser att se ut så här:

Och vi får ett svar endast från den första versionen av applikationen:

Utför Canary Deployment

Steg 1: 10 % trafik

För att starta en kanariefågel-distribution behöver vi bara ändra bildversionen som vi vanligtvis gör med implementeringar:

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

Och vi driver förändringar, så Gitlab CI distribuerar och vi ser förändringarna:

Om vi nu kommer åt tjänsten:

Bra! Vi är mitt i vår kanariefågeluppläggning. Vi kan se framstegen genom att köra:

kubectl argo rollouts get rollout rollout-canary

Steg 2: 50 % trafik:

Låt oss nu gå vidare till nästa steg: omdirigera 50 % av trafiken. Vi konfigurerade detta steg för att köras manuellt:

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

Och vår applikation returnerade 50 % av svaren från nya versioner:

Och lanseringsrecension:

Underbar.

Steg 3: 100 % trafik:

Vi ställer in det så att efter 2 minuter avslutas 50%-steget automatiskt och 100%-steget börjar:

Och applikationsutgången:

Och lanseringsrecension:

Kanarie-utbyggnaden är klar.

Fler exempel med Argo Rollouts

Det finns fler exempel här, till exempel hur man ställer in miljöförhandsvisningar och jämförelser baserade på kanariefågel:

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

Video om Argo Rollouts och Argo CI

Jag rekommenderar verkligen den här videon, den visar hur Argo Rollouts och Argo CI fungerar tillsammans:

Totalt

Jag gillar verkligen idén att använda CRD:er som hanterar skapandet av ytterligare typer av distributioner eller repliker, omdirigering av trafik, etc. Arbetet med dem går smidigt. Härnäst skulle jag vilja testa integrationen med Argo CI.

Det verkar dock vara en stor sammanslagning av Argo CI och Flux CI på väg, så jag kan vänta tills den nya releasen kommer ut: Argo Flux.

Har du någon erfarenhet av Argo Rollouts eller Argo CI?

Läs även andra artiklar på vår blogg:

Källa: will.com

Canary-distribution i Kubernetes #2: Argo-utrullningar