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-distribution i Kubernetes

Artiklar från denna serie:

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

Vi kommer att utföra Canary-distributionen manuellt via GitOps och skapa/ändra de viktigaste Kubernetes-resurserna. Den här artikeln är främst avsedd för introduktion med hur distributionen fungerar i Kubernetes Canary, eftersom det finns mer effektiva metoder för automation, som vi kommer att överväga i följande artiklar.

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

Kanarieöarnas utbyggnad

Med Canary-strategin tillämpas uppdateringar först på endast en undergrupp av användare. Genom övervakning, loggdata, manuell testning eller andra återkopplingskanaler testas releasen innan den släpps till alla användare.

Kubernetes Deployment (rullande uppdatering)

Standardstrategin för Kubernetes Deployment är rullande uppdatering, där ett visst antal poddar lanseras med nya versioner av bilderna. Om de skapades utan problem avslutas poddar med gamla versioner av bilder och nya poddar skapas parallellt.

GitOps

Vi använder GitOps i det här exemplet eftersom vi:

• använder Git som en enda källa till sanning
• vi använder Git Operations för att bygga och distribuera (inga andra kommandon än git-tagg/merge behövs)

Exempel

Låt oss ta en bra praxis - att ha ett arkiv för applikationskod och ett för infrastruktur.

Applikationsförråd

Detta är ett mycket enkelt Python+Flask API som returnerar ett svar som JSON. Vi kommer att bygga paketet via 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 ändringen i den returnerade JSON-filen. Vi använder denna applikation för att så enkelt som möjligt visualisera vilken version vi kommunicerar med.

Infrastrukturförråd

I denna kålrot kommer vi att distribuera via GitlabCI till Kubernetes, .gitlab-ci.yml är 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 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.

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

Infrastruktur Yaml

I infrastrukturförvaret har vi tjänsten:

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

Och utplacering 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 ytterligare en utplacering 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 inte har några repliker definierade ännu.

Utför inledande driftsättning

För att starta den initiala distributionen kan du starta GitlabCI-pipelinen manuellt på mastergrenen. Efter det kubectl ska mata ut följande:

Vi ser app distribution med 10 repliker och app-canary med 0. Det finns också en LoadBalancer från vilken vi kan komma åt via curl via extern 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ör Canary-utbyggnad

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

Vi ställer in antalet repliker till 1 i filen deploy-canary.yaml och den nya versionsbilden:

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 fil deploy.yaml vi ändrade antalet repliker till 9:

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

Vi skickar dessa ändringar till arkivet från vilket distributionen kommer att starta (via GitlabCI) och ser som ett resultat:

Vår tjänst kommer att peka på båda implementeringarna, eftersom båda har appväljaren. På grund av Kubernetes standardrandomisering bör vi se olika svar för ~10 % av förfrågningarna:

Det nuvarande tillståndet för vår applikation (GitOps, hämtat från Git as a Single Source Of Truth) är närvaron av två distributioner med aktiva repliker, en för varje version.

~10 % av användarna blir bekanta med en ny version och testar den oavsiktligt. Nu är det dags att leta efter fel i loggarna och övervakningsdata för att hitta problem.

Steg 2: Släpp den nya versionen till alla användare

Vi bestämde oss för att allt gick bra och nu måste vi rulla ut den nya versionen till alla användare. För att göra detta uppdaterar vi helt enkelt deploy.yaml installera en ny version av bilden och antalet repliker lika med 10. In deploy-canary.yaml vi ställer tillbaka antalet repliker till 0. Efter implementeringen blir resultatet följande:

Sammanfattningsvis

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

En annan sak som behöver implementeras är en ingångspunkt för testaren (LoadBalancer eller via Ingress) genom vilken endast den nya versionen kan nås. Den kan användas för manuell surfning.

I framtida artiklar kommer vi att kolla in andra automatiserade lösningar som implementerar det mesta av det vi har gjort.

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

• Vad ledde migreringen från ClickHouse utan auktorisering till ClickHouse med auktorisation till?
• Bygga dynamiska moduler för Nginx
• Uppdatera nxs-build-tools - en assistent i att bygga deb- och rpm-paket
• Introduktion till Hashicorp Consuls Kubernetes auktorisation
• Vad vi hade att möta när vi använde Csync2-verktyget
• Telegram bot för Redmine. Hur man förenklar livet för sig själv och andra

Källa: will.com