Estratexias de implantación en Kubernetes: rolamento, recreación, azul/verde, canario, escuro (probas A/B)

Nota tradución: Esta visión xeral de Weaveworks presenta as estratexias de lanzamento de aplicacións máis populares e mostra como se poden implementar as máis avanzadas mediante o operador Kubernetes Flagger. Está escrito nunha linguaxe sinxela e contén diagramas visuais que permiten que incluso os enxeñeiros novatos comprendan o problema.

O diagrama está sacado de outra recensión estratexias de implantación feitas en Container Solutions

Un dos maiores retos no desenvolvemento de aplicacións nativas na nube hoxe en día é acelerar a implantación. Nun enfoque de microservizos, os desenvolvedores xa traballan e deseñan aplicacións completamente modulares, o que permite que diferentes equipos escriban código e fagan cambios na aplicación simultáneamente.

As implantacións máis curtas e frecuentes teñen os seguintes beneficios:

• O tempo de comercialización redúcese.
• As novas funcións chegan aos usuarios máis rápido.
• Os comentarios dos usuarios chegan máis rápido ao equipo de desenvolvemento. Isto significa que o equipo pode engadir funcións e solucionar problemas máis rapidamente.
• Aumenta a moral dos desenvolvedores: é máis divertido traballar con máis funcións no desenvolvemento.

Pero a medida que aumenta a frecuencia dos lanzamentos, tamén aumentan as posibilidades de afectar negativamente á fiabilidade da aplicación ou á experiencia do usuario. Por iso é importante que os equipos de operacións e DevOps creen procesos e xestionen estratexias de implantación de forma que se minimice o risco para o produto e os usuarios. (Podes obter máis información sobre a automatización de canalizacións CI/CD aquí.)

Nesta publicación, discutiremos varias estratexias de despregamento en Kubernetes, incluíndo despregamentos continuos e métodos máis avanzados como os lanzamentos canarios e as súas variacións.

Estratexias de implantación

Existen varios tipos diferentes de estratexias de implantación que podes usar dependendo do teu obxectivo. Por exemplo, pode ter que facer cambios nun determinado ambiente para realizar probas posteriores, ou nun subconxunto de usuarios/clientes, ou pode ter que facer probas de usuarios limitadas antes de facer unha función público.

Rolling (gradual, despregamento "rolling")

Esta é a estratexia de implantación estándar en Kubernetes. Gradualmente, un por un, substitúe os pods coa versión antiga da aplicación por pods coa nova versión, sen tempo de inactividade do clúster.

Kubernetes agarda ata que os novos pods estean listos para funcionar (comprobando mediante probas de preparación), antes de comezar a enrolar os vellos. Se se produce un problema, esta actualización continua pódese abortar sen deter todo o clúster. No ficheiro YAML que describe o tipo de implantación, a nova imaxe substitúe a imaxe antiga:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

Os parámetros de actualización de rollover pódense especificar no ficheiro manifesto:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

Recrear

Neste tipo de despregamento máis sinxelo, as cápsulas antigas son eliminadas dunha soa vez e substitúense por outras novas:

O manifesto correspondente é algo así:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

Azul/Verde (impregacións en azul-verde)

A estratexia de implantación azul-verde (ás veces tamén chamada vermello/negro) implica a implantación simultánea das versións antiga (verde) e nova (azul) da aplicación. Despois de publicar ambas versións, os usuarios habituais teñen acceso á verde, mentres que a azul está dispoñible para que o equipo de control de calidade automatice as probas a través dun servizo separado ou de reenvío directo de portos:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

Despois de probar a versión azul (nova) e aprobar a súa publicación, o servizo cambia a ela e a versión verde (antiga) dóbrase:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Canarias (despliegues canarios)

Os lanzamentos de Canary son similares aos lanzamentos azul-verdes, pero teñen un mellor control e uso progresista enfoque paso a paso. Este tipo inclúe varias estratexias diferentes, incluíndo lanzamentos "sigilosos" e probas A/B.

