🥇Implementación Canary en Kubernetes #2: Argo Rollouts

Usaremos el controlador de implementación nativo de k8s Argo Rollouts y GitlabCI para lanzar una implementación Canary en Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artículos de este ciclo

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

Despliegue Canary

Esperamos que haya leído la primera parte, donde explicamos brevemente qué son las Implementaciones Canary. También mostramos cómo implementarlo utilizando los recursos estándar de Kubernetes.

Argo Rollouts

Argo Rollouts es un controlador de implementación nativo de Kubernetes. Proporciona CRD (Definición de Recursos Personalizados) para Kubernetes. Gracias a él, podemos usar una nueva entidad: Rollout, que gestiona implementaciones blue-green y canary con diferentes opciones de configuración.

El controlador Argo Rollouts, utilizado con el recurso personalizado Rollout, permite utilizar estrategias de implementación adicionales, como blue-green y canary para Kubernetes. El recurso Rollout ofrece funcionalidad equivalente Deployment, solo que con estrategias de implementación adicionales.
El recurso Deployments tiene dos estrategias para la implementación: RollingUpdate y Recreate. Aunque estas estrategias son adecuadas para la mayoría de los casos, para implementar en servidores a gran escala se utilizan estrategias adicionales, como blue-green o canary, que no están en el controlador de implementación. Para usar estas estrategias en Kubernetes, los usuarios tenían que escribir scripts sobre sus Implementaciones. El controlador Argo Rollouts proporciona estas estrategias en forma de parámetros configurables simples y declarativos.
https://argoproj.github.io/argo-rollouts

También existe Argo CI, que proporciona una interfaz web conveniente para usar junto con Rollouts, lo analizaremos en el siguiente artículo.

Instalación de Argo Rollouts

Del 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 nuestro repositorio de infraestructura (ver más abajo) ya hemos agregado install.yaml como i/k8s/argo-rollouts/install.yaml. Así, GitlabCI lo instalará en el clúster.

Del lado del cliente (plugin 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 para la infraestructura.

Repositorio de la aplicación

Kim Wuestkamp / k8s-deployment-example-app

Es una API muy simple en Python+Flask, que devuelve una respuesta en formato JSON. Compilaremos el paquete utilizando GitlabCI y subiremos el resultado a Gitlab Registry. En el registro tenemos dos versiones diferentes de lanzamientos:

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

La única diferencia entre ellas es el archivo JSON devuelto. Usamos esta aplicación para visualizar de la manera más simple posible con qué versión estamos interactuando.

Repositorio de infraestructura

En este repositorio vamos a utilizar GitlabCI para el despliegue en Kubernetes, .gitlab-ci.yml se ve de la siguiente manera:

imagen: traherom/kustomize-dockerbefore_script:
   - printenv
   - versión de kubectlstages:
 - desplegardeploy test:
   etapa: desplegar
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl obtener todo
     - kubectl aplicar -f i/k8s    solo:
     - maestra

Para ejecutarlo por su cuenta 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

Necesita hacer un fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure y crear una variable KUBECONFIG en GitlabCI, que contendrá la configuración para acceder kubectl a su clúster.

Aquí se puede leer sobre cómo obtener credenciales para el clúster (Gcloud).

Yaml de infraestructura

Dentro del repositorio de infraestructura tenemos el 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: Siempre
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Los despliegues se pueden reanudar manualmente ejecutando `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # dos minutos

Rollout funciona igual que un Deployment. Si no establecemos una estrategia de actualización (como canary aquí) se comportará como un despliegue rolling-update por defecto.

Definimos dos pasos en yaml para el despliegue canary:

10% de tráfico en canary (esperar aprobación manual)
50% de tráfico en canary (esperar 2 minutos y luego continuar hasta 100%)

Ejecución del despliegue inicial

Después del despliegue inicial, nuestros recursos se verán así:

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

Realizamos el Canary Deployment

Paso 1: 10% de tráfico

Para comenzar el despliegue canary, solo necesitamos cambiar la versión de la imagen, como normalmente lo hacemos con los despliegues:

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

Y subimos los cambios, por lo que Gitlab CI realiza el despliegue y vemos los cambios:

Ahora, si accedemos al servicio:

¡Genial! Estamos a la mitad de nuestro despliegue canary. 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. Hemos configurado este paso para que se ejecute manualmente:

kubectl argo rollouts promote rollout-canary # continuar al paso 2

Y nuestra aplicación ha devuelto el 50% de respuestas de nuevas versiones:

Y resumen del rollout:

Perfecto.

Paso 3: 100% de tráfico:

Hemos configurado para que después de 2 minutos el paso con 50% se complete automáticamente y se inicie el paso con 100%:

Y salida de la aplicación:

Y resumen del rollout:

El Canary deployment está completo.

Más ejemplos con Argo Rollouts

Aquí hay más ejemplos, como configurar la vista previa del entorno y comparaciones basadas en canary:

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

Video sobre Argo Rollouts y Argo CI

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

Summary

Me gusta mucho la idea de usar CRDs que gestionan la creación de tipos adicionales de deployments o replicasets, redirigen el tráfico, etc. Trabajar con ellos es fácil. Luego, me gustaría probar la integración con Argo CI.

Sin embargo, aparentemente se avecina una gran fusión entre Argo CI y Flux CI, así que podría esperar hasta que salga la nueva versión: Argo Flux.

¿Has tenido experiencia con Argo Rollouts o Argo CI?

También lee otros artículos en nuestro blog:

Fuente: habr.com