🥇Implementación de Canary en Kubernetes n.° 2: Implementaciones de Argo

Usaremos el controlador de implementación Argo Rollouts nativo de k8s y GitlabCI para ejecutar implementaciones de Canary en Kubernetes.

https://unsplash.com/photos/V41PulGL1z0

Artículos de esta serie

Implementación de Canary en Kubernetes n.° 1: Gitlab CI
(Este artículo)
Implementación de Canarias usando Istio
Implementación de Canary utilizando Jenkins-X Istio Flagger

Implementación canaria

Esperamos que leas primera parte, donde explicamos brevemente qué son los Canary Deployments. También mostramos cómo implementarlo utilizando recursos estándar de Kubernetes.

Lanzamientos de Argo

Argo Rollouts es un controlador de implementación nativo de Kubernetes. Proporciona una CRD (definición de recursos personalizados) para Kubernetes. Gracias a ello, podemos utilizar una nueva entidad: Rollout, que gestiona implementaciones azul-verde y canary con varias opciones de configuración.

Controlador Argo Rollouts utilizado por un recurso personalizado Rollout, Permite estrategias de implementación adicionales, como azul-verde y canario para Kubernetes. Recurso Rollout proporciona una funcionalidad equivalente Deployment, solo con estrategias de implementación adicionales.
recurso Deployments tiene dos estrategias de implementación: RollingUpdate и Recreate. Aunque estas estrategias son adecuadas para la mayoría de los casos, para la implementación en servidores a muy gran escala se utilizan estrategias adicionales, como azul-verde o canary, que no están disponibles en el controlador de implementación. Para utilizar estas estrategias en Kubernetes, los usuarios tenían que escribir scripts además de sus implementaciones. El controlador Argo Rollouts expone estas estrategias como parámetros simples, declarativos y configurables.
https://argoproj.github.io/argo-rollouts

También está Argo CI, que proporciona una interfaz web conveniente para usar con Rollouts, lo veremos en el próximo artículo.

Instalación de implementaciones de Argo

Lado del servidor

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

En nuestra infraestructura de nabo (ver más abajo) ya hemos agregado install.yaml como i/k8s/argo-rollouts/install.yaml. De esta forma, GitlabCI lo instalará en el clúster.

Lado del cliente (complemento kubectl)

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

Aplicación de ejemplo

Es una buena práctica tener repositorios separados para el código de la aplicación y la infraestructura.

Repositorio de la aplicación

Kim Wuestkamp/k8s-implementación-ejemplo-aplicación

Esta es una API Python+Flask muy simple que devuelve una respuesta como JSON. Construiremos el paquete usando GitlabCI y enviaremos el resultado al Registro de Gitlab. En el registro tenemos dos versiones de lanzamiento diferentes:

wuestkamp/k8s-implementación-ejemplo-aplicación:v1
wuestkamp/k8s-implementación-ejemplo-aplicación:v2

La única diferencia entre ellos es el archivo JSON devuelto. Utilizamos esta aplicación para visualizar lo más fácilmente posible con qué versión nos estamos comunicando.

Repositorio de infraestructura

En este repositorio usaremos GitlabCI para la implementación en Kubernetes, .gitlab-ci.yml tiene este 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 ejecutarlo usted mismo necesitará un clúster, puede 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 y crear una variable KUBECONFIG en GitlabCI, que contendrá la configuración para el acceso kubectl a su grupo.

es Puede leer sobre cómo obtener credenciales para un clúster (Gcloud).

Yaml de infraestructura

Dentro del repositorio de infraestructura tenemos servicio:

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

y 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 la implementación. Si no configuramos una estrategia de actualización (como canary aquí), se comportará como la implementación de actualización continua predeterminada.

Definimos dos pasos en yaml para la implementación canary:

10% del tráfico a Canary (espera a que se apruebe el manual)
50% de tráfico a Canary (espera 2 minutos y luego continúa hasta el 100%)

Realizar la implementación inicial

Después de la implementación inicial, nuestros recursos tendrán este aspecto:

Y obtenemos respuesta solo de la primera versión de la aplicación:

Realizar la implementación Canary

Paso 1: 10% de tráfico

Para iniciar una implementación canary, solo necesitamos cambiar la versión de la imagen como hacemos habitualmente con las implementaciones:

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, por lo que Gitlab CI se implementa y vemos los cambios:

Ahora si accedemos al servicio:

¡Excelente! Estamos en medio de nuestro despliegue canario. Podemos ver el progreso ejecutando:

kubectl argo rollouts get rollout rollout-canary

Paso 2: 50% de tráfico:

Ahora pasemos al siguiente paso: redirigir el 50% del tráfico. Configuramos este paso para que se ejecute manualmente:

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

Y nuestra aplicación arrojó el 50% de las respuestas de las nuevas versiones:

Y revisión de implementación:

Bien

Paso 3: 100% de tráfico:

Lo configuramos para que después de 2 minutos el paso del 50% finalice automáticamente y comience el paso del 100%:

Y el resultado de la aplicación:

Y revisión de implementación:

La implementación de Canarias está completa.

Más ejemplos con Argo Rollouts

Hay más ejemplos aquí, como cómo configurar vistas previas y comparaciones del entorno basadas en canary:

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

Vídeo sobre las implementaciones de Argo y Argo CI

Realmente recomiendo este video, muestra cómo Argo Rollouts y Argo CI trabajan juntos:

Total

Realmente me gusta la idea de utilizar CRD que gestionen la creación de tipos adicionales de implementaciones o conjuntos de réplicas, redireccionen el tráfico, etc. Trabajar con ellos se desarrolla sin problemas. A continuación me gustaría probar la integración con Argo CI.

Sin embargo, parece que se avecina una gran fusión de Argo CI y Flux CI, por lo que podría esperar hasta que salga la nueva versión: Flujo Argo.

¿Ha tenido alguna experiencia con Argo Rollouts o Argo CI?

Lea también otros artículos en nuestro blog:

Fuente: habr.com

Implementación de Canary en Kubernetes #2: Implementaciones de Argo