Unha forma sinxela e segura de automatizar as implementacións de canarias usando Helm

A implantación de Canary é unha forma moi eficaz de probar código novo nun subconxunto de usuarios. Reduce significativamente a carga de tráfico que pode ser problemática durante o proceso de implantación, xa que só ocorre dentro dun subconxunto específico. Esta nota dedícase a como organizar tal despregamento mediante Kubernetes e a automatización da implantación. Supoñemos que sabes algo sobre os recursos de Helm e Kubernetes.



Un simple despregue canario en Kubernetes inclúe dous recursos clave: o servizo en si e a ferramenta de implantación. A implantación de Canary funciona a través dun único servizo que interactúa con dous recursos diferentes que serven o tráfico de actualización. Un destes recursos funcionará coa versión "canario" e o segundo coa versión estable. Nesta situación, podemos regular o número de versións canarias para reducir o tráfico necesario para atender. Se, por exemplo, prefires usar Yaml, en Kubernetes quedará así:

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.

É aínda máis fácil imaxinar esta opción usando kubectl e dentro Documentación de Kubernetes Incluso hai un tutorial completo sobre este escenario. Pero a pregunta principal desta publicación é como imos automatizar este proceso usando Helm.

Automatización do despregue canario

En primeiro lugar, necesitamos un mapa gráfico Helm, que xa inclúe os recursos que comentamos anteriormente. Debería parecer algo así:

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

A base do concepto Helm é a xestión de lanzamentos de varias versións. A versión estable é a nosa principal rama estable do código do proxecto. Pero con Helm podemos implementar unha versión canaria co noso código experimental. O principal é manter o intercambio de tráfico entre a versión estable e a versión canaria. Xestionaremos todo isto mediante un selector especial:

selector:
  app.kubernetes.io/name: myapp

Os nosos recursos de despregamento "canario" e estable indicarán esta etiqueta nos módulos. Se todo está configurado correctamente, durante a implantación da versión canaria do noso mapa gráfico Helm veremos que o tráfico dirixirase aos módulos recentemente implantados. A versión estable deste comando terá o seguinte aspecto:

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 imos comprobar o noso lanzamento canario. Para implementar a versión canaria, debemos lembrar dúas cousas. O nome da versión debe ser diferente para non lanzar unha actualización á versión estable actual. A versión e a etiqueta tamén deben ser diferentes para que poidamos despregar outro código e identificar diferenzas por etiquetas 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

Iso é todo! Se fai ping ao servizo, verá que a actualización de Canary envía o tráfico só unha parte do tempo.

Se está a buscar ferramentas de automatización de implementación que inclúan a lóxica descrita, preste atención Deliverybot e Ferramentas de automatización de Helm en GitHub. Os gráficos Helm utilizados para implementar o método descrito anteriormente están en Github, aquí. En xeral, esta foi unha visión teórica de como implementar a automatización do despregue de versións canarias na práctica, con conceptos e exemplos específicos.

Fonte: www.habr.com