Nota de tradução: Este material de revisão da Weaveworks apresenta as estratégias de lançamento de aplicativos mais populares e discute a possibilidade de implementar as mais avançadas delas usando o operador Kubernetes Flagger. Ele é escrito de forma simples e contém diagramas ilustrativos que ajudam até mesmo os engenheiros iniciantes a entenderem o assunto.
O diagrama foi retirado de das estratégias de lançamento, feita na Container Solutions
Um dos maiores desafios no desenvolvimento de aplicativos cloud native hoje é acelerar a implantação. Com a abordagem de microsserviços, os desenvolvedores já trabalham com aplicativos totalmente modulares e os projetam, permitindo que diferentes equipes escrevam código e façam alterações no aplicativo simultaneamente.
Implantações mais curtas e frequentes têm as seguintes vantagens:
- O tempo de lançamento no mercado é reduzido.
- Novas funcionalidades chegam mais rápido aos usuários.
- O feedback dos usuários chega mais rapidamente à equipe de desenvolvimento. Isso significa que a equipe pode adicionar funcionalidades e corrigir problemas de forma mais ágil.
- O moral dos desenvolvedores aumenta: trabalhar com mais funcionalidades em desenvolvimento torna o trabalho mais interessante.
Mas, com o aumento da frequência de lançamentos, também crescem as chances de impactar negativamente a confiabilidade do aplicativo ou a experiência do usuário. Por isso, é importante que as equipes de operações e DevOps construam 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 do pipeline CI/CD) .)
Neste artigo, discutiremos diversas estratégias de implantação no Kubernetes, incluindo implantações rolling e métodos mais avançados, como implantações canárias e suas variantes.
Estratégias de deploy
Existem vários tipos diferentes de estratégias de implantação que podem ser utilizadas, dependendo do objetivo. Por exemplo, você pode precisar fazer alterações em um determinado ambiente para testes, ou em um subconjunto de usuários/clientes, ou pode ser necessário realizar testes limitados com os usuários antes de tornar uma funcionalidade pública.
Rolling (implantação gradual)
Esta é a estratégia padrão de implantação no Kubernetes. Ela substitui gradualmente, uma a uma, as pods com a versão antiga do aplicativo pelas pods com a nova versão — sem downtime no cluster.
O Kubernetes aguarda a prontidão das novas pods para operação (verificando-as com ), antes de iniciar a desativação das antigas. Se ocorrer um problema, essa atualização em camadas pode ser interrompida, sem parar todo o cluster. No arquivo YAML que descreve o tipo de deployment, a nova imagem substitui a 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: 8080Os parâmetros da atualização em camadas podem ser definidos no arquivo de manifesto:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (recriação)
Neste tipo mais simples de implantação, as antigas pods são eliminadas todas de uma vez e substituídas por novas:
O manifesto correspondente se parece com isto:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (implantação azul/vermelha)
A estratégia de implantação azul/verde (às vezes também chamada de vermelho/preto) prevê a implantação simultânea das versões antiga (verde) e nova (azul) do aplicativo. Após o deploy de ambas as versões, os usuários comuns têm acesso à versão verde, enquanto a azul está disponível para a equipe de QA para automação de testes através de um serviço separado ou encaminhamento direto de portas:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Depois que a versão azul (nova) foi testada e seu lançamento foi aprovado, o serviço é alternado para ela, e a verde (antiga) é desativada:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (implantação canário)
Implantações canárias são semelhantes às azul/verdes, mas são melhor gerenciadas e utilizam fases. Este tipo abrange várias estratégias diferentes, incluindo lançamentos "escondidos" e testes A/B.
Esta estratégia é aplicada quando é necessário testar uma nova funcionalidade, geralmente no backend da aplicação. A essência da abordagem é criar dois servidores praticamente idênticos: um atende quase todos os usuários, enquanto o outro, com novas funcionalidades, atende apenas um pequeno subgrupo de usuários, após o que os resultados de seu desempenho são comparados. Se tudo ocorrer sem erros, a nova versão é gradualmente implantada em toda a infraestrutura.
Embora essa estratégia possa ser implementada exclusivamente por meio do Kubernetes, substituindo os pods antigos pelos novos, é muito mais conveniente e simples usar um service mesh como o Istio.
Por exemplo, você pode ter dois manifestos diferentes no Git: um normal com a tag 0.1.0 e outro "canário" com a tag 0.2.0. Alterando os pesos no manifesto do gateway virtual do Istio, você pode gerenciar a distribuição do tráfego entre esses dois deployments:
Um guia passo a passo para implementar deployments canários com o Istio pode ser encontrado no material . (Nota do tradutor.: Também traduzimos o material sobre implantações canárias no Istio .)
Implantações canárias com Weaveworks Flagger
permite gerenciar implantações canárias de forma fácil e eficaz.
O Flagger automatiza o trabalho com eles. Ele usa o Istio ou o AWS App Mesh para roteamento e alternância de tráfego, assim como métricas do Prometheus para análise de resultados. Além disso, a análise das implantações canárias pode ser complementada com webhooks para realizar testes de aceitação, testes de carga e quaisquer outros tipos de verificações.
Baseando-se no deployment do Kubernetes e, se necessário, na escalabilidade horizontal dos pods (HPA), o Flagger cria conjuntos de objetos (deployments do Kubernetes, serviços ClusterIP e serviços virtuais do Istio ou do App Mesh) para realizar a análise e implementar as implantações canárias:
Implementando o contorno de controle (control loop), o Flagger gradualmente redireciona o tráfego para o servidor canário, enquanto mede indicadores-chave de desempenho, como a porcentagem de solicitações HTTP bem-sucedidas, a duração média da solicitação e a saúde dos pods. Com base na análise dos KPIs (indicadores-chave de desempenho), a parte canária cresce ou diminui, e os resultados da análise são publicados no Slack. A descrição e a demonstração desse processo podem ser encontradas no material .
Dark (ocultos) ou implantações A/B
A implantação oculta é mais uma variação da estratégia canária (com a qual, a propósito, o Flagger também pode trabalhar). A diferença entre implantações ocultas e canárias é que as implantações ocultas lidam com o front-end, e não com o back-end, como as canárias.
Outro nome para essas implantações é A/B testing. Em vez de abrir o acesso a uma nova funcionalidade para todos os usuários, ela é oferecida apenas a uma parte limitada deles. Normalmente, esses usuários não sabem que estão atuando como testadores pioneiros (daí o termo "implantações ocultas").
Com o uso de switches de funcionalidade (feature toggles) e outras ferramentas, é possível monitorar como os usuários interagem com a nova funcionalidade, se ela os atrai ou se consideram a nova interface confusa, além de outros tipos de métricas.
Flagger e implantações A/B
Além da roteação ponderada, o Flagger também pode direcionar o tráfego para um servidor canário com base em parâmetros HTTP. Em testes A/B, é possível usar cabeçalhos HTTP ou cookies para redirecionar um segmento específico de usuários. Isso é especialmente eficaz em aplicações front-end que requerem afinidade de sessão com o servidor (session affinity). Mais informações podem ser encontradas na documentação do Flagger.
O autor agradece , engenheiro da Weaveworks (e criador do Flagger), por todos esses incríveis diagramas de implantação.
P.S. do tradutor
Confira também em nosso blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
