Canary implementacija u Kubernetes #1: Gitlab CI

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

Članci iz ove serije:

• (Ovaj članak)
• Canary Deployment koristeći ArgoCI
• Canary Deployment koristeći Istio
• Canary Deployment koristeći Jenkins-X Istio Flagger

Izvešćemo Canary implementaciju ručno preko GitOps-a i kreiramo/modifikujemo glavne Kubernetes resurse. Ovaj članak je prvenstveno namijenjen uvodu kako implementacija funkcioniše u Kubernetes Canary, budući da postoje efikasnije metode automatizacije, koje ćemo razmotriti u narednim člancima.

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

Canary Deployment

Sa Canary strategijom, ažuriranja se prvo primjenjuju samo na podskup korisnika. Kroz praćenje, podatke dnevnika, ručno testiranje ili druge kanale povratnih informacija, izdanje se testira prije nego što bude pušteno svim korisnicima.

Kubernetes implementacija (ažuriranje)

Zadana strategija za Kubernetes Deployment je stalno ažuriranje, gdje se određen broj podova pokreće s novim verzijama slika. Ako su kreirani bez problema, podovi sa starim verzijama slika se prekidaju, a novi podovi se kreiraju paralelno.

gitops

U ovom primjeru koristimo GitOps jer:

• koristeći Git kao jedini izvor istine
• koristimo Git Operations za izgradnju i implementaciju (nisu potrebne nikakve naredbe osim git tag/merge)

Primjer:

Uzmimo dobru praksu - da imamo jedno spremište za kod aplikacije i jedno za infrastrukturu.

Repozitorijum aplikacija

Ovo je vrlo jednostavan Python+Flask API koji vraća odgovor kao JSON. Napravit ćemo paket preko GitlabCI-a i gurnuti 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 u vraćenom JSON fajlu. Koristimo ovu aplikaciju kako bismo što lakše vizualizirali s kojom verzijom komuniciramo.

Infrastrukturno spremište

U ovoj repi ćemo rasporediti preko GitlabCI na Kubernetes, .gitlab-ci.yml je sledeći:

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

Da biste ga sami pokrenuli, trebat će vam 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

Morate da se račvate https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure i kreirajte varijablu KUBECONFIG u GitlabCI, koji će sadržavati konfiguraciju za pristup kubectl vašem klasteru.

Možete pročitati o tome kako dobiti vjerodajnice za klaster (Gcloud) ovde.

Infrastruktura Yaml

U infrastrukturnom repozitoriju imamo uslugu:

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

I raspoređivanje 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 još jedno raspoređivanje 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

Imajte na umu da app-deploy još nema definirane replike.

Izvođenje početnog postavljanja

Da biste započeli početnu implementaciju, možete pokrenuti GitlabCI cjevovod ručno na glavnoj grani. Nakon toga kubectl trebao bi ispisati sljedeće:

Vidimo app implementacija sa 10 replika i app-canary sa 0. Tu je i LoadBalancer iz kojeg možemo pristupiti putem curl preko vanjske IP adrese:

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

Vidimo da naša test aplikacija vraća samo “v1”.

Izvršavanje Canary implementacije

Korak 1: objavite novu verziju za neke korisnike

Postavili smo broj replika na 1 u datoteci deploy-canary.yaml i slici 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 fajlu deploy.yaml promijenili smo broj replika na 9:

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

Ove promjene guramo u spremište iz kojeg će početi implementacija (preko GitlabCI-a) i vidimo kao rezultat:

Naša usluga će ukazati na obje implementacije, budući da obje imaju selektor aplikacija. Zbog Kubernetes-ove zadane randomizacije, trebali bismo vidjeti različite odgovore za ~10% zahtjeva:

Trenutno stanje naše aplikacije (GitOps, preuzeto iz Gita kao jedinstvenog izvora istine) je prisustvo dvije implementacije sa aktivnim replikama, po jedna za svaku verziju.

~10% korisnika upozna se s novom verzijom i nenamjerno je testira. Sada je vrijeme da provjerite da li postoje greške u evidenciji i podacima praćenja kako biste pronašli probleme.

Korak 2: Objavite novu verziju za sve korisnike

Odlučili smo da je sve prošlo kako treba i sada trebamo izbaciti novu verziju svim korisnicima. Da bismo to učinili, jednostavno ažuriramo deploy.yaml instaliranje nove verzije slike i broj replika jednak 10. In deploy-canary.yaml vraćamo broj replika na 0. Nakon implementacije, rezultat će biti sljedeći:

Sumirati

Za mene, pokretanje implementacije ručno na ovaj način pomaže da shvatim koliko se lako može konfigurirati pomoću k8s-a. Budući da vam Kubernetes omogućava ažuriranje svega putem API-ja, ovi koraci se mogu automatizirati putem skripti.

Još jedna stvar koju treba implementirati je ulazna tačka testera (LoadBalancer ili preko Ingress-a) preko koje se može pristupiti samo novoj verziji. Može se koristiti za ručno pretraživanje.

U budućim člancima ćemo provjeriti druga automatizirana rješenja koja implementiraju većinu onoga što smo uradili.

Pročitajte i druge članke na našem blogu:

• Do čega je dovela migracija sa ClickHouse bez autorizacije na ClickHouse sa autorizacijom?
• Izrada dinamičkih modula za Nginx
• Ažurirajte nxs-build-tools - pomoćnik u izgradnji deb i rpm paketa
• Uvod u Kubernetes autorizaciju Hashicorp konzula
• Sa čime smo se morali suočiti kada smo koristili uslužni program Csync2
• Telegram bot za Redmine. Kako sebi i drugima olakšati život

izvor: www.habr.com