Canary Deployment i Kubernetes #1: Gitlab CI

Vi vil bruge Gitlab CI og manuel GitOps til at implementere og anvende Canary-deployment i Kubernetes

Artikler fra denne cyklus:

• (denne artikel)
• Canary Deployment med ArgoCI
• Canary Deployment med Istio
• Canary Deployment med Jenkins-X Istio Flagger

Vi vil udføre Canary-deployment manuelt via GitOps ved at oprette/ændre de grundlæggende Kubernetes-ressourcer. Denne artikel er primært beregnet til at introducere hvordan Canary-deployment fungerer i Kubernetes, da der findes mere effektive automatiseringsmetoder, som vi vil se på i de næste artikler.

https://www.norberteder.com/canary-deployment/

Canary Deployment

Ved Canary-opdateringsstrategien anvendes ændringer først kun for en del af brugerne. Gennem overvågning, logdata, manuel testning eller andre tilbagekoblingskanaler testes udgivelsen, før den anvendes for alle brugere.

Kubernetes Deployment (rolling update)

Standardstrategien for Kubernetes Deployment er rolling-update, hvor der køres et bestemt antal pods med de nye versioner af billederne. Hvis de er oprettet uden problemer, afsluttes pods med de gamle versioner, og nye pods oprettes parallelt.

GitOps

Vi bruger GitOps i dette eksempel, fordi vi:

• bruger Git som den eneste sandhedskilde
• bruger Git Operations til bygning og deployment (ingen andre kommandoer end git tag/merge er nødvendige)

Eksempel

Lad os følge en god praksis — have et enkelt repository til applikationskoden og et til infrastrukturen.

Repository til applikationer

Dette er en meget simpel API på Python+Flask, der returnerer et svar i form af JSON. Vi vil samle pakken via GitlabCI og pushe resultatet til Gitlab Registry. I registret 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 ændringen i den returnerede JSON-fil. Vi bruger denne applikation til at visualisere på en meget enkel måde, hvilken version vi interagerer med.

Infrastruktur repository

I dette repo vil vi deploye via GitlabCI i Kubernetes, .gitlab-ci.yml sådan ud:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

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

Hvordan man får adgangsoplysninger til klyngen (Gcloud) kan læses her.

Infrastruktur Yaml

I det infrastrukturelle repository har vi service:

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

Og deployment i deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Og en anden deployment i deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Bemærk, at app-deploy endnu ikke har definerede replikaer.

Udførelse af den indledende deployment

For at starte den indledende deployment kan du køre GitlabCI-pipelinen manuelt i master-grenen. Herefter kubectl bør det vise følgende:

Vi ser app deployment med 10 replikaer og app-canary med 0. Der er også en LoadBalancer, som vi kan tilgå via curl via External IP:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

Vi ser, at vores testapplikation kun returnerer “v1”.

Udførelse af Canary deployment

Trin 1: Udgiv en ny version til en del af brugerne

Vi har indstillet antallet af replikaer til 1 i filen deploy-canary.yaml og billedet af den nye version:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

I filen deploy.yaml Vi har ændret antallet af replikaer til 9:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

Vi pusher disse ændringer til det repository, fra hvilket deploymenten vil køre (via GitlabCI) og ser i sidste ende:

Vores Service vil pege på begge deployments, da begge har selector app. På grund af tilfældig distribution som standard i Kubernetes bør vi se forskellige svar på ~ 10% af anmodningerne:

Den nuværende tilstand af vores applikation (GitOps, taget fra Git som den Single Source Of Truth) er tilstedeværelsen af to deployments med aktive replikaer, én for hver version.

~10% af brugerne bliver bekendt med den nye version og tester den utilsigtet. Nu er det tid til at kontrollere for fejl i loggene og overvågningsdataene for at finde problemer.

Trin 2: Udgiv en ny version til alle brugere

Vi har besluttet, at alt gik godt, og nu skal vi rulle den nye version ud til alle brugere. For at gøre dette opdaterer vi deploy.yaml ved at installere den nye version af billedet og sætte antallet af replikaer til 10. I deploy-canary.yaml sætter vi antallet af replikaer tilbage til 0. Efter udrulningen vil resultatet være som følger:

Sammenfattende

For mig hjælper det at starte udrulningen manuelt på denne måde med at forstå, hvor nemt det kan konfigureres ved hjælp af k8s. Da Kubernetes tillader opdateringer gennem API'et, kan disse trin automatiseres via scripts.

Endnu en ting, der skal implementeres, er indgangspunktet for testeren (LoadBalancer eller via Ingress), som kun kan bruges til at få adgang til den nye version. Det kan bruges til manuel gennemgang.

I de næste artikler vil vi se på andre automatiserede løsninger, der implementerer det meste af det, vi har gjort.

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

• Hvad migrationen fra ClickHouse med autorisation til ClickHouse uden autorisation førte til
• Byggelse af dynamiske moduler til Nginx
• Opdatering af nxs-build-tools - hjælperen til at bygge deb- og rpm-pakker
• Introduksjon til Hashicorp Consul’s Kubernetes-autorisering
• Hvad vi stødte på, da vi brugte værktøjet Csync2
• Telegram-bot til Redmine. Hvordan man forenkler livet for sig selv og andre

Kilde: habr.com