Canary Deployment in Kubernetes #1: Gitlab CI

Mir benotze Gitlab CI a manuelle GitOps fir Kanaresch Deployment an Kubernetes ëmzesetzen an ze benotzen

Artikelen aus dëser Serie:

• (Dësen Artikel)
• Canary Deployment benotzt ArgoCI
• Canary Deployment benotzt Istio
• Canary Deployment benotzt Jenkins-X Istio Flagger

Mir wäerten d'Kanaresch Deployment manuell iwwer GitOps ausféieren an d'Haapt Kubernetes Ressourcen erstellen / änneren. Dësen Artikel ass haaptsächlech fir Aféierung geduecht mat wéi d'Deployment am Kubernetes Canary funktionnéiert, well et méi effektiv Automatiséierungsmethoden gëtt, déi mir an den folgenden Artikelen betruechten.

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

Kanaresch Deployment

Mat der Kanaresch Strategie ginn d'Aktualiséierunge fir d'éischt op nëmmen e Subset vu Benotzer applizéiert. Duerch Iwwerwaachung, Logdaten, manuell Testen oder aner Feedbackkanäl gëtt d'Verëffentlechung getest ier se un all Benotzer verëffentlecht gëtt.

Kubernetes Deployment (Rolling Update)

D'Standardstrategie fir Kubernetes Deployment ass Rolling-Update, wou eng gewëssen Zuel vu Pods mat neie Versioune vun de Biller gestart ginn. Wa se ouni Probleemer erstallt goufen, ginn Pods mat alen Versioune vu Biller ofgeschloss, an nei Pods ginn parallel erstallt.

GitOps

Mir benotzen GitOps an dësem Beispill well mir:

• benotzt Git als eenzeg Quell vun der Wourecht
• mir benotze Git Operatioune fir ze bauen an z'installéieren (keng Kommandoen ausser Git Tag / Merge sinn néideg)

Beispill:

Loosst eis eng gutt Praxis huelen - ee Repository fir Applikatiounscode an een fir Infrastruktur hunn.

Applikatioun Repository

Dëst ass eng ganz einfach Python + Flask API déi eng Äntwert als JSON zréckginn. Mir bauen de Package iwwer GitlabCI an dréckt d'Resultat op de Gitlab Registry. Am Registry hu mir zwou verschidde Verëffentlechungsversioune:

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

Deen eenzegen Ënnerscheed tëscht hinnen ass d'Ännerung an der zréckginn JSON Datei. Mir benotzen dës Applikatioun fir sou einfach wéi méiglech ze visualiséieren mat wéi enger Versioun mir kommunizéieren.

Infrastruktur Repository

An dëser Rübe wäerte mir iwwer GitlabCI op Kubernetes ofsetzen, .gitlab-ci.yml ass folgend:

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

Fir et selwer ze lafen braucht Dir e Cluster, Dir kënnt Gcloud benotzen:

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

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

Dir musst Gabel https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure a schafen eng Variabel KUBECONFIG an GitlabCI, déi d'Configuratioun fir Zougang enthält kubectl op Äre Stärekoup.

Dir kënnt liesen wéi Dir Umeldungsinformatiounen fir e Cluster kritt (Gcloud) hei riets.

Infrastruktur Yaml

Am Infrastrukturrepository hu mir Service:

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

An Ofbau an 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

An eng aner Deployment an 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

Notéiert datt d'App-Deploy nach keng Repliken definéiert huet.

Ausféieren initial Deployment

Fir den initialen Deployment unzefänken, kënnt Dir d'GitlabCI Pipeline manuell op der Masterbranche starten. Nodeems datt kubectl soll déi folgend erausginn:

Mir gesinn app deployment with 10 replicas and app-canary with 0. Et gëtt och e LoadBalancer aus deem mir Zougang duerch curl iwwer extern IP:

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

Mir gesinn datt eis Testapplikatioun nëmmen "v1" zréckkënnt.

Ausféierung Kanaresch Deployment

Schrëtt 1: Fräisetzung eng nei Versioun fir e puer Benotzer

Mir setzen d'Zuel vun de Repliken op 1 an der deploy-canary.yaml Datei an dem neie Versiounsbild:

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

Am Dossier deploy.yaml mir hunn d'Zuel vun de Repliken op 9 geännert:

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

Mir drécken dës Ännerungen op de Repository aus deem d'Deployment ufänkt (iwwer GitlabCI) an als Resultat gesi mir:

Eise Service wäert op béid Deployementer weisen, well béid den App Selector hunn. Wéinst Kubernetes 'Standard Randomiséierung, solle mir verschidden Äntwerte fir ~ 10% vun Ufroe gesinn:

Den aktuellen Zoustand vun eiser Applikatioun (GitOps, aus Git als Single Source Of Truth geholl) ass d'Präsenz vun zwee Deployementer mat aktive Repliken, eng fir all Versioun.

~ 10% vun de Benotzer ginn mat enger neier Versioun vertraut an testen se onbedéngt. Elo ass d'Zäit fir Feeler an de Logbicher an Iwwerwaachungsdaten ze kontrolléieren fir Probleemer ze fannen.

Schrëtt 2: Fräisetzung déi nei Versioun fir all Benotzer

Mir hunn decidéiert datt alles gutt gaang ass an elo musse mir déi nei Versioun un all Benotzer ausrollen. Fir dëst ze maachen, aktualiséieren mir einfach deploy.yaml eng nei Versioun vum Bild installéieren an d'Zuel vun de Repliken gläich 10. An deploy-canary.yaml mir setzen d'Zuel vun de Repliken zréck op 0. Nom Ofbau gëtt d'Resultat wéi follegt:

Zesummefaassung

Fir mech hëlleft den Deployment manuell op dës Manéier ze verstoen wéi einfach et ka mat k8s konfiguréiert ginn. Zënter Kubernetes erlaabt Iech alles iwwer eng API ze aktualiséieren, kënnen dës Schrëtt duerch Skripte automatiséiert ginn.

Eng aner Saach déi ëmgesat muss ginn ass en Tester-Entréepunkt (LoadBalancer oder iwwer Ingress), duerch deen nëmmen déi nei Versioun zougänglech ass. Et kann fir manuell Surfen benotzt ginn.

An zukünfteg Artikele wäerte mir aner automatiséiert Léisunge kucken, déi dat meescht vun deem wat mir gemaach hunn ëmsetzen.

Liest och aner Artikelen op eisem Blog:

• Wat huet d'Migratioun vu ClickHouse ouni Autorisatioun op ClickHouse mat Autorisatioun gefouert?
• Bauen dynamesch Moduler fir Nginx
• Update nxs-build-tools - en Assistent beim Bauen vun Deb- a Rpm-Paketen
• Aféierung an der Kubernetes Autorisatioun vum Hashicorp Consul
• Wat mir hu misse konfrontéieren wann Dir de Csync2 Utility benotzt
• Telegram Bot fir Redmine. Wéi d'Liewen fir Iech selwer an anerer ze vereinfachen

Source: will.com