🥇Canary juurutamine Kubernetesis #1: Gitlab CI

Kasutame Kubernetesis Canary juurutamise juurutamiseks ja kasutamiseks Gitlab CI-d ja käsitsi GitOpsi

Artiklid sellest sarjast:

(See artikkel)
Kanaari juurutamine ArgoCI abil
Kanaari juurutamine Istio abil
Kanaari juurutamine Jenkins-X Istio Flaggeri abil

Teostame Canary juurutamise käsitsi GitOpsi kaudu ja luues/muutes peamisi Kubernetese ressursse. See artikkel on mõeldud eelkõige sissejuhatuseks kuidas juurutamine Kubernetes Canarys töötab, kuna seal on tõhusamaid automatiseerimismeetodeid, mida käsitleme järgmistes artiklites.

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

Kanaari juurutamine

Canary strateegia puhul rakendatakse värskendusi esmalt ainult kasutajate alamhulgale. Järelevalve, logiandmete, käsitsi testimise või muude tagasisidekanalite kaudu testitakse väljalaset enne, kui see kõigile kasutajatele avaldatakse.

Kubernetese juurutamine (jooksev värskendus)

Kubernetese juurutamise vaikestrateegia on jooksev värskendus, mille puhul käivitatakse piltide uute versioonidega teatud arv kaustasid. Kui need loodi probleemideta, lõpetatakse piltide vanade versioonidega kaustad ja paralleelselt luuakse uued kaustad.

GitOps

Kasutame selles näites GitOpsi, kuna:

kasutades Gitit ühe tõeallikana
me kasutame koostamiseks ja juurutamiseks Git Operationsi (vaja pole muid käske peale git tag/merge)

Näide

Võtame hea tava – et oleks üks hoidla rakenduse koodi ja üks infrastruktuuri jaoks.

Rakenduste hoidla

See on väga lihtne Python+Flask API, mis tagastab vastuse JSON-ina. Ehitame paketi GitlabCI kaudu ja edastame tulemuse Gitlabi registrisse. Registris on meil kaks erinevat väljalaskeversiooni:

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

Ainus erinevus nende vahel on muudatus tagastatud JSON-failis. Kasutame seda rakendust, et võimalikult lihtsalt visualiseerida, millise versiooniga me suhtleme.

Infrastruktuuri hoidla

Selles naeris juurutame GitlabCI kaudu Kubernetes, .gitlab-ci.yml on järgmine:

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

Selle ise käitamiseks vajate klastrit, saate kasutada Gcloudi:

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

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

Sa pead hargima https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure ja luua muutuja KUBECONFIG GitlabCI-s, mis sisaldab juurdepääsu konfiguratsiooni kubectl teie klastrisse.

Saate lugeda klastri mandaatide hankimise kohta (Gcloud) siin.

Infrastruktuur Yaml

Infrastruktuuri hoidlas on meil teenus:

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

Ja kasutuselevõtt 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

Ja veel üks kasutuselevõtt 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

Pange tähele, et rakenduse juurutamisel pole veel ühtegi koopiat määratletud.

Esialgse juurutamise teostamine

Esialgse juurutamise alustamiseks saate GitlabCI konveieri põhiharus käsitsi käivitada. Pärast seda kubectl peaks väljastama järgmise:

Me näeme app juurutamine 10 koopiaga ja app-canary 0-ga. Samuti on olemas LoadBalancer, kust pääseme juurde curl välise IP kaudu:

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

Näeme, et meie testrakendus tagastab ainult "v1".

Kanaari juurutamise elluviimine

1. samm: vabastage mõne kasutaja jaoks uus versioon

Määrasime failis deploy-canary.yaml ja uue versiooni kujutises koopiate arvuks 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

Failis deploy.yaml muutsime koopiate arvu 9-le:

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

Lükkame need muudatused hoidlasse, millest juurutamine algab (GitlabCI kaudu) ja näeme selle tulemusel:

Meie teenus osutab mõlemale juurutusviisile, kuna mõlemal on rakenduse valija. Kubernetese vaikejuhustamise tõttu peaksime ~10% päringutest nägema erinevaid vastuseid:

Meie rakenduse praegune olek (GitOps, võetud Gitist kui ühtne tõeallikas) on kahe juurutuse olemasolu koos aktiivsete koopiatega, üks iga versiooni jaoks.

~10% kasutajatest saavad uue versiooniga tuttavaks ja testivad seda tahtmatult. Nüüd on õige aeg kontrollida, kas logides ja seireandmetes on vigu, et leida probleeme.

2. samm: avaldage uus versioon kõigile kasutajatele

Otsustasime, et kõik läks hästi ja nüüd peame uue versiooni kõigile kasutajatele levitama. Selleks värskendame lihtsalt deploy.yaml pildi uue versiooni installimine ja koopiate arv on 10. In deploy-canary.yaml määrasime koopiate arvuks tagasi 0. Pärast juurutamist on tulemus järgmine:

Kokkuvõtteks

Minu jaoks aitab juurutuse käsitsi käivitamine sel viisil mõista, kui hõlpsalt saab seda k8s-i abil konfigureerida. Kuna Kubernetes võimaldab teil API kaudu kõike värskendada, saab neid samme skriptide abil automatiseerida.

Teine asi, mis vajab juurutamist, on testeri sisenemispunkt (LoadBalancer või Ingressi kaudu), mille kaudu pääseb ligi ainult uuele versioonile. Seda saab kasutada käsitsi sirvimiseks.

Edaspidistes artiklites uurime teisi automatiseeritud lahendusi, mis rakendavad enamikku meie tehtust.

Loe ka teisi meie ajaveebi artikleid:

Allikas: www.habr.com

Kanaari juurutamine Kubernetesis nr 1: Gitlab CI