Canary Deployment i Kubernetes #1: Gitlab CI

Vi kommer att använda Gitlab CI och manuell GitOps för att implementera och använda Canary-deployment i Kubernetes

Artiklar från denna cykel:

• (denna artikel)
• Canary Deployment med hjälp av ArgoCI
• Canary Deployment med hjälp av Istio
• Canary Deployment med hjälp av Jenkins-X Istio Flagger

Vi kommer att genomföra Canary-deployment manuellt genom GitOps och skapande/ändring av grundresurser i Kubernetes. Denna artikel är främst avsedd för att introducera hur Canary deployment fungerar i Kubernetes, eftersom det finns mer effektiva sätt att automatisera, som vi kommer att diskutera i kommande artiklar.

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

Canary-deployment

Vid en Canary-uppdateringsstrategi tillämpas uppdateringar först för en del av användarna. Genom övervakning, loggdata, manuell testning eller andra kanaler för feedback testas releasen innan den tillämpas för alla användare.

Kubernetes Deployment (rolling update)

Standardstrategin för Kubernetes Deployment är rolling-update, där ett visst antal pods med nya versioner av bilder startas. Om de skapas utan problem avslutas pods med äldre versioner av bilder och nya pods skapas parallellt.

GitOps

Vi använder GitOps i detta exempel eftersom vi:

• använder Git som en enda sanningens källa
• använder Git Operations för byggande och deployment (inga kommandon, utom git tag/merge behövs)

Exempel

Låt oss ta en bra praxis — ha ett enda repository för applikationskoden och ett för infrastrukturen.

Repository för applikationer

Detta är en mycket enkel API på Python+Flask som returnerar svar i JSON-format. Vi kommer att bygga paketet via GitlabCI och pusha resultatet till Gitlab Registry. I registret har vi två olika versioner av releaser:

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

Den enda skillnaden mellan dem är ändringen av den returnerade JSON-filen. Vi använder denna applikation för att maximalt enkelt visualisera vilken version vi kommunicerar med.

Infrastrukturens repository

I detta repo kommer vi att deploya via GitlabCI i Kubernetes, .gitlab-ci.yml ser ut som följer:

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

För att köra det på egen hand behöver du en 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 behöver göra en fork 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 din kluster.

Hur man får autentiseringsuppgifter för klustret (Gcloud) kan man läsa om här.

Infrastrukturens Yaml

I infrastrukturrepositoryt 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

Och 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

Och en annan 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

Observera att app-deploy för tillfället inte har några specificerade repliker.

Utför den initiala deploymenten

För att köra den initiala deployment kan du manuellt köra GitlabCI-pipelinen i master-grenen. Efter detta kubectl ska visa följande:

Vi ser app deployment med 10 repliker och app-canary med 0. Det finns också en LoadBalancer som vi kan komma åt genom curl via External IP:

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

Vi ser att vår testapplikation endast returnerar “v1”.

Utförande av Canary deployment

Steg 1: släpp en ny version för en del användare

Vi har ställt in antalet repliker till 1 i filen deploy-canary.yaml och bilden av den nya versionen:

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 ändrat antalet repliker till 9:

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

Vi pushar dessa ändringar till arkivet, som kommer att starta deployment (via GitlabCI) och ser till slut:

Vår Service kommer att peka på båda deployments, eftersom båda har selektorn app. På grund av den slumpmässiga fördelningen som standard i Kubernetes bör vi se olika svar på ~ 10% av förfrågningarna:

Det aktuella läget för vår applikation (GitOps, taget från Git som en Single Source Of Truth) är att ha två deployments med aktiva repliker, en för varje version.

~10% av användarna får tillgång till den nya versionen och testar den oavsiktligt. Nu är det dags att kontrollera loggar och övervakningsdata för att identifiera problem.

Steg 2: släpp en ny version för alla användare

Vi har beslutat att allt har gått bra, och nu behöver vi rulla ut den nya versionen till alla användare. För detta helt enkelt uppdatera deploy.yaml genom att installera den nya versionen av bilden och antalet repliker lika med 10. I deploy-canary.yaml Vi ställer antalet repliker till att vara 0. Efter distributionen blir resultatet följande:

Sammanfattningsvis

För mig hjälper det att köra distributionen manuellt på detta sätt för att förstå hur enkelt det kan konfigureras med hjälp av k8s. Eftersom Kubernetes tillåter att man uppdaterar allt via API kan dessa steg automatiseras med skript.

En annan sak som behöver implementeras är ingångspunkten för testaren (LoadBalancer eller via Ingress), som bara kan användas för att få tillgång till den nya versionen. Den kan användas för manuell visning.

I kommande artiklar kommer vi att undersöka andra automatiserade lösningar som implementerar det mesta av det vi har gjort.

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

• Vad migreringen från ClickHouse utan autentisering till ClickHouse med autentisering ledde till
• Bygg dynamiska moduler för Nginx
• Uppdatering av nxs-build-tools — verktyget för att bygga deb och rpm-paket
• Introduktion till Hashicorp Consuls Kubernetes-autorisering
• Vad vi har stött på vid användning av verktyget Csync2
• Telegram-bot för Redmine. Hur man förenklar livet för sig själv och andra

Källa: habr.com