Canary Deployment u Kubernetesu #1: Gitlab CI

Koristit ćemo Gitlab CI i ručni GitOps za implementaciju i korištenje Canary deploya u Kubernetesu

Članci iz ovog ciklusa:

• (ovaj članak)
• Canary Deployment uz pomoć ArgoCI
• Canary Deployment uz pomoć Istio
• Canary Deployment uz pomoć Jenkins-X Istio Flagger

Canary deploy ćemo provoditi ručno putem GitOps i stvaranjem/izmjenom osnovnih Kubernetes resursa. Ovaj članak je prvenstveno namijenjen upoznavanju s tim kako funciona Canary deploy u Kubernetesu, jer postoje učinkovitiji načini automatzacije koje ćemo razmotriti u sljedećim člancima.

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

Canary Deployment

Kod Canary strategije ažuriranja, prvo se promjene primjenjuju samo za dio korisnika. Kroz praćenje, podatke iz logova, ručno testiranje ili druge kanale povratnih informacija, izdanje se testira prije nego što se primjeni za sve korisnike.

Kubernetes Deployment (rolling update)

Zadana strategija za Kubernetes Deployment je rolling-update, gdje se pokreće određeni broj podova s novim verzijama slika. Ako su se stvorili bez problema, stari podovi s prethodnim verzijama slika se završavaju, a novi podovi se stvaraju paralelno.

GitOps

Koristimo GitOps u ovom primjeru, jer:

• koristimo Git kao jedini izvor istine
• koristimo Git operacije za izgradnju i deploy (nije potrebna nikakva komanda osim git tag/merge)

Primjer

Uzet ćemo dobru praksu — imati jedan repozitorij za kod aplikacija i jedan za infrastrukturu.

Rep prioritet za aplikacije

Ovo je vrlo jednostavna API na Pythonu+Flasku, koja vraća odgovor u obliku JSON-a. Izradit ćemo paket putem GitlabCI i pushati rezultat u Gitlab Registry. U registru imamo dvije različite verzije izdanja:

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

Jedina razlika između njih je promjena vraćenog JSON fajla. Koristimo ovu aplikaciju za maksimalno jednostavnu vizualizaciju s kojom verzijom komuniciramo.

Infrastrukturni repozitorij

U ovom repu ćemo deployati kroz GitlabCI u Kubernetes; .gitlab-ci.yml izgleda ovako:

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

Za njegovo pokretanje sami ćete trebati klaster, možete koristiti Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

Trebate napraviti forku https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure i stvoriti varijablu KUBECONFIG u GitlabCI, koja će sadržavati konfiguraciju za pristup kubectl vašem klasteru.

O tome kako dobiti podatke za klaster (Gcloud) možete pročitati ovdje.

Infrastrukturni Yaml

U infrastrukturnom repozitoriju imamo službu:

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

I deployment u 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

I druga implementacija u 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

Primijetite da app-deploy još nema definiranih replika.

Izvršenje inicijalnog implementiranja

Za pokretanje početne implementacije možete ručno pokrenuti GitlabCI pipeline u glavnoj grani. Nakon toga kubectl trebalo bi ispisati sljedeće:

Vidimo app implementaciju s 10 replika i app-canary s 0. Također postoji LoadBalancer putem kojeg možemo pristupiti curl putem vanjskog IP-a:

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

Vidimo da naša testna aplikacija vraća samo "v1".

Izvođenje Canary implementacije

Korak 1: objaviti novu verziju za dio korisnika

Postavili smo broj replika na 1 u datoteci deploy-canary.yaml i sliku nove verzije:

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

U datoteci deploy.yaml promijenili smo broj replika na 9:

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

Guramo te promjene u repozitorij iz kojeg će se pokrenuti implementacija (putem GitlabCI) i konačno vidimo:

Naša Usluga će ukazivati na obje implementacije, budući da obje imaju selektor app. Zbog slučajne raspodjele prema zadanim postavkama u Kubernetesu trebali bismo vidjeti različite odgovore na ~ 10% zahtjeva:

Trenutačno stanje naše aplikacije (GitOps, preuzeto iz Gita kao iz Jedinog Izvora Istine) je postojanje dviju implementacija s aktivnim replikama, po jedna za svaku verziju.

~10% korisnika upoznaje novu verziju i nesvjesno ju testira. Sada je vrijeme da provjerimo ima li grešaka u zapisima i podacima o praćenju kako bismo pronašli probleme.

Korak 2: objaviti novu verziju za sve korisnike

Odlučili smo da je sve prošlo dobro i sada moramo rasporediti novu verziju svim korisnicima. Za to jednostavno ažuriramo deploy.yaml naručujući novu verziju slike i broj replika, koji iznosi 10. U deploy-canary.yaml postavljamo broj replika na nulu. Nakon implementacije, rezultat će biti sljedeći:

Zaključno

Za mene, ručno pokretanje implementacije na ovaj način pomaže razumjeti koliko lako se može konfigurirati pomoću k8s. Budući da Kubernetes omogućava ažuriranje svega putem API-ja, ove korake je moguće automatizirati skriptama.

Još jedna stvar koju treba implementirati je pristupna tačka za testere (LoadBalancer ili putem Ingress-a), preko koje se može pristupiti samo novoj verziji. Može se koristiti za ručno pregledavanje.

U sljedećim člancima ćemo istražiti druga automatizirana rješenja koja implementiraju većinu onoga što smo napravili.

Također pročitajte druge članke na našem blogu:

• K čemu je dovela migracija s ClickHousea bez autorizacije na ClickHouse s autorizacijom
• Izrada dinamičkih modula za Nginx
• Ažuriranje nxs-build-tools — pomoćnika za izradu deb i rpm paketa
• Uvod u Hashicorp Consulovu autorizaciju za Kubernetes
• S čim smo se suočili prilikom korištenja alata Csync2
• Telegram-bot za Redmine. Kako olakšati život sebi i drugima

Izvor: habr.com