Deployments
Para ese estudio vamos a seguir la siguiente secuencia:
Blue Green vs Canary
En pocas palabras, el Blue-Green es el acto de crear un segundo deployment, con un nuevo nombre, nueva imagen, nuevas labels, inclusive es recomendable mantener una label version, pero no necesaria. Una vez que el segundo deployment esté listo, debe ser cambiado apenas el selector del service para dejar de apuntar para el primer deployment y apuntar para el segundo, redireccionando todo el tráfico inmediatamente.
Por otro lado, el Canary deployment es el acto de ir migrando gradualmente. Un porcentaje de las requisiciones del service deben ir para el primer deployment y otro porcentaje para el segundo. Esos porcentajes deben ser ajustados gradualmente para que a lo largo de un período todo el tráfico pase para el segundo deployment.
En el Canary deployment ambos deployments precisan tener por lo menos una label en común, por ejemplo app=my-app-name. En el Service vamos a filtrar por esa label común para que todos los pods de ambos deployments puedan responder a las requisiciones, incluso siendo de diferentes versiones.
Para controlar el tráfico es necesario apenas controlar el número de pods de ambas versiones. En la versión 1 podemos tener 3 réplicas y en la versión 2 podemos tener 7 réplicas. Eso nos da un tráfico de 30% para la versión 1 y 70% para la versión 2, una vez que el service posee el algoritmo round robin por padrón.
Existen herramientas mejores para hacer eso, como es el caso del Istio, pero no estudiaremos en el CKAD.