La implementación de Canary es una forma muy efectiva de probar un nuevo código en un subconjunto de usuarios. Reduce significativamente la carga de tráfico, lo que puede causar problemas durante el proceso de implementación, ya que ocurre solo dentro de un determinado subgrupo. Este artículo está dedicado a cómo organizar una implementación similar usando Kubernetes y la automatización de implementación.
Se supone que sabes algo sobre los recursos de Helm y Kubernetes .
El sencillo despliegue canario de Kubernetes incluye dos recursos clave: el servicio en sí y la herramienta de despliegue. La implementación canaria funciona a través de un servicio, que interactúa con dos recursos diferentes que sirven para actualizar el tráfico. Uno de estos recursos funcionará con la versión "canaria", y el segundo con la versión estable. En esta situación, podemos ajustar el número de versiones canarias para reducir la cantidad de tráfico requerido para el mantenimiento. Si, por ejemplo, prefiere usar Yaml, se verá así en Kubernetes:
kind: Deployment metadata: name: app-canary labels: app: app spec: replicas: 1 ... image: myapp:canary --- kind: Deployment metadata: name: app labels: app: app spec: replicas: 5 ... image: myapp:stable --- kind: Service selector: app: app # Selector will route traffic to both deployments.
Es aún más fácil imaginar tal opción en kubectl, y la
documentación de Kubernetes incluso tiene un tutorial completo sobre este escenario. Pero la pregunta principal de esta publicación es cómo vamos a automatizar este proceso usando Helm.
Automatización de un despliegue canario
En primer lugar, necesitamos el Helm Chart Map, que ya ha incluido los recursos discutidos anteriormente. Debería verse más o menos así:
~/charts/app ├── Chart.yaml ├── README.md ├── templates │ ├── NOTES.txt │ ├── _helpers.tpl │ ├── deployment.yaml │ └── service.yaml └── values.yaml
La base del concepto Helm es la gestión de versiones múltiples. La versión estable es nuestra principal rama estable del código del proyecto. Pero con Helm, podemos implementar una versión canaria con nuestro código experimental. Lo principal es mantener el intercambio de tráfico entre la versión estable y la versión canaria. Gestionaremos todo esto utilizando un selector especial:
selector: app.kubernetes.io/name: myapp
Nuestros recursos de implementación “canarios” y estables indicarán esta etiqueta en los módulos. Si todo está configurado correctamente, durante la implementación de la versión canaria de nuestro gráfico Helm, veremos que el tráfico se enviará a los módulos recién implementados. Una versión estable de este comando se verá así:
helm upgrade --install myapp \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v1 \ # Goes into app.kubernetes.io/version --set image.tag=stable \ --set replicaCount=5
Ahora echemos un vistazo a nuestro lanzamiento canario. Para implementar la versión canaria, debemos recordar dos cosas. El nombre de la versión debe ser diferente para que no acumulemos la actualización en la versión estable actual. La versión y la etiqueta también deben ser diferentes para que podamos implementar diferentes códigos e identificar diferencias por etiquetas de recursos.
helm upgrade --install myapp-canary \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v2 \ # Goes into app.kubernetes.io/version --set image.tag=canary \ --set replicaCount=1
Eso es todo, en realidad! Si hace ping al servicio, puede ver que la actualización canaria enruta el tráfico solo una parte del tiempo.
Si está buscando herramientas de automatización de implementación que incluyen la lógica descrita, consulte
Deliverybot y las
herramientas de automatización de Helm en GitHub . Los gráficos de Helm utilizados para implementar el método descrito anteriormente están en Github,
aquí mismo . En general, esta fue una descripción teórica de cómo implementar el despliegue de versiones canarias en la práctica, con conceptos y ejemplos específicos.