Deployments
Para esse estudo vamos seguir a seguinte sequência:
Blue Green vs Canary
Em poucas palavras, o Blue-Green é o ato de criar um segundo deployment, com um novo nome, nova imagem, novas labels, inclusive é recomendável manter uma label version, mas não necessária. Uma vez que o segundo deployment estiver pronto, deve ser mudado apenas o selector do service para deixar de apontar para o primeiro deployment e apontar para o segundo, redirecionando todo o tráfego imediatamente.
Por outro lado, o Canary deployment é o ato de ir migrando gradativamente. Uma porcentagem das requisições do service devem ir para o primeiro deployment e outra porcentagem para o segundo. Essas porcentagens devem ser ajustadas gradativamente para que ao longo de um período todo o tráfego passe para o segundo deployment.
No Canary deployment ambos os deployments precisam ter pelo menos uma label em comum, por exemplo app=my-app-name. No Service vamos filtrar por essa label comum para que todos os pods de ambos deployments possam responder às requisições, mesmo sendo de diferentes versões.
Para controlar o tráfego é necessário apenas controlar o número de pods de ambas as versões. Na versão 1 podemos ter 3 réplicas e na versão 2 podemos ter 7 réplicas. Isso nos dá um tráfego de 30% para a versão 1 e 70% para a versão 2, uma vez que o service possui o algoritmo round robin por padrão.
Existem ferramentas melhores para fazer isso, como é o caso do Istio, mas não estudaremos no CKAD.