🥇Uvajanje Canary v Kubernetes #1: Gitlab CI

Uporabili bomo Gitlab CI in ročne GitOps za implementacijo in uporabo uvajanja Canary v Kubernetes

Članki iz te serije:

(Ta članek)
Canary Deployment z uporabo ArgoCI
Canary Deployment with Istio
Uvedba Canary z uporabo Jenkins-X Istio Flagger

Uvajanje Canaryja bomo izvedli ročno prek GitOps in ustvarjanja/spreminjanja glavnih virov Kubernetes. Ta članek je namenjen predvsem uvodu s tem, kako deluje uvajanje v Kubernetes Canary, saj obstajajo bolj učinkovite metode avtomatizacije, ki jih bomo obravnavali v naslednjih člankih.

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

Canary Deployment

Pri strategiji Canary se posodobitve najprej uporabijo samo za podmnožico uporabnikov. S spremljanjem, dnevniškimi podatki, ročnim testiranjem ali drugimi povratnimi kanali se izdaja testira, preden se izda vsem uporabnikom.

Uvajanje Kubernetes (tekoča posodobitev)

Privzeta strategija za uvajanje Kubernetes je tekoče posodabljanje, kjer se določeno število podov zažene z novimi različicami slik. Če so bili ustvarjeni brez težav, se podi s starimi različicami slik prekinejo in vzporedno se ustvarijo novi podi.

GitOps

V tem primeru uporabljamo GitOps, ker:

uporabo Gita kot edinega vira resnice
za gradnjo in uvajanje uporabljamo Git Operations (ukazi razen git tag/merge niso potrebni)

Primer

Vzemimo dobro prakso – imeti en repozitorij za aplikacijsko kodo in enega za infrastrukturo.

Repozitorij aplikacij

To je zelo preprost API Python+Flask, ki vrne odgovor kot JSON. Paket bomo zgradili prek GitlabCI in rezultat potisnili v register Gitlab. V registru imamo dve različni različici izdaje:

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

Edina razlika med njima je sprememba v vrnjeni datoteki JSON. To aplikacijo uporabljamo za čim lažjo vizualizacijo, s katero različico komuniciramo.

Repozitorij infrastrukture

V tej repi bomo prek GitlabCI uvedli v Kubernetes, .gitlab-ci.yml je naslednji:

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

Če ga želite zagnati sami, potrebujete gručo, lahko uporabite Gcloud:

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

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

Morate vilice https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure in ustvarite spremenljivko KUBECONFIG v GitlabCI, ki bo vseboval konfiguracijo za dostop kubectl v vaš grozd.

Preberete lahko o tem, kako pridobiti poverilnice za gručo (Gcloud) tukaj.

Infrastruktura Yaml

V infrastrukturnem repozitoriju imamo storitev:

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

In uvedba v 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

In še ena uvedba v 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

Upoštevajte, da app-deploy še nima definiranih replik.

Izvajanje začetne uvedbe

Za začetek začetne uvedbe lahko ročno zaženete cevovod GitlabCI v glavni veji. Potem kubectl mora izpisati naslednje:

Vidimo app uvajanje z 10 replikami in app-canary z 0. Obstaja tudi LoadBalancer, do katerega lahko dostopamo prek curl prek zunanjega IP-ja:

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

Vidimo, da naša testna aplikacija vrne samo »v1«.

Izvajanje uvajanja Canary

1. korak: izdajte novo različico za nekatere uporabnike

V datoteki deploy-canary.yaml in sliki nove različice smo nastavili število replik na 1:

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

V datoteki deploy.yaml smo spremenili število replik na 9:

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

Te spremembe potisnemo v repozitorij, iz katerega se bo začela uvedba (prek GitlabCI), in kot rezultat vidimo:

Naša storitev bo kazala na obe uvedbi, saj imata obe izbirnik aplikacij. Zaradi privzete randomizacije Kubernetes bi morali videti različne odgovore za ~10 % zahtev:

Trenutno stanje naše aplikacije (GitOps, vzeto iz Git kot en sam vir resnice) je prisotnost dveh uvedb z aktivnimi replikami, po ena za vsako različico.

~10 % uporabnikov se seznani z novo različico in jo nenamerno preizkusi. Zdaj je čas, da preverite napake v dnevnikih in podatkih spremljanja, da poiščete težave.

2. korak: izdajte novo različico za vse uporabnike

Odločili smo se, da je šlo vse dobro in zdaj moramo novo različico uvesti za vse uporabnike. Da bi to naredili, preprosto posodobimo deploy.yaml namestitev nove različice slike in število replik enako 10. In deploy-canary.yaml nastavimo število replik nazaj na 0. Po uvedbi bo rezultat naslednji:

Če povzamemo:

Zame ročno izvajanje uvajanja na ta način pomaga razumeti, kako preprosto ga je mogoče konfigurirati z uporabo k8s. Ker Kubernetes omogoča posodobitev vsega prek API-ja, je te korake mogoče avtomatizirati s skripti.

Druga stvar, ki jo je treba implementirati, je vstopna točka testerja (LoadBalancer ali prek Ingressa), prek katere je mogoče dostopati samo do nove različice. Uporablja se lahko za ročno brskanje.

V prihodnjih člankih bomo preverili druge avtomatizirane rešitve, ki izvajajo večino tega, kar smo naredili.

Preberite tudi druge članke na našem blogu:

Vir: www.habr.com

Uvedba Canary v Kubernetes #1: Gitlab CI