A implantação do Canary é uma maneira muito eficaz de testar o novo código em um subconjunto de usuários. Reduz significativamente a carga de tráfego, o que pode causar problemas durante o processo de implantação, pois ocorre apenas dentro de um determinado subgrupo. Este artigo é dedicado a como organizar uma implantação semelhante usando o Kubernetes e a automação de implantação.
Supõe-se que você saiba algo sobre os recursos do Helm e do Kubernetes .
A implantação simples de canários do Kubernetes inclui dois recursos principais: o próprio serviço e a ferramenta de implantação. A implantação do canary funciona por meio de um serviço, que interage com dois recursos diferentes que atendem ao tráfego de atualização. Um desses recursos funcionará com a versão "canary" e o segundo com a versão estável. Nesta situação, podemos ajustar o número de versões canárias para reduzir a quantidade de tráfego necessária para manutenção. Se, por exemplo, você preferir usar o Yaml, ele ficará assim no 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.
É ainda mais fácil imaginar essa opção no kubectl, e a
documentação do
Kubernetes ainda tem um tutorial completo sobre esse cenário. Mas a principal questão deste post é como vamos automatizar esse processo usando o Helm.
Automação de uma implantação canária
Primeiro, precisamos do Mapa do Helm Chart, que já incluiu os recursos discutidos por nós acima. Deve ser algo como isto:
~/charts/app ├── Chart.yaml ├── README.md ├── templates │ ├── NOTES.txt │ ├── _helpers.tpl │ ├── deployment.yaml │ └── service.yaml └── values.yaml
A base do conceito Helm é o gerenciamento de lançamentos em várias versões. A versão estável é nosso principal ramo estável do código do projeto. Mas com o Helm, podemos implantar um release canário com nosso código experimental. O principal é manter a troca de tráfego entre a versão estável e a versão canary. Gerenciaremos tudo isso usando um seletor especial:
selector: app.kubernetes.io/name: myapp
Nossos recursos de implantação "canários" e estáveis indicarão esse rótulo nos módulos. Se tudo estiver configurado corretamente, durante a implantação da versão canária de nosso gráfico Helm, veremos que o tráfego será direcionado para módulos recém-implantados. Uma versão estável deste comando terá a seguinte aparência:
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
Agora vamos conferir nosso lançamento de canário. Para implantar a versão canary, precisamos nos lembrar de duas coisas. O nome do release deve ser diferente para que não acumulemos a atualização na versão estável atual. A versão e a tag também devem ser diferentes para que possamos implantar códigos diferentes e identificar diferenças por rótulos 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
Isso é tudo, na verdade! Se você executar ping no serviço, poderá ver que a atualização do canário direciona o tráfego apenas parte do tempo.
Se você estiver procurando por ferramentas de automação de implantação que incluam a lógica descrita, confira o
Deliverybot e as
ferramentas de automação Helm no GitHub . Os gráficos Helm usados para implementar o método descrito acima estão no Github,
aqui . Em geral, essa foi uma visão geral teórica de como implementar a implantação de versões canárias na prática, com conceitos e exemplos específicos.