🥇Estratégias de implantação em Kubernetes: rolamento, recriar, azul/verde, canário, escuro (teste A/B)

Observação tradução: Esta visão geral do Weaveworks apresenta as estratégias de implementação de aplicativos mais populares e mostra como as mais avançadas podem ser implementadas usando o operador Kubernetes Flagger. Ele está escrito em linguagem simples e contém diagramas visuais que permitem que até mesmo engenheiros novatos entendam o problema.

O diagrama é retirado de outra revisão estratégias de implementação feitas em Container Solutions

Um dos maiores desafios no desenvolvimento de aplicativos nativos da nuvem atualmente é acelerar a implantação. Em uma abordagem de microsserviços, os desenvolvedores já trabalham e projetam aplicativos completamente modulares, permitindo que diferentes equipes escrevam códigos e façam alterações no aplicativo simultaneamente.

Implantações mais curtas e frequentes têm os seguintes benefícios:

O tempo de lançamento no mercado é reduzido.
Novos recursos chegam aos usuários com mais rapidez.
O feedback do usuário chega à equipe de desenvolvimento com mais rapidez. Isso significa que a equipe pode adicionar recursos e corrigir problemas mais rapidamente.
O moral do desenvolvedor aumenta: mais recursos em desenvolvimento são mais divertidos de trabalhar.

Mas à medida que a frequência dos lançamentos aumenta, as chances de impactar negativamente a confiabilidade do aplicativo ou a experiência do usuário também aumentam. É por isso que é importante que as equipes de operações e DevOps criem processos e gerenciem estratégias de implantação de uma forma que minimize o risco para o produto e para os usuários. (Você pode aprender mais sobre automação de pipeline de CI/CD aqui.)

Nesta postagem, discutiremos várias estratégias de implantação no Kubernetes, incluindo implantações contínuas e métodos mais avançados, como implementações canário e suas variações.

Estratégias de implantação

Existem vários tipos diferentes de estratégias de implantação que você pode usar dependendo do seu objetivo. Por exemplo, você pode precisar fazer alterações em um determinado ambiente para testes adicionais, ou em um subconjunto de usuários/clientes, ou pode precisar fazer testes de usuário limitados antes de criar um recurso. publicamente disponível.

Contínuo (implantação gradual e “contínua”)

Esta é a estratégia de implantação padrão no Kubernetes. Ele gradualmente, um por um, substitui os pods pela versão antiga do aplicativo por pods pela nova versão - sem tempo de inatividade do cluster.

O Kubernetes espera até que novos pods estejam prontos para funcionar (verificando-os usando testes de prontidão), antes de começar a enrolar os antigos. Se ocorrer um problema, esta atualização contínua poderá ser abortada sem interromper todo o cluster. No arquivo YAML que descreve o tipo de implantação, a nova imagem substitui a imagem 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 atualização de rollover podem ser especificados no arquivo de manifesto:

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

Recriar

Neste tipo mais simples de implantação, os pods antigos são eliminados todos de uma vez e substituídos por novos:

O manifesto correspondente é mais ou menos assim:

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

Azul/Verde (implantações azul-verde)

A estratégia de implantação azul-verde (às vezes também chamada de vermelho/preto) envolve a implantação simultânea das versões antiga (verde) e nova (azul) do aplicativo. Depois de postar as duas versões, os usuários regulares têm acesso à verde, enquanto a azul fica disponível para a equipe de QA automatizar os testes por meio de um serviço separado ou encaminhamento direto de porta:

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

Após a versão azul (nova) ter sido testada e seu lançamento aprovado, o serviço muda para ela e a versão verde (antiga) é dobrada:

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

Canário (implantações canário)

As implementações Canary são semelhantes às implementações azul-verde, mas têm melhor controle e uso progressivo abordagem passo a passo. Este tipo inclui diversas estratégias diferentes, incluindo lançamentos “furtivos” e testes A/B.

