Implementarea Canary în Kubernetes #1: Gitlab CI

Vom folosi Gitlab CI și GitOps manual pentru a implementa și utiliza implementarea Canary în Kubernetes

Articole din această serie:

• (Acest articol)
• Implementarea Canary folosind ArgoCI
• Implementarea Canary folosind Istio
• Implementarea Canary folosind Jenkins-X Istio Flagger

Vom efectua manual implementarea Canary prin GitOps și crearea/modificarea principalelor resurse Kubernetes. Acest articol este destinat în primul rând pentru introducere cu modul în care funcționează implementarea în Kubernetes Canary, deoarece există metode mai eficiente de automatizare, pe care le vom lua în considerare în articolele următoare.

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

Desfăşurare Canary

Cu strategia Canary, actualizările sunt aplicate mai întâi doar unui subset de utilizatori. Prin monitorizare, date de jurnal, testare manuală sau alte canale de feedback, versiunea este testată înainte de a fi lansată tuturor utilizatorilor.

Implementarea Kubernetes (actualizare continuă)

Strategia implicită pentru Kubernetes Deployment este actualizarea continuă, în care un anumit număr de pod-uri sunt lansate cu noi versiuni ale imaginilor. Dacă au fost create fără probleme, podurile cu versiuni vechi de imagini sunt terminate, iar podurile noi sunt create în paralel.

GitOps

Folosim GitOps în acest exemplu deoarece:

• folosind Git ca sursă unică de adevăr
• folosim operațiuni Git pentru construirea și implementarea (nu sunt necesare alte comenzi decât git tag/merge)

Exemplu

Să luăm o practică bună - să avem un depozit pentru codul aplicației și unul pentru infrastructură.

Depozitul de aplicații

Acesta este un API Python+Flask foarte simplu, care returnează un răspuns ca JSON. Vom construi pachetul prin GitlabCI și vom împinge rezultatul în Registrul Gitlab. În registru avem două versiuni de lansare diferite:

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

Singura diferență dintre ele este modificarea fișierului JSON returnat. Folosim această aplicație pentru a vizualiza cât mai ușor cu ce versiune comunicăm.

Depozitul de infrastructură

În acest nap vom implementa prin GitlabCI în Kubernetes, .gitlab-ci.yml este după cum urmează:

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

Pentru a-l rula singur, veți avea nevoie de un cluster, puteți utiliza Gcloud:

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

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

Trebuie să bifurcați https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure și creați o variabilă KUBECONFIG în GitlabCI, care va conține configurația pentru acces kubectl către clusterul tău.

Puteți citi despre cum să obțineți acreditări pentru un cluster (Gcloud) aici.

Infrastructură Yaml

În depozitul de infrastructură avem serviciul:

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

Și desfășurare î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

Și încă o desfășurare î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

Rețineți că app-deploy nu are încă definite replici.

Efectuarea implementării inițiale

Pentru a începe implementarea inițială, puteți porni canalul GitlabCI manual pe ramura principală. După care kubectl ar trebui să scoată următoarele:

V-om vedea app implementare cu 10 replici și app-canary cu 0. Există și un LoadBalancer de la care putem accesa prin curl prin IP extern:

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

Vedem că aplicația noastră de testare returnează doar „v1”.

Executarea implementării Canary

Pasul 1: lansați o nouă versiune pentru unii utilizatori

Am setat numărul de replici la 1 în fișierul deploy-canary.yaml și imaginea versiunii noi:

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 dosar deploy.yaml am schimbat numărul de replici la 9:

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

Împingem aceste modificări în depozitul de la care va începe implementarea (prin GitlabCI) și vedem ca rezultat:

Serviciul nostru va indica ambele implementări, deoarece ambele au selectorul de aplicații. Datorită randomizării prestabilite Kubernetes, ar trebui să vedem răspunsuri diferite pentru ~10% din solicitări:

Starea actuală a aplicației noastre (GitOps, preluată din Git ca sursă unică de adevăr) este prezența a două implementări cu replici active, câte una pentru fiecare versiune.

~10% dintre utilizatori se familiarizează cu o nouă versiune și o testează neintenționat. Acum este momentul să verificați erorile în jurnalele și datele de monitorizare pentru a găsi probleme.

Pasul 2: Lansați noua versiune pentru toți utilizatorii

Am decis că totul a mers bine și acum trebuie să lansăm noua versiune pentru toți utilizatorii. Pentru a face acest lucru, pur și simplu actualizăm deploy.yaml instalarea unei noi versiuni a imaginii și a numărului de replici egal cu 10. În deploy-canary.yaml setăm numărul de replici înapoi la 0. După implementare, rezultatul va fi următorul:

Rezumând

Pentru mine, rularea manuală a implementării în acest fel ajută la înțelegerea cât de ușor poate fi configurată folosind k8s. Deoarece Kubernetes vă permite să actualizați totul printr-un API, acești pași pot fi automatizați prin scripturi.

Un alt lucru care trebuie implementat este un punct de intrare al testerului (LoadBalancer sau prin Ingress) prin care poate fi accesată doar noua versiune. Poate fi folosit pentru navigarea manuală.

În articolele viitoare, vom verifica și alte soluții automate care implementează majoritatea a ceea ce am făcut.

Citiți și alte articole de pe blogul nostru:

• La ce a dus migrarea de la ClickHouse fără autorizație la ClickHouse cu autorizare?
• Construirea de module dinamice pentru Nginx
• Actualizați nxs-build-tools - un asistent în construirea pachetelor deb și rpm
• Introducere în autorizația Kubernetes a Hashicorp Consul
• Ce a trebuit să ne confruntăm când folosim utilitarul Csync2
• Botul Telegram pentru Redmine. Cum să simplifici viața pentru tine și pentru alții

Sursa: www.habr.com