🥇Canary izvietošana Kubernetes #1: Gitlab CI

Mēs izmantosim Gitlab CI un manuālo GitOps, lai ieviestu un izmantotu Canary izvietošanu Kubernetes.

Raksti no šīs sērijas:

(Šis raksts)
Kanāriju izvietošana, izmantojot ArgoCI
Kanāriju izvietošana, izmantojot Istio
Kanāriju izvietošana, izmantojot Jenkins-X Istio Flagger

Mēs veiksim Canary izvietošanu manuāli, izmantojot GitOps un izveidojot/pārveidojot galvenos Kubernetes resursus. Šis raksts galvenokārt ir paredzēts ievadam ar to, kā izvietošana darbojas Kubernetes Canary, jo ir efektīvākas automatizācijas metodes, kuras mēs apsvērsim turpmākajos rakstos.

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

Kanāriju izvietošana

Izmantojot Canary stratēģiju, atjauninājumi vispirms tiek lietoti tikai lietotāju apakškopai. Izmantojot pārraudzību, žurnāla datus, manuālu testēšanu vai citus atgriezeniskās saites kanālus, laidiens tiek pārbaudīts, pirms tas tiek izlaists visiem lietotājiem.

Kubernetes izvietošana (pastāvīgs atjauninājums)

Kubernetes izvietošanas noklusējuma stratēģija ir nepārtraukta atjaunināšana, kurā tiek palaists noteikts skaits aplikumu ar jaunām attēlu versijām. Ja tie tika izveidoti bez problēmām, pāksti ar vecām attēlu versijām tiek pārtraukti un paralēli tiek izveidoti jauni podi.

GitOps

Šajā piemērā mēs izmantojam GitOps, jo mēs:

izmantojot Git kā vienotu patiesības avotu
mēs izmantojam Git Operations izveidei un izvietošanai (nav vajadzīgas citas komandas, izņemot git tagu/merge)

Piemērs

Pieņemsim labu praksi – lai būtu viens repozitorijs lietojumprogrammas kodam un viens infrastruktūrai.

Lietojumprogrammu repozitorijs

Šī ir ļoti vienkārša Python+Flask API, kas atgriež atbildi kā JSON. Mēs izveidosim pakotni, izmantojot GitlabCI, un nosūtīsim rezultātu Gitlab reģistram. Reģistrā mums ir divas dažādas laidiena versijas:

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

Vienīgā atšķirība starp tām ir izmaiņas atgrieztajā JSON failā. Mēs izmantojam šo lietojumprogrammu, lai pēc iespējas vienkāršāk vizualizētu, ar kuru versiju mēs sazināmies.

Infrastruktūras repozitorijs

Šajā rāceņā mēs caur GitlabCI izvietosim Kubernetes, .gitlab-ci.yml ir šāds:

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

Lai to palaistu pats, jums būs nepieciešams klasteris, varat izmantot Gcloud:

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

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

Jums vajag dakšiņu https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure un izveidojiet mainīgo KUBECONFIG GitlabCI, kurā būs piekļuves konfigurācija kubectl uz jūsu kopu.

Varat lasīt par to, kā iegūt akreditācijas datus klasterim (Gcloud) šeit.

Infrastruktūra Yaml

Infrastruktūras repozitorijā mums ir pakalpojums:

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

Un izvietošana iekšā 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

Un vēl viena izvietošana 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

Ņemiet vērā, ka lietotņu izvietošanai vēl nav definēta neviena kopija.

Veicot sākotnējo izvietošanu

Lai sāktu sākotnējo izvietošanu, varat manuāli palaist GitlabCI konveijeru galvenajā atzarā. Pēc tam kubectl jāizvada sekojošais:

Mēs redzam app izvietošana ar 10 replikām un app-canary ar 0. Ir arī LoadBalancer, no kura mēs varam piekļūt, izmantojot curl caur ārējo IP:

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

Mēs redzam, ka mūsu testa lietojumprogramma atgriež tikai “v1”.

Kanāriju izvietošanas izpilde

1. darbība: izlaidiet jaunu versiju dažiem lietotājiem

Mēs iestatījām kopiju skaitu uz 1 failā deploy-canary.yaml un jaunās versijas attēlā:

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

Failā deploy.yaml mēs mainījām kopiju skaitu uz 9:

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

Mēs virzām šīs izmaiņas repozitorijā, no kuras sāksies izvietošana (izmantojot GitlabCI), un rezultātā redzam:

Mūsu pakalpojums norādīs uz abiem izvietojumiem, jo abiem ir lietotņu atlasītājs. Kubernetes noklusējuma randomizācijas dēļ mums vajadzētu redzēt dažādas atbildes uz ~ 10% pieprasījumu:

Pašreizējais mūsu lietojumprogrammas stāvoklis (GitOps, kas ņemts no Git kā vienots patiesības avots) ir divu izvietojumu klātbūtne ar aktīvām replikām, viena katrai versijai.

~10% lietotāju iepazīst jaunu versiju un netīši to testē. Tagad ir pienācis laiks pārbaudīt, vai žurnālos un pārraudzības datos nav kļūdu, lai atrastu problēmas.

2. darbība: izlaidiet jauno versiju visiem lietotājiem

Mēs nolēmām, ka viss noritēja labi, un tagad mums ir jāizlaiž jaunā versija visiem lietotājiem. Lai to izdarītu, mēs vienkārši atjauninām deploy.yaml instalējot jaunu attēla versiju un reprodukciju skaitu, kas vienāds ar 10. In deploy-canary.yaml mēs iestatām repliku skaitu atpakaļ uz 0. Pēc izvietošanas rezultāts būs šāds:

Summējot

Manuāla izvietošanas palaišana šādā veidā palīdz saprast, cik viegli to var konfigurēt, izmantojot k8s. Tā kā Kubernetes ļauj atjaunināt visu, izmantojot API, šīs darbības var automatizēt, izmantojot skriptus.

Vēl viena lieta, kas jāievieš, ir testētāja ieejas punkts (LoadBalancer vai caur Ingress), caur kuru var piekļūt tikai jaunajai versijai. To var izmantot manuālai pārlūkošanai.

Nākamajos rakstos mēs apskatīsim citus automatizētus risinājumus, kas ievieš lielāko daļu mūsu paveiktā.