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 implementacija pomoću ArgoCI
• Canary implementacija pomoću Istia
• Canary implementacija pomoću Jenkins-X Istio Flaggera

Implementaciju Canarya izvršit ćemo ručno putem GitOpsa i kreiranja/modificiranja glavnih resursa Kubernetesa. Ovaj je članak prvenstveno namijenjen uvodu s načinom na koji implementacija funkcionira u Kubernetes Canary, budući da postoje učinkovitije metode automatizacije, koje ćemo razmotriti u sljedećim člancima.

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

Canary raspoređivanje

Sa strategijom Canary, ažuriranja se prvo primjenjuju samo na podskup korisnika. Putem praćenja, podataka dnevnika, ručnog testiranja ili drugih kanala povratnih informacija, izdanje se testira prije nego što se objavi svim korisnicima.

Kubernetes implementacija (tekuće ažuriranje)

Zadana strategija za Kubernetes Deployment je rolling-update, gdje se određeni broj podova pokreće s novim verzijama slika. Ako su kreirani bez problema, podovi sa starim verzijama slika se prekidaju, a paralelno se stvaraju novi podovi.

GitOps

Koristimo GitOps u ovom primjeru 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 - imati jedno spremište za kod aplikacije i jedno za infrastrukturu.

Repozitorij aplikacija

Ovo je vrlo jednostavan Python+Flask API koji vraća odgovor kao JSON. Izgradit ćemo paket putem GitlabCI-ja i poslati rezultat u Gitlab registar. 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ćenoj JSON datoteci. Ovu aplikaciju koristimo kako bismo što lakše vizualizirali s kojom verzijom komuniciramo.

Spremište infrastrukture

U ovoj ćemo fazi implementirati putem GitlabCI-ja u Kubernetes, .gitlab-ci.yml je kako slijedi:

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

Trebate račvati https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure i stvoriti varijablu KUBECONFIG u GitlabCI, koji će sadržavati konfiguraciju za pristup kubectl u svoj klaster.

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

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

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

Izvođenje početne implementacije

Za početak početne implementacije, možete pokrenuti GitlabCI cjevovod ručno na glavnoj grani. Nakon toga kubectl treba ispisati sljedeće:

Mi vidimo app implementacija s 10 replika i app-canary s 0. Tu je i LoadBalancer iz kojeg možemo pristupiti putem curl preko 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".

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 spisu 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 započeti implementacija (putem GitlabCI-ja) i kao rezultat vidimo:

Naša će usluga ukazivati ​​na obje implementacije, budući da obje imaju birač aplikacija. Zbog Kubernetesove zadane randomizacije, trebali bismo vidjeti različite odgovore za ~10% zahtjeva:

Trenutačno stanje naše aplikacije (GitOps, preuzeto iz Gita kao jedinstvenog izvora istine) je prisutnost dvije implementacije s aktivnim replikama, po jedna za svaku verziju.

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

2. korak: objavite novu verziju za sve korisnike

Odlučili smo da je sve prošlo u redu i sada moramo uvesti novu verziju za sve korisnike. 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:

Sažimanje

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

Još jedna stvar koju treba implementirati je ulazna točka testera (LoadBalancer ili preko Ingressa) preko koje se može pristupiti samo novoj verziji. Može se koristiti za ručno pregledavanje.

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

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

• Do čega je dovela migracija s ClickHouse bez autorizacije na ClickHouse s autorizacijom?
• Izrada dinamičkih modula za Nginx
• Ažurirajte nxs-build-tools - pomoćnik u izgradnji deb i rpm paketa
• Uvod u autorizaciju Kubernetesa tvrtke Hashicorp Consul
• S čime smo se morali suočiti prilikom korištenja uslužnog programa Csync2
• Telegram bot za Redmine. Kako pojednostaviti život sebi i drugima

Izvor: www.habr.com