🥇Desplegament de Canary a Kubernetes #1: Gitlab CI

Utilitzarem Gitlab CI i GitOps manuals per implementar i utilitzar el desplegament de Canary a Kubernetes

Articles d'aquesta sèrie:

(Aquest article)
Desplegament de Canary mitjançant ArgoCI
Desplegament de Canary mitjançant Istio
Desplegament de Canary mitjançant Jenkins-X Istio Flagger

Realitzarem el desplegament de Canary manualment a través de GitOps i creant/modificant els principals recursos de Kubernetes. Aquest article està destinat principalment a la introducció amb com funciona el desplegament a Kubernetes Canary, ja que hi ha mètodes d'automatització més efectius, que tindrem en compte en els articles següents.

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

Desplegament Canari

Amb l'estratègia Canary, les actualitzacions s'apliquen primer només a un subconjunt d'usuaris. Mitjançant la supervisió, les dades de registre, les proves manuals o altres canals de comentaris, la versió es prova abans de ser llançada a tots els usuaris.

Desplegament de Kubernetes (actualització continuada)

L'estratègia predeterminada per a Kubernetes Deployment és l'actualització continua, on es llança un nombre determinat de pods amb noves versions de les imatges. Si es van crear sense problemes, els pods amb versions antigues d'imatges s'acaben i es creen nous pods en paral·lel.

GitOps

Utilitzem GitOps en aquest exemple perquè:

utilitzant Git com a font única de veritat
fem servir les operacions de Git per a la creació i el desplegament (no calen ordres que no siguin git tag/merge)

Exemple

Prenem una bona pràctica: tenir un dipòsit per al codi de l'aplicació i un altre per a la infraestructura.

Repositori d'aplicacions

Aquesta és una API Python+Flask molt senzilla que retorna una resposta com a JSON. Construirem el paquet mitjançant GitlabCI i enviarem el resultat al registre de Gitlab. Al registre tenim dues versions de llançament diferents:

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

L'única diferència entre ells és el canvi en el fitxer JSON retornat. Utilitzem aquesta aplicació per visualitzar el més fàcilment possible amb quina versió ens estem comunicant.

Repositori d'infraestructura

En aquest nap desplegarem mitjançant GitlabCI a Kubernetes, .gitlab-ci.yml es veu així:

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

Per executar-lo vosaltres mateixos, necessitareu un clúster, podeu utilitzar Gcloud:

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

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

Cal bifurcar-se https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure i crear una variable KUBECONFIG a GitlabCI, que contindrà la configuració d'accés kubectl al vostre clúster.

Podeu llegir sobre com obtenir credencials per a un clúster (Gcloud) aquí.

Infraestructura Yaml

Al repositori d'infraestructura tenim el servei:

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

I desplegament en 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 un altre desplegament 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

Tingueu en compte que app-deploy encara no té cap rèplica definida.

Realització del desplegament inicial

Per iniciar el desplegament inicial, podeu iniciar manualment la canalització de GitlabCI a la branca mestra. Després d'això kubectl hauria de sortir el següent:

Nosaltres veiem app desplegament amb 10 rèpliques i app-canary amb 0. També hi ha un LoadBalancer des del qual podem accedir mitjançant curl mitjançant IP externa:

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

Veiem que la nostra aplicació de prova només retorna "v1".

Execució del desplegament de Canary

Pas 1: llançar una versió nova per a alguns usuaris

Establem el nombre de rèpliques a 1 al fitxer deploy-canary.yaml i a la imatge de la nova versió:

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

A l'arxiu deploy.yaml hem canviat el nombre de rèpliques a 9:

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

Impulsem aquests canvis al repositori des del qual començarà el desplegament (mitjançant GitlabCI) i veiem com a resultat:

El nostre servei apuntarà a tots dos desplegaments, ja que tots dos tenen el selector d'aplicacions. A causa de l'aleatorització predeterminada de Kubernetes, hauríem de veure respostes diferents per al ~10% de les sol·licituds:

L'estat actual de la nostra aplicació (GitOps, extret de Git com a Single Source Of Truth) és la presència de dos desplegaments amb rèpliques actives, una per a cada versió.

El ~10% dels usuaris es familiaritzen amb una versió nova i la proven sense voler. Ara és el moment de comprovar si hi ha errors als registres i les dades de control per trobar problemes.

Pas 2: llança la nova versió per a tots els usuaris

Vam decidir que tot anava bé i ara hem de llançar la nova versió a tots els usuaris. Per fer-ho simplement actualitzem deploy.yaml instal·lant una nova versió de la imatge i el nombre de rèpliques igual a 10. In deploy-canary.yaml tornem a establir el nombre de rèpliques a 0. Després del desplegament, el resultat serà el següent:

En resum

Per a mi, executar el desplegament manualment d'aquesta manera ajuda a entendre amb quina facilitat es pot configurar amb k8s. Com que Kubernetes us permet actualitzar-ho tot mitjançant una API, aquests passos es poden automatitzar mitjançant scripts.

Una altra cosa que cal implementar és un punt d'entrada del provador (LoadBalancer o via Ingress) a través del qual només es pot accedir a la nova versió. Es pot utilitzar per a la navegació manual.

En articles futurs, veurem altres solucions automatitzades que implementen la major part del que hem fet.

Llegiu també altres articles al nostre blog:

Font: www.habr.com

Desplegament de Canary a Kubernetes #1: Gitlab CI