Uma maneira simples e segura de automatizar implantações canárias com o Helm

A implantação canário é uma forma muito eficaz de testar novo código em um subconjunto de usuários. Reduz significativamente a carga de tráfego que pode ser problemática durante o processo de implantação, pois ocorre apenas dentro de um subconjunto específico. Esta nota é dedicada a como organizar tal implantação usando Kubernetes e automação de implantação. Presumimos que você saiba algo sobre os recursos do Helm e do Kubernetes.



Uma implantação canário simples no Kubernetes inclui dois recursos principais: o próprio serviço e a ferramenta de implantação. A implantação canário funciona por meio de um único serviço que interage com dois recursos diferentes que atendem ao tráfego de atualização. Um desses recursos funcionará com a versão “canário” e o segundo funcionará com a versão estável. Nesta situação, podemos regular o número de versões canário para reduzir a quantidade de tráfego necessária para servir. Se, por exemplo, você preferir usar Yaml, no Kubernetes ficará assim:

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 esta opção usando kubectl, e em Documentação do Kubernetes Existe até um tutorial completo sobre esse cenário. Mas a questão principal deste post é como vamos automatizar esse processo usando o Helm.

Automação da implantação canário

Primeiro de tudo, precisamos de um mapa gráfico do Helm, que já inclui os recursos que discutimos acima. Deve ser algo assim:

~/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 multi-versão. A versão estável é nosso principal ramo estável do código do projeto. Mas com Helm podemos implantar uma versão 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 canário. Faremos tudo isso usando um seletor especial:

selector:
  app.kubernetes.io/name: myapp

Nossos recursos de implantação “canário” e estáveis ​​indicarão esta etiqueta nos módulos. Se tudo estiver configurado corretamente, durante a implantação da versão canário do nosso mapa gráfico Helm, veremos que o tráfego será direcionado para os módulos recém-implantados. A versão estável deste comando ficará assim:

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 verificar nosso lançamento canário. Para implantar a versão canário, precisamos lembrar de duas coisas. O nome da versão deve ser diferente para que não implementemos uma atualização para a versão estável atual. A versão e a tag também devem ser diferentes para que possamos implantar outro código e identificar diferenças por tags 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! Se você executar ping no serviço, poderá ver que a atualização canário roteia o tráfego apenas parte do tempo.

Se você estiver procurando ferramentas de automação de implantação que incluam a lógica descrita, preste atenção em Robô de entrega e 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, esta foi uma visão teórica de como implementar a automação da implantação de versões canário na prática, com conceitos e exemplos específicos.

Fonte: habr.com