Essa estratégia é utilizada quando há necessidade de testar alguma funcionalidade nova, geralmente no backend da aplicação. A essência da abordagem é criar dois servidores quase idênticos: um atende quase todos os usuários e o outro, com novas funções, atende apenas um pequeno subgrupo de usuários, após o qual os resultados de seu trabalho são comparados. Se tudo correr sem erros, a nova versão será gradualmente implementada em toda a infraestrutura.

Embora esta estratégia possa ser implementada exclusivamente usando Kubernetes, substituindo pods antigos por novos, é muito mais conveniente e simples usar uma malha de serviço como o Istio.

Por exemplo, você pode ter dois manifestos diferentes no Git: um manifesto regular com a tag 0.1.0 e um manifesto canário com a tag 0.2.0. Ao alterar os pesos no manifesto do gateway virtual do Istio, você pode controlar a distribuição do tráfego entre estas duas implantações:

Para obter um guia passo a passo sobre como implementar implantações canário usando o Istio, consulte Fluxos de trabalho GitOps com Istio. (Observação. trad.: Também traduzimos material sobre lançamentos canary para o Istio aqui.)

Implantações Canary com Weaveworks Flagger

Sinalizador da Weaveworks permite que você gerencie implementações canário de maneira fácil e eficaz.

O Flagger automatiza o trabalho com eles. Ele usa Istio ou AWS App Mesh para rotear e alternar o tráfego e métricas do Prometheus para analisar os resultados. Além disso, a análise de implantações canário pode ser complementada com webhooks para realizar testes de aceitação, testes de carga e quaisquer outros tipos de verificações.

Com base na implantação do Kubernetes e, se necessário, no escalonamento horizontal de pods (HPA), o Flagger cria conjuntos de objetos (implantações do Kubernetes, serviços ClusterIP e serviços virtuais Istio ou App Mesh) para analisar e implementar implantações canário:

Implementando a malha de controle (loop de controle),O Flagger alterna gradualmente o tráfego para o servidor canário, enquanto mede simultaneamente as principais métricas de desempenho, como a porcentagem de solicitações HTTP bem-sucedidas, a duração média da solicitação e a integridade do pod. Com base na análise de KPI (Key Performance Indicators), o canário cresce ou entra em colapso e os resultados da análise são publicados no Slack. Uma descrição e demonstração deste processo podem ser encontradas no material Entrega progressiva para App Mesh.

Implantações escuras (ocultas) ou A/B

A implantação furtiva é outra variação da estratégia canário (com a qual, aliás, Flagger também pode trabalhar). A diferença entre implantações furtivas e canário é que as implantações furtivas lidam com o front-end e não com o back-end, como as implantações canário.

Outro nome para essas implantações é teste A/B. Em vez de disponibilizar o novo recurso para todos os usuários, ele é oferecido apenas a uma parte limitada deles. Normalmente, esses usuários não sabem que são testadores pioneiros (daí o termo “implantação furtiva”).

Usando opções de funcionalidade (alternância de recurso) e outras ferramentas, você pode monitorar como os usuários interagem com o novo recurso, se eles estão envolvidos com ele ou se acham a nova interface do usuário confusa e outros tipos de métricas.

Implantações sinalizadoras e A/B

Além do roteamento baseado em peso, o Flagger também pode rotear o tráfego para o servidor canário com base em parâmetros HTTP. Nos testes A/B, você pode usar cabeçalhos HTTP ou cookies para atingir um segmento específico de usuários. Isto é especialmente eficaz no caso de aplicativos frontend que exigem ligação de sessão ao servidor (afinidade da sessão). Mais informações podem ser encontradas na documentação do Flagger.

O autor é grato Stefan Prodan, engenheiro da Weaveworks (e criador do Flagger), por todos esses incríveis padrões de implantação.

Estratégias de implantação em Kubernetes: rolante, recriar, azul/verde, canário, escuro (teste A/B)