Shpërndarja Canary në Kubernetes #1: Gitlab CI

Ne do të përdorim Gitlab CI dhe GitOps të dorës për të implementuar dhe përdorur Canary-deploy në Kubernetes

Artikujt nga ky cikël:

• (ky artikull)
• Canary Deployment duke përdorur ArgoCI
• Canary Deployment duke përdorur Istio
• Canary Deployment duke përdorur Jenkins-X Istio Flagger

Ne do të kryejmë Canary-deploy manualisht përmes GitOps dhe krijimit/modifikimit të burimeve kryesore të Kubernetes. Ky artikull është në radhë të parë për t'u njohur me mënyrën se si funksionon Canary deployment në Kubernetes, pasi ka mënyra më efikase të automatizimit që do t'i shqyrtojmë në artikujt e ardhshëm.

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

Shpërndarja Canary

Me strategjinë Canary, përditësimi fillimisht aplikohet vetëm për një pjesë të përdoruesve. Përmes monitorimit, të dhënave nga log-et, testimit manual ose kanaleve të tjera të feedback-ut, lëshimi testohet para se të aplikohet për të gjithë përdoruesit.

Kubernetes Deployment (rolling update)

Strategjia e paracaktuar për Kubernetes Deployment është rolling-update, ku nis një numër i caktuar pod-esh me versione të reja të imazheve. Nëse ato krijohen pa probleme, pod-et me versionet e vjetra të imazheve përfundojnë, dhe pod-et e reja krijohen paralelisht.

GitOps

Ne përdorim GitOps në këtë shembull, pasi ne:

• përdorim Git si burimin e vetëm të së vërtetës
• përdorim Git Operations për ndërtimin dhe lëshimin (asnjë komandë tjetër përveç git tag/merge nuk nevojitet)

Shembulli

Le të marrim një praktikë të mirë — të kemi një repozitor për kodin e aplikacioneve dhe një për infrastrukturën.

Repozitori për aplikacionet

Ky është një API shumë i thjeshtë në Python+Flask, që kthen një përgjigje në formatin JSON. Ne do ta ndërtoshim paketën përmes GitlabCI dhe do ta dërgojmë rezultatin në Gitlab Registry. Në registrin kemi dy versione të ndryshme lëshimesh:

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

Dallimi i vetëm midis tyre është ndryshimi i skedarit JSON që kthehet. Ne e përdorim këtë aplikacion për një vizualizim të thjeshtë se me cilën version po komunikojmë.

Repozitori infrastruktural

Në këtë repo ne do të realizojmë deploy përmes GitlabCI në Kubernetes, .gitlab-ci.yml authorize { filter_username preprocess auth_log chap mschap suffix eap { ok = return } files -sql #-ldap expiration logintime if (!State) { if (&User-Password) { # Nëse !State dhe Password-i i Përdoruesit (PAP), atëherë detyro LDAP: update control { Ldap-UserDN := "%{User-Name}" Auth-Type := LDAP } } else { reject } } else { # Nëse State, atëherë proxy request: group_authorization } pap }

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

Për ta nisur vetë, do t'ju nevojitet një klasër, mund të përdorni Gcloud:

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

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

Ju nevojitet të bëni fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure dhe të krijoni një variablë KUBECONFIG në GitlabCI, e cila do të përmbajë konfigurimin për qasje kubectl në klasrin tuaj.

Për informacion rreth mënyrës për të marrë akreditimet për klasterin (Gcloud) mund të lexoni këtu.

Yaml-infrastrukturor

Në repozitorin e infrastrukturës kemi një shërbim:

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

Dhe deployment-in në 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

Dhe një tjetër deployment në 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

Vini re se app-deploy aktualisht nuk ka replika të caktuara.

Ekzekutimi i përllogaritjes fillestare

Për të nisur deployment-in fillestar, mund të nisni pipeline-in GitlabCI manualisht në degën master. Pasi të bëni këtë kubectl duhet të shfaqë këtë:

Shikojmë app deployment me 10 replika dhe app-canary me 0. Gjithashtu ka një LoadBalancer nga i cili mund të aksesojmë përmes curl në IP-në e jashtme:

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

Shikojmë se aplikacioni ynë testues kthen vetëm “v1”.

Ekzekutimi i Canary deploy-it

Hapi 1: lëshoni një version të ri për një pjesë të përdoruesve

Kemi vendosur numrin e replika në 1 në skedarin deploy-canary.yaml dhe imazhin e versionit të ri:

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

Në skedar deploy.yaml ne kemi ndryshuar numrin e replika në 9:

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

Ne po e shtyjmë këtë ndryshim në repositorin, nga i cili do të nisë deploy (nëpërmjet GitlabCI) dhe shikojmë në fund:

Shërbimi ynë do të tregojë për të dy deploy-et, pasi të dy kanë selektorin app. Për shkak të shpërndarjes rastësore sipas parazgjedhjes në Kubernetes, duhet të shohim përgjigje të ndryshme në rreth 10% të kërkesave:

Gjendja aktuale e aplikacionit tonë (GitOps, e marrë nga Git si Një Burim i Vërtetë) është ekzistenca e dy deploy-eve me replika aktive, nga një për çdo version.

~10% e përdoruesve po njohin versionin e ri dhe pa e dëshiruara po e testojnë atë. Tani ka ardhur koha për të kontrolluar për gabime në ditar dhe të dhënat e monitorimit për të gjetur probleme.

Hapi 2: lëshoni një version të ri për të gjithë përdoruesit

Kemi vendosur se gjithçka ka shkuar mirë dhe tani na duhet të shpërndajmë versionin e ri për të gjithë përdoruesit. Për këtë, thjesht përditësojmë deploy.yaml duke instaluar versionin e ri të imazhit dhe numrin e replika, të barabartë me 10. Në deploy-canary.yaml ne vendosim numrin e kopjeve të barabartë me 0. Pas shpërndarjes, rezultati do të jetë si më poshtë:

Në përfundim

Për mua, nisja e shpërndarjes manualisht në këtë mënyrë ndihmon të kuptoj se sa lehtë mund të konfigurohet me ndihmën e k8s. Siç e lejon Kubernetes për të përditësuar gjithçka përmes API, këta hapa mund të automatizohen përmes skripteve.

Një gjë tjetër që duhet implementuar është pika e hyrjes për testuesit (LoadBalancer ose përmes Ingress), përmes së cilës mund të aksesoni vetëm versionin e ri. Ajo mund të përdoret për të parë manualisht.

Në artikujt e ardhshëm do të shqyrtojmë zgjidhje të tjera automatizimi që realizojnë shumicën e asaj që kemi bërë.

Lexoni gjithashtu artikuj të tjerë në blogun tonë:

• Çfarë solli migrimi nga ClickHouse pa autorizim në ClickHouse me autorizim
• Ndërtimi i moduleve dinamike për Nginx
• Përditësimi i nxs-build-tools — ndihmësi në ndërtimin e paketave deb dhe rpm
• Hyrja në autorizimin e Kubernetes të Hashicorp Consul
• Me çfarë u përballëm gjatë përdorimit të utilitarit Csync2
• Telegram-boti për Redmine. Si ta thjeshtoni jetën tuaj dhe të tjerëve

Burimi: habr.com