Esta estratexia úsase cando hai que probar algunha nova funcionalidade, normalmente no backend da aplicación. A esencia do enfoque é crear dous servidores case idénticos: un atende a case todos os usuarios e o outro, con novas funcións, atende só a un pequeno subgrupo de usuarios, despois do cal se comparan os resultados do seu traballo. Se todo sae sen erros, a nova versión vaise implementando gradualmente en toda a infraestrutura.

Aínda que esta estratexia pódese implementar exclusivamente usando Kubernetes, substituíndo os pods antigos por outros novos, é moito máis cómodo e sinxelo usar unha malla de servizo como Istio.

Por exemplo, pode ter dous manifestos diferentes en Git: un manifesto normal coa etiqueta 0.1.0 e un manifesto canario coa etiqueta 0.2.0. Ao cambiar os pesos no manifesto da pasarela virtual de Istio, pode controlar a distribución do tráfico entre estas dúas implementacións:

Para obter unha guía paso a paso para implementar implementacións canarias usando Istio, consulte Fluxos de traballo de GitOps con Istio. (Nota. transl.: Tamén traducimos material sobre lanzamentos canarios a Istio aquí.)

Desplegamentos de Canarias con Weaveworks Flagger

Bandeira de Weaveworks permítelle xestionar de xeito sinxelo e eficaz os lanzamentos de Canary.

Flagger automatiza o traballo con eles. Usa Istio ou AWS App Mesh para enrutar e cambiar o tráfico, e métricas de Prometheus para analizar os resultados. Ademais, a análise dos despregamentos canarios pódese complementar con webhooks para realizar probas de aceptación, probas de carga e calquera outro tipo de comprobacións.

Baseándose no despregamento de Kubernetes e, se é necesario, no escalado horizontal de pods (HPA), Flagger crea conxuntos de obxectos (implementacións de Kubernetes, servizos ClusterIP e servizos virtuais Istio ou App Mesh) para analizar e implementar implantacións canarias:

Implementación do bucle de control (bucle de control),Flagger cambia gradualmente o tráfico ao servidor canario, mentres mide simultaneamente as métricas clave de rendemento, como a porcentaxe de solicitudes HTTP exitosas, a duración media das solicitudes e o estado do pod. En base á análise KPI (Key Performance Indicators), o canario crece ou colapsa e os resultados da análise publícanse en Slack. No material pódese atopar unha descrición e demostración deste proceso Entrega progresiva para App Mesh.

Desplegamentos escuros (ocultos) ou A/B

O despregamento furtivo é outra variación da estratexia canaria (que, por certo, Flagger tamén pode traballar). A diferenza entre os despregamentos furtivos e canarios é que os despregamentos furtivos tratan co frontend e non co backend como os despregamentos canarios.

Outro nome para estes despregamentos é probas A/B. En lugar de poñer a nova función dispoñible para todos os usuarios, ofrécese só a unha parte limitada deles. Normalmente, estes usuarios non saben que son probadores pioneiros (de aí o termo "implementación furtiva").

Usando interruptores de funcionalidade (alternar función) e outras ferramentas, pode supervisar como interactúan os usuarios coa nova función, se están involucrados con ela ou se consideran confusa a nova interface de usuario e outros tipos de métricas.

Despregamentos de bandeiras e A/B

Ademais do enrutamento baseado no peso, Flagger tamén pode dirixir o tráfico ao servidor canario en función de parámetros HTTP. Nas probas A/B, pode usar cabeceiras HTTP ou cookies para orientar a un segmento específico de usuarios. Isto é especialmente efectivo no caso de aplicacións de frontend que requiren vinculación de sesión ao servidor (afinidade de sesión). Pódese atopar máis información na documentación de Flagger.

O autor expresa gratitude Stefan Prodan, enxeñeiro de Weaveworks (e creador de Flagger), por todos estes sorprendentes patróns de implantación.

PS do tradutor

Lea tamén no noso blog:

• «Visión xeral e comparación dos controladores Ingress para Kubernetes»;
• «werf - a nosa ferramenta para CI / CD en Kubernetes (descrición xeral e informe de vídeo)»;
• «Crea e implementa microservizos do mesmo tipo con werf e GitLab CI»;
• «Que é GitOps?».

Fonte: www.habr.com