🥇Canary-implementering i Kubernetes #2: Argo-udrulning

Vi vil bruge den k8s-native Argo Rollouts implementeringscontroller og GitlabCI til at køre Canary-implementeringer til Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artikler i denne serie

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

Kanariske indsættelse

Vi håber du læser med 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 udrulninger

Argo Rollouts er en indbygget Kubernetes-implementeringscontroller. Det giver en CRD (Custom Resource Definition) til Kubernetes. Takket være det kan vi bruge en ny enhed: Rollout, som administrerer blågrønne og kanariske installationer med forskellige konfigurationsmuligheder.

Argo Rollouts-controller brugt af en tilpasset ressource Rollout, Giver mulighed for yderligere implementeringsstrategier såsom blå-grøn og kanariefugle for Kubernetes. Ressource Rollout giver tilsvarende funktionalitet Deployment, kun med yderligere implementeringsstrategier.
ressource Deployments har to strategier til implementering: RollingUpdate и Recreate. Selvom disse strategier er velegnede til de fleste tilfælde, bruges der yderligere strategier til udrulning til servere i meget stor skala, såsom blå-grøn eller kanarisk, som ikke er tilgængelige i implementeringscontrolleren. For at bruge disse strategier i Kubernetes skulle brugerne skrive scripts oven på deres implementeringer. Argo Rollouts-controlleren afslører disse strategier som enkle, deklarative, konfigurerbare parametre.
https://argoproj.github.io/argo-rollouts

Der er også Argo CI, som giver en praktisk webgrænseflade til brug med udrulninger, det tager vi et kig på i næste artikel.

Installation af Argo Rollouts

Server side

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

I vores infrastruktur turnip (se nedenfor) har vi allerede tilføjet install.yaml som i/k8s/argo-rollouts/install.yaml. På denne måde vil GitlabCI installere det i klyngen.

Klientside (kubectl-plugin)

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

Eksempel applikation

Det er god praksis at have separate arkiver til applikationskode og infrastruktur.

Repository for applikationen

Kim Wuestkamp/k8s-deployment-example-app

Dette er en meget simpel Python+Flask API, der returnerer et svar som JSON. Vi bygger pakken ved hjælp af GitlabCI og skubber resultatet til Gitlab Registry. I registreringsdatabasen har vi to forskellige udgivelsesversioner:

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 så let som muligt at visualisere, hvilken version vi kommunikerer med.

Infrastrukturlager

I dette lager vil vi bruge GitlabCI til udrulning til Kubernetes, .gitlab-ci.yml ser sådan 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 en klynge, 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 gaffel https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure og opret en variabel KUBECONFIG i GitlabCI, som vil indeholde konfigurationen for adgang kubectl til din klynge.

Her Du kan læse om, hvordan du får legitimationsoplysninger til en klynge (Gcloud).

Infrastruktur Yaml

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

Rollout fungerer på samme måde som Deployment. Hvis vi ikke sætter en opdateringsstrategi (som Canary her) vil den opføre sig som standard rullende opdateringsimplementering.

Vi definerer to trin i yaml til kanarie-udrulning:

10 % af trafikken til Kanarieøerne (vent på manuel OK)
50 % trafik til Canary (vent 2 minutter og fortsæt derefter til 100 %)

Udførelse af indledende implementering

Efter den indledende implementering vil vores ressourcer se sådan ud:

Og vi får kun et svar fra den første version af applikationen:

Udførelse af Canary Deployment

Trin 1: 10 % trafik

For at starte en kanarie-implementering skal vi bare ændre billedversionen, som vi plejer med implementeringer:

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 ændringer, så Gitlab CI implementerer, og vi ser ændringerne:

Hvis vi nu får adgang til tjenesten:

Store! Vi er midt i vores kanarie-udsendelse. Vi kan se fremskridtene ved at køre:

kubectl argo rollouts get rollout rollout-canary

Trin 2: 50 % trafik:

Lad os nu gå videre til næste trin: omdirigere 50 % af trafikken. Vi konfigurerede dette trin til at blive kørt manuelt:

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

Og vores applikation returnerede 50 % af svarene fra nye versioner:

Og udrulningsgennemgang:

Vidunderlig.

Trin 3: 100 % trafik:

Vi sætter det op, så efter 2 minutter slutter 50%-trinnet automatisk, og 100%-trinnet starter:

Og applikationsoutput:

Og udrulningsgennemgang:

Canary-udrulningen er fuldført.

Flere eksempler med Argo Rollouts

Der er flere eksempler her, såsom hvordan man opsætter miljøforhåndsvisninger og sammenligninger baseret på kanariefugle:

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

Video om Argo Rollouts og Argo CI

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

Total

Jeg kan virkelig godt lide ideen om at bruge CRD'er, der styrer oprettelsen af yderligere typer implementeringer eller replikasæt, omdirigere trafik osv. Arbejdet med dem går glat. Dernæst vil jeg gerne teste integrationen med Argo CI.

Der ser dog ud til at være en stor fusion af Argo CI og Flux CI på vej, så jeg kan vente, indtil den nye udgivelse kommer ud: Argo Flux.

Har du nogen erfaring med Argo Rollouts eller Argo CI?

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

Kilde: www.habr.com

Canary-udrulning i Kubernetes #2: Argo-udrulning