Vendosja e Kanarinave në Kubernetes #1: Gitlab CI

Ne do të përdorim Gitlab CI dhe GitOps manuale për të zbatuar dhe përdorur vendosjen Canary në Kubernetes

Artikuj nga kjo seri:

• (Ky artikull)
• Shpërndarja e Kanarit duke përdorur ArgoCI
• Shpërndarja e Kanarinave duke përdorur Istio
• Zbatimi i Kanarit duke përdorur Jenkins-X Istio Flagger

Ne do të kryejmë vendosjen Canary manualisht nëpërmjet GitOps dhe duke krijuar/modifikuar burimet kryesore të Kubernetes. Ky artikull është menduar kryesisht për hyrje me mënyrën se si funksionon vendosja në Kubernetes Canary, pasi ka metoda më efektive të automatizimit, të cilat do t'i shqyrtojmë në artikujt vijues.

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

Vendosja e Kanarinave

Me strategjinë Canary, përditësimet aplikohen fillimisht vetëm për një nëngrup përdoruesish. Nëpërmjet monitorimit, të dhënave të regjistrit, testimit manual ose kanaleve të tjera të reagimit, lëshimi testohet përpara se të lëshohet për të gjithë përdoruesit.

Vendosja e Kubernetes (përditësim i vazhdueshëm)

Strategjia e parazgjedhur për Kubernetes Deployment është përditësimi i përsëritur, ku një numër i caktuar pods lëshohen me versione të reja të imazheve. Nëse ato u krijuan pa probleme, podet me versionet e vjetra të imazheve mbyllen dhe podet e reja krijohen paralelisht.

GitOps

Ne përdorim GitOps në këtë shembull sepse ne:

• duke përdorur Git si një burim të vetëm të së vërtetës
• ne përdorim Operacionet Git për ndërtimin dhe vendosjen (nuk nevojiten komanda të tjera përveç etiketës/bashkimit të git)

Shembull

Le të marrim një praktikë të mirë - të kemi një depo për kodin e aplikacionit dhe një për infrastrukturën.

Depoja e aplikacionit

Ky është një API shumë i thjeshtë Python+Flask që kthen një përgjigje si JSON. Ne do të ndërtojmë paketën përmes GitlabCI dhe do ta shtyjmë rezultatin në Regjistrin Gitlab. Në regjistër kemi dy versione të ndryshme të lëshimit:

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

Dallimi i vetëm midis tyre është ndryshimi në skedarin JSON të kthyer. Ne e përdorim këtë aplikacion për të vizualizuar sa më lehtë se me cilin version po komunikojmë.

Depoja e infrastrukturës

Në këtë rrepë ne do të vendosemi nëpërmjet GitlabCI në Kubernetes, .gitlab-ci.yml duket si kjo:

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 ekzekutuar vetë do t'ju duhet një grup, 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 duhet të piruni https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure dhe krijoni një ndryshore KUBECONFIG në GitlabCI, i cili do të përmbajë konfigurimin për akses kubectl në grupin tuaj.

Mund të lexoni se si të merrni kredencialet për një grup (Gcloud) këtu.

Infrastruktura Yaml

Në depon e infrastrukturës kemi shërbimin:

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

Dhe vendosja 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 vendosje 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 vendosja e aplikacionit nuk ka ende asnjë kopje të përcaktuar.

Kryerja e vendosjes fillestare

Për të nisur vendosjen fillestare, mund të nisni manualisht tubacionin GitlabCI në degën kryesore. Pas kësaj kubectl duhet të nxjerrë sa vijon:

Ne shohim app vendosje me 10 kopje dhe app-canary me 0. Ekziston edhe një LoadBalancer nga i cili mund të hyjmë përmes curl përmes IP-së së jashtme:

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

Ne shohim që aplikacioni ynë i testimit kthen vetëm "v1".

Ekzekutimi i vendosjes së Kanarit

Hapi 1: lëshoni një version të ri për disa përdorues

Ne vendosëm numrin e kopjeve 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ë dosje deploy.yaml ne ndryshuam numrin e kopjeve në 9:

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

Ne i shtyjmë këto ndryshime në depo nga e cila do të fillojë vendosja (nëpërmjet GitlabCI) dhe shohim si rezultat:

Shërbimi ynë do të tregojë për të dy vendosjet, pasi të dyja kanë përzgjedhësin e aplikacionit. Për shkak të rastësisë së paracaktuar të Kubernetes, ne duhet të shohim përgjigje të ndryshme për ~ 10% të kërkesave:

Gjendja aktuale e aplikacionit tonë (GitOps, marrë nga Git si një burim i vetëm i së vërtetës) është prania e dy vendosjeve me kopje aktive, një për çdo version.

~10% e përdoruesve njihen me një version të ri dhe e testojnë pa dashje. Tani është koha për të kontrolluar për gabime në regjistrat dhe të dhënat e monitorimit për të gjetur probleme.

Hapi 2: Lëshoni versionin e ri për të gjithë përdoruesit

Ne vendosëm që gjithçka shkoi mirë dhe tani duhet të prezantojmë versionin e ri për të gjithë përdoruesit. Për ta bërë këtë, ne thjesht përditësojmë deploy.yaml instalimi i një versioni të ri të imazhit dhe numri i kopjeve të barabarta me 10. In deploy-canary.yaml ne vendosëm përsëri numrin e kopjeve në 0. Pas vendosjes, rezultati do të jetë si më poshtë:

Duke përmbledhur

Për mua, ekzekutimi manual i vendosjes në këtë mënyrë ndihmon për të kuptuar se sa lehtë mund të konfigurohet duke përdorur k8s. Meqenëse Kubernetes ju lejon të përditësoni gjithçka përmes një API, këto hapa mund të automatizohen përmes skripteve.

Një tjetër gjë që duhet të zbatohet është një pikë hyrëse e testuesit (LoadBalancer ose nëpërmjet Ingress) përmes së cilës mund të aksesohet vetëm versioni i ri. Mund të përdoret për shfletim manual.

Në artikujt e ardhshëm, ne do të shqyrtojmë zgjidhje të tjera të automatizuara që zbatojnë pjesën më të madhe të asaj që kemi bërë.

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

• Në çfarë çoi migrimi nga ClickHouse pa autorizim në ClickHouse me autorizim?
• Ndërtimi i moduleve dinamike për Nginx
• Përditëso nxs-build-tools - një asistent në ndërtimin e paketave deb dhe rpm
• Hyrje në Autorizimin Kubernetes të Konsullit Hashicorp
• Me çfarë duhej të përballeshim kur përdornim programin Csync2
• Telegram bot për Redmine. Si ta thjeshtoni jetën për veten dhe të tjerët

Burimi: www.habr.com