🥇Canary Deployment sa Kubernetes #1: Gitlab CI

Gagamitin namin ang Gitlab CI at manu-manong GitOps para ipatupad at gamitin ang Canary deployment sa Kubernetes

Mga artikulo mula sa seryeng ito:

(Ang artikulong ito)
Canary Deployment gamit ang ArgoCI
Canary Deployment gamit ang Istio
Canary Deployment gamit ang Jenkins-X Istio Flagger

Gagawin namin ang Canary deployment nang manu-mano sa pamamagitan ng GitOps at paggawa/pagbabago ng pangunahing mapagkukunan ng Kubernetes. Ang artikulong ito ay pangunahing inilaan para sa pagpapakilala sa kung paano gumagana ang deployment sa Kubernetes Canary, dahil may mga mas epektibong paraan ng automation, na isasaalang-alang namin sa mga sumusunod na artikulo.

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

Pag-deploy ng Canary

Gamit ang diskarte sa Canary, unang inilapat ang mga update sa isang subset lamang ng mga user. Sa pamamagitan ng pagsubaybay, data ng log, manu-manong pagsubok, o iba pang mga channel ng feedback, sinusubok ang release bago ito i-release sa lahat ng user.

Kubernetes Deployment (rolling update)

Ang default na diskarte para sa Kubernetes Deployment ay rolling-update, kung saan ang isang tiyak na bilang ng mga pod ay inilunsad na may mga bagong bersyon ng mga larawan. Kung ginawa ang mga ito nang walang problema, ang mga pod na may mga lumang bersyon ng mga imahe ay wawakasan, at ang mga bagong pod ay gagawin nang magkatulad.

GitOps

Ginagamit namin ang GitOps sa halimbawang ito dahil kami:

gamit ang Git bilang isang pinagmumulan ng katotohanan
ginagamit namin ang Git Operations para sa pagbuo at pag-deploy (walang mga utos maliban sa git tag/merge ang kailangan)

Halimbawa

Magsagawa tayo ng isang mahusay na kasanayan - upang magkaroon ng isang repository para sa application code at isa para sa imprastraktura.

Imbakan ng aplikasyon

Ito ay isang napakasimpleng Python+Flask API na nagbabalik ng tugon bilang JSON. Bubuo kami ng package sa pamamagitan ng GitlabCI at itulak ang resulta sa Gitlab Registry. Sa registry mayroon kaming dalawang magkaibang bersyon ng paglabas:

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

Ang tanging pagkakaiba sa pagitan nila ay ang pagbabago sa ibinalik na JSON file. Ginagamit namin ang application na ito upang mailarawan nang madali hangga't maaari kung saang bersyon kami nakikipag-usap.

Imbakan ng imprastraktura

Sa singkamas na ito kami ay magde-deploy sa pamamagitan ng GitlabCI sa Kubernetes, .gitlab-ci.yml ganito ang hitsura nito:

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

Upang patakbuhin ito nang mag-isa, kakailanganin mo ng isang kumpol, maaari mong gamitin ang Gcloud:

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

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

Kailangan mong tinidor https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure at lumikha ng isang variable KUBECONFIG sa GitlabCI, na maglalaman ng config para sa pag-access kubectl sa iyong kumpol.

Maaari mong basahin ang tungkol sa kung paano makakuha ng mga kredensyal para sa isang cluster (Gcloud) dito.

Imprastraktura Yaml

Sa imbakan ng imprastraktura mayroon kaming serbisyo:

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

At deployment sa 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

At isa pang deployment sa 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

Tandaan na ang app-deploy ay wala pang anumang mga replika na tinukoy.

Nagsasagawa ng paunang pag-deploy

Upang simulan ang paunang deployment, maaari mong simulan ang GitlabCI pipeline nang manu-mano sa master branch. Pagkatapos kubectl dapat ilabas ang sumusunod:

Nakikita namin app deployment na may 10 replicas at app-canary na may 0. Mayroon ding LoadBalancer kung saan maa-access natin sa pamamagitan ng curl sa pamamagitan ng Panlabas na IP:

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

Nakikita namin na ang aming pagsubok na application ay nagbabalik lamang ng "v1".

Isinasagawa ang pag-deploy ng Canary

Hakbang 1: maglabas ng bagong bersyon para sa ilang user

Itinakda namin ang bilang ng mga replika sa 1 sa deploy-canary.yaml file at sa bagong bersyon ng imahe:

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

Nasa file deploy.yaml binago namin ang bilang ng mga replika sa 9:

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

Itinutulak namin ang mga pagbabagong ito sa repositoryo kung saan magsisimula ang deployment (sa pamamagitan ng GitlabCI) at makita bilang resulta:

Ang aming Serbisyo ay ituturo sa parehong mga deployment, dahil pareho ang tagapili ng app. Dahil sa default na randomization ng Kubernetes, dapat tayong makakita ng iba't ibang mga tugon para sa ~10% ng mga kahilingan:

Ang kasalukuyang estado ng aming aplikasyon (GitOps, kinuha mula sa Git bilang Isang Pinagmulan ng Katotohanan) ay ang pagkakaroon ng dalawang deployment na may aktibong mga replika, isa para sa bawat bersyon.

~10% ng mga user ay naging pamilyar sa isang bagong bersyon at hindi sinasadyang subukan ito. Ngayon na ang oras upang suriin ang mga error sa mga log at pagsubaybay sa data upang makahanap ng mga problema.

Hakbang 2: Ilabas ang bagong bersyon sa lahat ng user

Napagpasyahan namin na naging maayos ang lahat at ngayon kailangan naming ilunsad ang bagong bersyon sa lahat ng user. Para magawa ito, nag-a-update lang kami deploy.yaml pag-install ng bagong bersyon ng imahe at ang bilang ng mga replika na katumbas ng 10. Sa deploy-canary.yaml itinakda namin ang bilang ng mga replika pabalik sa 0. Pagkatapos ng pag-deploy, ang magiging resulta ay ang mga sumusunod:

Lagom

Para sa akin, ang pagpapatakbo ng deployment nang manu-mano sa paraang ito ay nakakatulong na maunawaan kung gaano kadali itong mai-configure gamit ang k8s. Dahil pinapayagan ka ng Kubernetes na i-update ang lahat sa pamamagitan ng API, maaaring i-automate ang mga hakbang na ito sa pamamagitan ng mga script.

Ang isa pang bagay na kailangang ipatupad ay isang tester entry point (LoadBalancer o sa pamamagitan ng Ingress) kung saan ang bagong bersyon lamang ang maa-access. Maaari itong magamit para sa manu-manong pag-browse.

Sa mga artikulo sa hinaharap, titingnan namin ang iba pang mga awtomatikong solusyon na nagpapatupad ng karamihan sa aming nagawa.

Basahin din ang iba pang mga artikulo sa aming blog:

Pinagmulan: www.habr.com

Canary Deployment sa Kubernetes #1: Gitlab CI