🥇Implementación de Canary en Kubernetes #2: Lanzamentos de Argo

Usaremos o controlador de implementación Argo Rollouts nativo de k8s e GitlabCI para executar despregamentos de Canary en Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artigos desta serie

Implementación de Canary en Kubernetes #1: Gitlab CI
(Este artigo)
Despliegue Canary usando Istio
Implementación de Canary usando Jenkins-X Istio Flagger

Despliegue Canario

Esperamos que leas primeira parte, onde explicamos brevemente que son os Despliegues Canarios. Tamén mostramos como implementalo usando recursos estándar de Kubernetes.

Lanzamentos de Argo

Argo Rollouts é un controlador de implantación nativo de Kubernetes. Proporciona un CRD (Custom Resource Definition) para Kubernetes. Grazas a ela, podemos utilizar unha nova entidade: Rollout, que xestiona despregamentos azul-verde e canario con varias opcións de configuración.

Controlador Argo Rollouts usado por un recurso personalizado Rollout, Permite estratexias de implantación adicionais, como azul-verde e canario para Kubernetes. Recurso Rollout proporciona unha funcionalidade equivalente Deployment, só con estratexias de implantación adicionais.
recurso Deployments ten dúas estratexias de implantación: RollingUpdate и Recreate. Aínda que estas estratexias son axeitadas para a maioría dos casos, para a súa implantación en servidores a gran escala utilízanse estratexias adicionais, como o azul-verde ou o canario, que non están dispoñibles no controlador de implementación. Para usar estas estratexias en Kubernetes, os usuarios tiñan que escribir scripts enriba das súas implementacións. O Argo Rollouts Controller expón estas estratexias como parámetros simples, declarativos e configurables.
https://argoproj.github.io/argo-rollouts

Tamén hai Argo CI, que ofrece unha interface web cómoda para usar con Rollouts, verémolo no seguinte artigo.

Instalación de Argo Rollouts

Lado do servidor

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

Na nosa infraestrutura nabo (ver máis abaixo) xa engadimos install.yaml como i/k8s/argo-rollouts/install.yaml. Deste xeito, GitlabCI instalaráo no clúster.

Lado do cliente (complemento kubectl)

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

Aplicación de exemplo

É unha boa práctica ter repositorios separados para o código e a infraestrutura das aplicacións.

Repositorio para a aplicación

Kim Wuestkamp/k8s-deployment-example-app

Esta é unha API de Python+Flask moi sinxela que devolve unha resposta como JSON. Construiremos o paquete usando GitlabCI e enviaremos o resultado ao Rexistro de Gitlab. No rexistro temos dúas versións diferentes:

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

A única diferenza entre eles é o ficheiro JSON devolto. Usamos esta aplicación para visualizar o máis facilmente posible con que versión nos estamos comunicando.

Repositorio de infraestruturas

Neste repositorio usaremos GitlabCI para a implantación en Kubernetes, .gitlab-ci.yml ten o seguinte aspecto:

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

Para executalo vostede mesmo, necesitará un clúster, pode usar Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

Necesitas bifurcar https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure e crea unha variable KUBECONFIG en GitlabCI, que conterá a configuración de acceso kubectl ao teu clúster.

Aquí Podes ler sobre como obter credenciais para un clúster (Gcloud).

Infraestrutura Yaml

Dentro do repositorio de infraestruturas temos o servizo:

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

e 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 o Despliegue. Se non establecemos unha estratexia de actualización (como Canary aquí) comportarase como a implementación de actualización continua predeterminada.

Definimos dous pasos en yaml para a implantación de Canary:

10 % do tráfico a Canary (agardar a que se acepte o manual)
50 % de tráfico a Canary (espera 2 minutos e despois continúa ata o 100 %)

Realización da implantación inicial

Despois da implantación inicial, os nosos recursos terán o seguinte aspecto:

E recibimos unha resposta só da primeira versión da aplicación:

Realizando o Despliegue Canario

Paso 1: 10% de tráfico

Para comezar un despregue canario, só necesitamos cambiar a versión da imaxe como adoitamos facer cos despregamentos:

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
...

E impulsamos cambios, polo que Gitlab CI se implementa e vemos os cambios:

Agora se accedemos ao servizo:

Genial! Estamos no medio do noso despregamento canario. Podemos ver o progreso executando:

kubectl argo rollouts get rollout rollout-canary

Paso 2: 50 % de tráfico:

Agora imos pasar ao seguinte paso: redirixir o 50% do tráfico. Configuramos este paso para que se execute manualmente:

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

E a nosa aplicación devolveu o 50% das respostas das novas versións:

E revisión do lanzamento:

Marabilloso.

Paso 3: 100 % de tráfico:

Configurámolo para que despois de 2 minutos o paso do 50 % remate automaticamente e comece o paso do 100 %:

E a saída da aplicación:

E revisión do lanzamento:

O despregamento de Canary completouse.

Máis exemplos con Argo Rollouts

Aquí hai máis exemplos, como como configurar as vistas previas do contorno e as comparacións baseadas en Canary:

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

Vídeo sobre Argo Rollouts e Argo CI

Realmente recomendo este vídeo, que mostra como Argo Rollouts e Argo CI traballan xuntos:

Total

Gústame moito a idea de usar CRDs que xestionan a creación de tipos adicionais de implantacións ou réplicas, redireccionan o tráfico, etc. Traballar con eles vai sen problemas. A continuación gustaríame probar a integración con Argo CI.

Non obstante, parece haber unha gran fusión de Argo CI e Flux CI, polo que podería esperar ata que saia a nova versión: Argo Flux.

Tivo algunha experiencia con Argo Rollouts ou Argo CI?

Lea tamén outros artigos no noso blog:

Fonte: www.habr.com