🥇Desplegament de Canary a Kubernetes #2: llançaments d'Argo

Utilitzarem el controlador de desplegament Argo Rollouts natiu de k8s i GitlabCI per executar desplegaments de Canary a Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Articles d'aquesta sèrie

Desplegament de Canary a Kubernetes #1: Gitlab CI
(Aquest article)
Desplegament de Canary mitjançant Istio
Desplegament de Canary mitjançant Jenkins-X Istio Flagger

Desplegament Canari

Esperem que llegiu primera part, on vam explicar breument què són els Desplegaments Canaris. També vam mostrar com implementar-lo mitjançant els recursos estàndard de Kubernetes.

Desplegaments d'Argo

Argo Rollouts és un controlador de desplegament natiu de Kubernetes. Proporciona un CRD (Custom Resource Definition) per a Kubernetes. Gràcies a això, podem utilitzar una nova entitat: Rollout, que gestiona els desplegaments de color blau-verd i canari amb diverses opcions de configuració.

Controlador Argo Rollouts utilitzat per un recurs personalitzat Rollout, Permet estratègies de desplegament addicionals com ara blau-verd i canari per a Kubernetes. Recurs Rollout proporciona una funcionalitat equivalent Deployment, només amb estratègies de desplegament addicionals.
recurs Deployments té dues estratègies de desplegament: RollingUpdate и Recreate. Tot i que aquestes estratègies són adequades per a la majoria dels casos, per a la implementació a servidors a gran escala, s'utilitzen estratègies addicionals, com ara blau-verd o canari, que no estan disponibles al controlador de desplegament. Per utilitzar aquestes estratègies a Kubernetes, els usuaris havien d'escriure scripts a sobre dels seus desplegaments. El controlador Argo Rollouts exposa aquestes estratègies com a paràmetres simples, declaratius i configurables.
https://argoproj.github.io/argo-rollouts

També hi ha Argo CI, que proporciona una interfície web còmoda per utilitzar-la amb desplegaments, ho farem una ullada al proper article.

Instal·lació d'Argo Rollouts

La part del servidor

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

A la nostra infraestructura de nap (vegeu més avall) ja hem afegit install.yaml com i/k8s/argo-rollouts/install.yaml. D'aquesta manera, GitlabCI l'instal·larà al clúster.

costat del client (connector kubectl)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Exemple d'aplicació

És una bona pràctica tenir repositoris separats per al codi de l'aplicació i la infraestructura.

Repositori per a l'aplicació

Kim Wuestkamp/k8s-deployment-example-app

Aquesta és una API Python+Flask molt senzilla que retorna una resposta com a JSON. Construirem el paquet utilitzant 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 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 repositori utilitzarem GitlabCI per al desplegament a Kubernetes, .gitlab-ci.yml té aquest aspecte:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy 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.

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

Infraestructura Yaml

Dins del repositori d'infraestructura tenim el servei:

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

i rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout funciona igual que el desplegament. Si no establim una estratègia d'actualització (com ara Canary aquí), es comportarà com el desplegament d'actualització continua per defecte.

Definim dos passos a Yaml per al desplegament de Canary:

10% del trànsit a Canary (espera que el manual estigui bé)
50% de trànsit a Canary (espera 2 minuts i després continua fins al 100%)

Realització del desplegament inicial

Després del desplegament inicial, els nostres recursos seran així:

I només rebem una resposta de la primera versió de l'aplicació:

Realitzant el desplegament canari

Pas 1: 10% de trànsit

Per iniciar un desplegament canari, només hem de canviar la versió de la imatge tal com fem habitualment amb els desplegaments:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

I impulsem els canvis, de manera que Gitlab CI es desplega i veiem els canvis:

Ara si accedim al servei:

Genial! Estem enmig del nostre desplegament canari. Podem veure el progrés executant:

kubectl argo rollouts get rollout rollout-canary

Pas 2: 50% de trànsit:

Ara passem al següent pas: redirigir el 50% del trànsit. Hem configurat aquest pas perquè s'executi manualment:

kubectl argo rollouts promote rollout-canary # continue to step 2

I la nostra aplicació va retornar el 50% de les respostes de les noves versions:

I revisió del llançament:

Meravellós.

Pas 3: 100% de trànsit:

Ho configurem de manera que al cap de 2 minuts el pas del 50% acabi automàticament i comenci el pas del 100%:

I la sortida de l'aplicació:

I revisió del llançament:

El desplegament de Canary s'ha completat.

Més exemples amb Argo Rollouts

Hi ha més exemples aquí, com ara com configurar visualitzacions prèvies d'entorn i comparacions basades en Canary:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Vídeo sobre Argo Rollouts i Argo CI

Realment recomano aquest vídeo, que mostra com Argo Rollouts i Argo CI treballen junts:

Total

M'agrada molt la idea d'utilitzar CRDs que gestionen la creació de tipus addicionals de desplegaments o rèpliques, redirigeix el trànsit, etc. Treballar amb ells va bé. A continuació, m'agradaria provar la integració amb Argo CI.

Tanmateix, sembla que hi haurà una gran fusió d'Argo CI i Flux CI, així que podria esperar fins que surti la nova versió: Argo Flux.

Heu tingut alguna experiència amb Argo Rollouts o Argo CI?

Llegiu també altres articles al nostre blog:

Font: www.habr.com

Desplegament de Canary a Kubernetes #2: llançaments d'Argo