🥇Canaryn käyttöönotto Kubernetes #1:ssä: Gitlab CI

Käytämme Gitlab CI:tä ja manuaalista GitOpsia Canaryn käyttöönoton toteuttamiseen ja käyttämiseen Kubernetesissa

Tämän sarjan artikkelit:

(Tämä artikkeli)
Canary Deployment käyttäen ArgoCI
Canary Deployment Istion avulla
Canary Deployment Jenkins-X Istio Flaggerin avulla

Suoritamme Canaryn käyttöönoton manuaalisesti GitOpsin kautta ja luomme/muokkaamme Kubernetesin pääresursseja. Tämä artikkeli on tarkoitettu ensisijaisesti esittelyyn miten käyttöönotto toimii Kubernetes Canaryssa, koska on olemassa tehokkaampia automaatiomenetelmiä, joita tarkastelemme seuraavissa artikkeleissa.

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

Kanarian käyttöönotto

Canary-strategiassa päivitykset koskevat ensin vain osaa käyttäjiä. Valvonnan, lokitietojen, manuaalisen testauksen tai muiden palautekanavien avulla julkaisua testataan ennen kuin se julkaistaan kaikille käyttäjille.

Kubernetes-käyttöönotto (jatkuva päivitys)

Kubernetes Deploymentin oletusstrategia on jatkuva päivitys, jossa tietty määrä podeja käynnistetään kuvien uusilla versioilla. Jos ne luotiin ilman ongelmia, vanhoja kuvien versioita sisältävät podit lopetetaan ja uudet podit luodaan rinnakkain.

GitOps

Käytämme GitOpsia tässä esimerkissä, koska:

käyttämällä Gitiä yhtenä totuuden lähteenä
käytämme Git Operations -toimintoja rakentamiseen ja käyttöönottoon (muita komentoja ei tarvita kuin git tag/merge)

Esimerkki

Otetaanpa hyvä käytäntö - yksi arkisto sovelluskoodille ja yksi infrastruktuurille.

Sovellusarkisto

Tämä on hyvin yksinkertainen Python+Flask API, joka palauttaa vastauksen JSON-muodossa. Rakennamme paketin GitlabCI:n kautta ja välitämme tuloksen Gitlabin rekisteriin. Meillä on rekisterissä kaksi erilaista julkaisuversiota:

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

Ainoa ero niiden välillä on muutos palautetussa JSON-tiedostossa. Käytämme tätä sovellusta visualisoidaksemme mahdollisimman helposti, minkä version kanssa kommunikoimme.

Infrastruktuurin arkisto

Tässä nauriissa otamme käyttöön GitlabCI:n kautta Kubernetesiin, .gitlab-ci.yml on seuraava:

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

Jos haluat suorittaa sen itse, tarvitset klusterin, voit käyttää Gcloudia:

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

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

Sinun täytyy haarukka https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure ja luo muuttuja KUBECONFIG GitlabCI:ssä, joka sisältää pääsyn asetukset kubectl klusteriisi.

Voit lukea klusterin tunnistetietojen hankkimisesta (Gcloud) täällä.

Infrastruktuuri Yaml

Infrastruktuuriarkistossa meillä on palvelu:

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

Ja käyttöönotto sisää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

Ja toinen käyttöönotto 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

Huomaa, että app-deploy ei ole vielä määritetty replikoita.

Alkukäyttöönotto suoritetaan

Aloita ensimmäinen käyttöönotto käynnistämällä GitlabCI-putkilinjan manuaalisesti päähaarassa. Sen jälkeen kubectl pitäisi tulostaa seuraavaa:

Me näemme app käyttöönotto 10 replikalla ja app-canary 0. On myös LoadBalancer, josta pääsemme curl Ulkoisen IP:n kautta:

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

Näemme, että testisovelluksemme palauttaa vain "v1".

Suoritetaan Canarian käyttöönottoa

Vaihe 1: julkaise uusi versio joillekin käyttäjille

Asetamme replikoiden lukumääräksi 1 deploy-canary.yaml-tiedostossa ja uudessa version kuvassa:

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

Tiedostossa deploy.yaml muutimme kopioiden lukumäärän 9:ksi:

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

Siirrämme nämä muutokset arkistoon, josta käyttöönotto alkaa (GitlabCI:n kautta), ja näemme tuloksena:

Palvelumme osoittaa molempiin käyttöönottoihin, koska molemmissa on sovelluksen valitsin. Kubernetesin oletussatunnaistuksen vuoksi meidän pitäisi nähdä erilaisia vastauksia ~10 %:lle pyynnöistä:

Sovelluksemme (GitOps, otettu Gitistä yhtenä totuuden lähteenä) nykyinen tila on kaksi käyttöönottoa aktiivisilla replikoilla, yksi jokaiselle versiolle.

~10 % käyttäjistä tutustuu uuteen versioon ja testaa sitä tahattomasti. Nyt on aika tarkistaa lokien ja seurantatiedon virheet ongelmien löytämiseksi.

Vaihe 2: Julkaise uusi versio kaikille käyttäjille

Päätimme, että kaikki meni hyvin, ja nyt meidän on julkaistava uusi versio kaikille käyttäjille. Tätä varten vain päivitämme deploy.yaml kuvan uuden version asentaminen ja kopioiden lukumäärä on 10. In deploy-canary.yaml asetamme replikoiden lukumääräksi takaisin 0. Käyttöönoton jälkeen tulos on seuraava:

Yhteenvetona

Minulle käyttöönoton suorittaminen manuaalisesti tällä tavalla auttaa ymmärtämään, kuinka helposti se voidaan määrittää k8s:lla. Koska Kubernetes antaa sinun päivittää kaiken API:n kautta, nämä vaiheet voidaan automatisoida komentosarjojen avulla.

Toinen asia, joka on otettava käyttöön, on testaajan sisääntulopiste (LoadBalancer tai Ingressin kautta), jonka kautta pääsee vain uuteen versioon. Sitä voidaan käyttää manuaaliseen selaamiseen.

Tulevissa artikkeleissa tutustumme muihin automatisoituihin ratkaisuihin, jotka toteuttavat suurimman osan tekemästämme.

Lue myös muut artikkelit blogistamme:

Lähde: will.com

Canaryn käyttöönotto Kubernetesissa #1: Gitlab CI