Despliegue seguro de servidores con pruebas canary

• Relato de experiencia sobre despliegue canary en un entorno de Kubernetes, escrito por Taeho Kim de VCNC, la empresa que opera Tada.

• El despliegue canary toma su nombre de la práctica de los mineros de llevar un canario en una jaula para detectar fugas de gas en las minas de carbón.

• Al subir la versión mayor de Spring Boot, también cambian de forma forzada las versiones de las bibliotecas de las que depende, por lo que intentaron un despliegue canary para minimizar problemas de rendimiento o fallas no detectadas en las pruebas.

• Despliegan en Kubernetes usando el gestor de paquetes Helm; a la unidad de paquete de Helm se le llama "chart", y al instalar un chart en un clúster de Kubernetes se crea un release.

• Crearon un chart/release para canary y añadieron anotaciones al controlador Ingress para que solo un porcentaje específico de las solicitudes fuera al Ingress canary.

Tareas futuras

• Cuando surge un problema en el release canary, es difícil determinar si la causa son los cambios del canary o un problema que ya existía, así que se necesita un método para levantar un grupo de control con la misma proporción y comparar métricas.

• Como una parte de las solicitudes se envía al canary sin relación con el usuario, aunque haya problemas en el canary algunas solicitudes pueden terminar siendo procesadas con éxito por la versión anterior tras reintentos; sin embargo, en términos generales puede aumentar la proporción de usuarios que experimentan los problemas del canary, por lo que parece posible lograr más control si se enruta al canary según grupos de usuarios (como el manejo sticky en el LB).