Kanarídreifing í Kubernetes #1: Gitlab CI

Við munum nota Gitlab CI og handvirka GitOps til að innleiða og nota Canary dreifingu í Kubernetes

Greinar úr þessari röð:

• (Þessi grein)
• Canary Deployment með ArgoCI
• Canary Deployment með Istio
• Canary Deployment með Jenkins-X Istio Flagger

Við munum framkvæma Canary dreifinguna handvirkt í gegnum GitOps og búa til/breyta helstu Kubernetes auðlindum. Þessi grein er fyrst og fremst ætluð til kynningar með því hvernig dreifing virkar á Kubernetes Canary, þar sem það eru skilvirkari aðferðir við sjálfvirkni, sem við munum íhuga í eftirfarandi greinum.

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

Kanaríútsetning

Með Kanarístefnunni er uppfærslum fyrst beitt á aðeins undirmengi notenda. Með vöktun, gagnaskrárgögnum, handvirkum prófunum eða öðrum endurgjöfarrásum er útgáfan prófuð áður en hún er gefin út til allra notenda.

Kubernetes dreifing (uppfærsla)

Sjálfgefin stefna fyrir Kubernetes Deployment er rúllandi uppfærsla, þar sem ákveðinn fjöldi fræbelgja er settur af stað með nýjum útgáfum af myndunum. Ef þeir voru búnir til án vandræða er belg með gömlum útgáfum af myndum hætt og nýir belg eru búnir til samhliða.

gitops

Við notum GitOps í þessu dæmi vegna þess að við:

• að nota Git sem eina uppsprettu sannleikans
• við notum Git Operations fyrir byggingu og dreifingu (engar skipanir aðrar en git tag/merge eru nauðsynlegar)

Dæmi

Við skulum taka góða æfingu - að hafa eina geymslu fyrir forritakóða og eina fyrir innviði.

Umsóknargeymsla

Þetta er mjög einfalt Python+Flask API sem skilar svari sem JSON. Við munum byggja pakkann í gegnum GitlabCI og ýta niðurstöðunni í Gitlab Registry. Í skránni höfum við tvær mismunandi útgáfur:

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

Eini munurinn á milli þeirra er breytingin á JSON skránni sem skilað er. Við notum þetta forrit til að sjá eins auðveldlega og mögulegt er hvaða útgáfu við erum í samskiptum við.

Innviðageymsla

Í þessari rófu munum við dreifa í gegnum GitlabCI til Kubernetes, .gitlab-ci.yml lítur svona út:

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

Til að keyra það sjálfur þarftu klasa, þú getur notað Gcloud:

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

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

Þú þarft að punga https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure og búa til breytu KUBECONFIG í GitlabCI, sem mun innihalda stillingar fyrir aðgang kubectl til þyrpingarinnar þinnar.

Þú getur lesið um hvernig á að fá skilríki fyrir klasa (Gcloud) hér.

Innviðir Yaml

Í innviðageymslunni höfum við þjónustu:

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

Og dreifing í 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

Og önnur dreifing í 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

Athugaðu að app-deploy hefur engar eftirmyndir skilgreindar ennþá.

Framkvæmir fyrstu dreifingu

Til að hefja upphaflega dreifinguna geturðu ræst GitlabCI leiðsluna handvirkt á aðalútibúinu. Eftir það kubectl ætti að gefa út eftirfarandi:

Við sjáum app dreifing með 10 eftirlíkingum og app-kanarí með 0. Það er líka LoadBalancer sem við getum nálgast í gegnum curl í gegnum ytri IP:

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

Við sjáum að prófunarforritið okkar skilar aðeins „v1“.

Framkvæmir kanarídreifingu

Skref 1: gefa út nýja útgáfu fyrir suma notendur

Við stilltum fjölda eftirmynda á 1 í deploy-canary.yaml skránni og nýju útgáfumyndinni:

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

Í skrá deploy.yaml við breyttum fjölda eftirmynda í 9:

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

Við ýtum þessum breytingum á geymsluna sem dreifingin mun hefjast frá (í gegnum GitlabCI) og sjáum í kjölfarið:

Þjónustan okkar mun benda á báðar uppsetningarnar þar sem báðar eru með forritavalið. Vegna sjálfgefna slembivals Kubernetes ættum við að sjá mismunandi svör fyrir ~10% beiðna:

Núverandi staða forritsins okkar (GitOps, tekið úr Git as a Single Source Of Truth) er tilvist tveggja dreifinga með virkum eftirmyndum, ein fyrir hverja útgáfu.

~10% notenda kynnast nýrri útgáfu og prófa hana óviljandi. Nú er kominn tími til að athuga hvort villur séu í annálum og eftirlitsgögnum til að finna vandamál.

Skref 2: Gefa út nýju útgáfuna fyrir alla notendur

Við ákváðum að allt gengi vel og nú þurfum við að setja nýju útgáfuna út fyrir alla notendur. Til að gera þetta uppfærum við einfaldlega deploy.yaml uppsetning nýrrar útgáfu af myndinni og fjöldi eftirmynda sem jafngildir 10. Í deploy-canary.yaml við setjum fjölda eftirmynda aftur á 0. Eftir uppsetningu verður niðurstaðan sem hér segir:

Toppur upp

Fyrir mig hjálpar það að keyra uppsetninguna handvirkt á þennan hátt til að skilja hversu auðvelt er að stilla hana með k8s. Þar sem Kubernetes gerir þér kleift að uppfæra allt í gegnum API er hægt að gera þessi skref sjálfvirk í gegnum forskriftir.

Annað sem þarf að útfæra er inngangsstaður prófunaraðila (LoadBalancer eða í gegnum Ingress) þar sem aðeins er hægt að nálgast nýju útgáfuna. Það er hægt að nota til handvirkrar vafra.

Í framtíðargreinum munum við skoða aðrar sjálfvirkar lausnir sem útfæra flest það sem við höfum gert.

Lestu einnig aðrar greinar á blogginu okkar:

• Til hvers leiddi flutningur frá ClickHouse án heimildar til ClickHouse með heimild?
• Byggja kraftmiklar einingar fyrir Nginx
• Uppfærðu nxs-build-tools - aðstoðarmaður við að búa til deb og rpm pakka
• Kynning á Kubernetes heimild Hashicorp Consul
• Það sem við þurftum að horfast í augu við þegar við notuðum Csync2 tólið
• Telegram láni fyrir Redmine. Hvernig á að einfalda lífið fyrir sjálfan þig og aðra

Heimild: www.habr.com