Canary Deployment i Kubernetes #1: Gitlab CI

Vi vil bruge Gitlab CI og manuelle GitOps til at implementere og bruge Canary-implementering i Kubernetes

Artikler fra denne serie:

• (Denne artikel)
• Canary Deployment ved hjælp af ArgoCI
• Canary Deployment ved hjælp af Istio
• Canary Deployment ved hjælp af Jenkins-X Istio Flagger

Vi vil udføre Canary-implementeringen manuelt via GitOps og oprette/ændre de vigtigste Kubernetes-ressourcer. Denne artikel er primært beregnet til introduktion med hvordan udrulning fungerer i Kubernetes Canary, da der er mere effektive metoder til automatisering, som vi vil overveje i de følgende artikler.

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

Kanariske indsættelse

Med Canary-strategien anvendes opdateringer først på kun en undergruppe af brugere. Gennem overvågning, logdata, manuel test eller andre feedbackkanaler testes udgivelsen, inden den frigives til alle brugere.

Kubernetes-implementering (rullende opdatering)

Standardstrategien for Kubernetes Deployment er rullende opdatering, hvor et vist antal pods lanceres med nye versioner af billederne. Hvis de blev oprettet uden problemer, afsluttes pods med gamle versioner af billeder, og nye pods oprettes parallelt.

GitOps

Vi bruger GitOps i dette eksempel, fordi vi:

• ved at bruge Git som en enkelt kilde til sandhed
• vi bruger Git Operations til opbygning og implementering (ingen andre kommandoer end git tag/merge er nødvendige)

Eksempel

Lad os tage en god praksis - at have ét lager til applikationskode og et til infrastruktur.

Applikationslager

Dette er en meget simpel Python+Flask API, der returnerer et svar som JSON. Vi vil bygge pakken via GitlabCI og skubbe 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 ændringen i den returnerede JSON-fil. Vi bruger denne applikation til så let som muligt at visualisere, hvilken version vi kommunikerer med.

Infrastrukturlager

I denne majro vil vi implementere via GitlabCI til Kubernetes, .gitlab-ci.yml er som følger:

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

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

Infrastruktur Yaml

I infrastrukturlageret 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 indsættelse 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 endnu en indsættelse 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 ikke har nogen replikaer defineret endnu.

Udførelse af indledende implementering

For at starte den indledende implementering kan du starte GitlabCI-pipelinen manuelt på mastergrenen. Efter det kubectl skal udskrive følgende:

Vi ser app implementering med 10 replikaer og app-canary med 0. Der er også en LoadBalancer, hvorfra vi kan få adgang via curl via ekstern 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-udrulning

Trin 1: frigiv en ny version for nogle brugere

Vi indstiller antallet af replikaer til 1 i filen deploy-canary.yaml og det nye versionsbillede:

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 ændrede antallet af replikaer til 9:

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

Vi skubber disse ændringer til det lager, hvorfra implementeringen starter (via GitlabCI) og ser som et resultat:

Vores service vil pege på begge implementeringer, da begge har appvælgeren. På grund af Kubernetes' standard randomisering bør vi se forskellige svar for ~10 % af anmodningerne:

Den aktuelle tilstand af vores applikation (GitOps, taget fra Git as a Single Source Of Truth) er tilstedeværelsen af ​​to implementeringer med aktive replikaer, en for hver version.

~10 % af brugerne bliver bekendt med en ny version og tester den utilsigtet. Nu er det tid til at tjekke for fejl i logfilerne og overvågningsdata for at finde problemer.

Trin 2: Frigiv den nye version til alle brugere

Vi besluttede, at alt gik godt, og nu skal vi udrulle den nye version til alle brugere. For at gøre dette opdaterer vi blot deploy.yaml installation af en ny version af billedet og antallet af replikaer svarende til 10. In deploy-canary.yaml vi sætter antallet af replikaer tilbage til 0. Efter implementering vil resultatet være som følger:

Opsummering

For mig hjælper det at køre installationen manuelt på denne måde med at forstå, hvor nemt det kan konfigureres ved hjælp af k8s. Da Kubernetes giver dig mulighed for at opdatere alt via en API, kan disse trin automatiseres gennem scripts.

En anden ting, der skal implementeres, er et testindgangspunkt (LoadBalancer eller via Ingress), hvorigennem kun den nye version kan tilgås. Den kan bruges til manuel browsing.

I fremtidige artikler vil vi tjekke andre automatiserede løsninger, der implementerer det meste af det, vi har gjort.

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

• Hvad førte migreringen fra ClickHouse uden autorisation til ClickHouse med autorisation til?
• Opbygning af dynamiske moduler til Nginx
• Opdater nxs-build-tools - en assistent til at bygge deb- og rpm-pakker
• Introduktion til Hashicorp Consuls Kubernetes-autorisation
• Hvad vi skulle stå over for, når vi brugte Csync2-værktøjet
• Telegram bot til Redmine. Sådan forenkler du livet for dig selv og andre

Kilde: www.habr.com