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