Nota perev.: Este material de revisão da Weaveworks apresenta as estratégias de implementação de aplicativos mais populares e fala sobre a possibilidade de implementar as mais avançadas delas usando o operador Kubernetes Flagger. Ele foi escrito em linguagem simples e contém diagramas visuais que possibilitam que até mesmo engenheiros iniciantes entendam o problema.
O diagrama é retirado de outra revisão das estratégias de implementação feitas na Container Solutions.Um dos maiores problemas no desenvolvimento de aplicativos nativos da nuvem hoje é implantar a implantação. Com a abordagem de microsserviço, os desenvolvedores já estão trabalhando com aplicativos totalmente modulares e projetando-os, permitindo que equipes diferentes escrevam código e façam alterações no aplicativo ao mesmo tempo.
Implantações mais curtas e frequentes têm as seguintes vantagens:
- O tempo de colocação no mercado é reduzido.
- Novos recursos alcançam os usuários mais rapidamente.
- O feedback do usuário chega à equipe de desenvolvimento mais rapidamente. Isso significa que a equipe pode complementar funções e corrigir problemas mais rapidamente.
- O moral dos desenvolvedores aumenta: é mais interessante trabalhar com um grande número de funções no desenvolvimento.
Porém, com o aumento das frequências de liberação, as chances de afetar adversamente 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 o DevOps criem processos e gerenciem estratégias de implantação de maneira a minimizar os riscos para o produto e os usuários. (Saiba mais sobre a automação de pipeline de CI / CD
aqui .)
Neste post, discutiremos várias estratégias de implantação no Kubernetes, incluindo implantações contínuas e métodos mais avançados, como lançamentos de canários e suas variações.
Estratégias de implantação
Existem vários tipos diferentes de estratégias de implantação que você pode usar com base em seu objetivo. Por exemplo, pode ser necessário fazer alterações em um determinado ambiente para testes adicionais ou em um subconjunto de usuários / clientes, ou pode ser necessário realizar testes limitados nos usuários antes de disponibilizar
publicamente alguma função.
Rolling (implantação gradual, "rolling")
Esta é uma estratégia de implantação padrão no Kubernetes. Gradualmente, um por um, substitui os pods pela versão antiga do aplicativo pelos pods pela nova versão - sem tempo de inatividade do cluster.
O Kubernetes espera até que os novos pods estejam prontos para o trabalho (verificando-os com
testes de prontidão ) antes de começar a recolher os antigos. Se ocorrer um problema, essa atualização sem interrupção pode ser interrompida sem parar o cluster inteiro. No arquivo YAML do 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 para uma atualização sem interrupção podem ser especificados no arquivo de manifesto:
spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 25% template: ...
Recriar (recriar)
Nesse tipo mais simples de implantação, os pods antigos são eliminados de uma só vez e substituídos por novos:
O manifesto correspondente é mais ou menos assim:
spec: replicas: 3 strategy: type: Recreate template: ...
Azul / Verde (implantação azul esverdeado)
A estratégia de implantação azul-verde (às vezes também chamada de vermelho / preto, ou seja, vermelho-preto) envolve a implantação simultânea das versões antiga (verde) e nova (azul) do aplicativo. Após colocar as duas versões, os usuários comuns obtêm acesso à verde, enquanto a azul está disponível para a equipe de controle de qualidade 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 sua liberação aprovada, o serviço muda para ela e o verde (antigo) é minimizado:
apiVersion: v1 kind: Service metadata: name: awesomeapp spec: selector: app: awesomeapp version: "02" ...
Canárias (implantação canária)
Os rolos canários parecem azul esverdeado, mas são melhor gerenciados e usam uma abordagem
progressiva progressiva . Esse tipo inclui várias estratégias diferentes, incluindo lançamentos "ocultos" e testes A / B.
Essa estratégia é usada quando é necessário experimentar algumas novas funcionalidades, como regra, no back-end do aplicativo. A essência da abordagem é criar dois servidores quase idênticos: um atende a quase todos os usuários e o outro, com novos recursos, atende apenas a um pequeno subconjunto de usuários, após o qual os resultados são comparados. Se tudo correr bem, a nova versão será gradualmente implementada em toda a infraestrutura.
Embora essa estratégia possa ser implementada apenas usando as ferramentas do Kubernetes, substituindo os pods antigos por novos, é muito mais conveniente e fácil usar uma malha de serviço como o Istio.
Por exemplo, você pode ter dois manifestos diferentes no Git: o regular com a tag 0.1.0 e o "canary" com a tag 0.2.0. Alterando os pesos no manifesto do gateway virtual Istio, você pode controlar a distribuição do tráfego entre essas duas implantações:
Para obter uma explicação sobre a implementação de implantações de canários com o Istio, consulte
Fluxos de trabalho do GitOps com o Istio .
( Nota : também traduzimos material sobre rolos de canário no Istio aqui .)Implantações de canários com o Weaveworks Flagger
O Weaveworks Flagger torna fácil e eficiente o gerenciamento de lançamentos de canários.
O Flagger automatiza o trabalho com eles. Ele usa o Istio ou o AWS App Mesh para rotear e alternar o tráfego, bem como as métricas do Prometheus para analisar os resultados. Além disso, a análise de implantações de canários pode ser complementada com webhooks para testes de aceitação, testes de estresse e quaisquer outros tipos de verificações.
Com base na implantação do Kubernetes e, se necessário, na escala horizontal de pod (HPA), o Flagger cria conjuntos de objetos (implantações do Kubernetes, serviços ClusterIP e serviços virtuais Istio ou App Mesh) para análise e implementação de implantações canárias:
Ao implementar um
loop de controle , o Flagger muda gradualmente o tráfego para o servidor canário, enquanto mede simultaneamente os principais indicadores de desempenho, como a porcentagem de solicitações HTTP bem-sucedidas, a duração média das solicitações e a integridade do pod. Com base na análise do KPI (principais indicadores de desempenho), a parte do canário cresce ou entra em colapso e os resultados da análise são publicados no Slack. Uma descrição e demonstração desse processo podem ser encontradas na
Entrega progressiva para o App Mesh .
Implantação escura (oculta) ou A / B
A implantação encoberta é outra variação da estratégia das canárias (a propósito, o Flagger também pode trabalhar com ela). A diferença entre implantações secretas e canárias é que implantações secretas lidam com o front-end e não com o back-end, como os canários.
Outro nome para essas implantações é teste A / B. Em vez de abrir o acesso à nova função a todos os usuários, ela é oferecida apenas a uma parte limitada deles. Normalmente, esses usuários não sabem que são testadores pioneiros (daí o termo "implantação secreta").
Usando
alternâncias de função e outras ferramentas, você pode monitorar como os usuários interagem com a nova função, se ela os cativa ou se eles acham a nova interface do usuário confusa e outros tipos de métricas.
Flagger e implantações A / B
Além do roteamento ponderado, o Flagger também pode direcionar o tráfego para o servidor canary, dependendo das configurações de HTTP. Para testes A / B, você pode usar cabeçalhos ou cookies HTTP para redirecionar um segmento específico de usuários. Isso é especialmente eficaz para aplicativos de front-end que requerem
afinidade de sessão para o servidor. Para mais informações, consulte a documentação do Flagger.
O autor agradece a Stefan Prodan , engenheiro da Weaveworks (e criador da Flagger), por todas essas implantações impressionantes.PS do tradutor
Leia também em nosso blog: