🥇Deploy Canary no Kubernetes #2: Argo Rollouts

Vamos usar o controlador de implantação nativo do k8s, Argo Rollouts, e o GitlabCI para lançar implantações Canary no Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artigos desta série

🥇StealthWatch: análise e investigação de incidentes. Parte 3 | ProHoster
(Este artigo)
Implantação Canary usando Istio
Implantação Canary usando Jenkins-X Istio Flagger

Canary Deployment

Esperamos que você tenha lido a primeira parte, onde explicamos brevemente o que são implantações Canary. Também mostramos como implementá-las usando os recursos padrão do Kubernetes.

Argo Rollouts

Argo Rollouts é um controlador de implantação nativo do Kubernetes. Ele fornece CRD (Definição de Recurso Personalizado) para o Kubernetes. Com isso, podemos usar uma nova entidade: Rollout, que gerencia implantações blue-green e canary com várias opções de configuração.

O controlador Argo Rollouts, usado com o recurso personalizado Rollout, permite o uso de estratégias adicionais de implantação, como blue-green e canary para Kubernetes. O recurso Rollout fornece funcionalidade equivalente Deployment, apenas com estratégias de implantação adicionais.
Recurso Implantações têm duas estratégias de implantação: RollingUpdate e Recreate. Embora essas estratégias sejam adequadas para a maioria dos casos, implantações em servidores em grande escala utilizam estratégias adicionais, como blue-green ou canary, que não estão disponíveis no controlador de Implantação. Para usar essas estratégias no Kubernetes, os usuários precisavam escrever scripts sobre suas Implantação. O controlador Argo Rollouts fornece essas estratégias como parâmetros configuráveis e simples de declarar.
https://argoproj.github.io/argo-rollouts

Existem também Argo CI, que oferece uma interface web conveniente para uso junto com Rollouts; abordaremos este assunto no próximo artigo.

Instalação do Argo Rollouts

Do lado do servidor

kubectl create namespace argo-rollouts kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

Em nosso repositório de infraestrutura (veja abaixo), já adicionamos install.yaml como i/k8s/argo-rollouts/install.yaml. Assim, o GitlabCI o instalará no cluster.

Do lado do cliente (plugin do kubectl)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Aplicativo de exemplo

Uma boa prática é ter repositórios separados para o código do aplicativo e para a infraestrutura.

Repositório do aplicativo

Kim Wuestkamp / k8s-deployment-example-app

Este é um API muito simples em Python+Flask, que retorna uma resposta em formato JSON. Vamos empacotar usando o GitlabCI e enviar o resultado para o Registro do Gitlab. No registro, temos duas versões diferentes de lançamentos:

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

A única diferença entre eles é o arquivo JSON retornado. Usamos este aplicativo para visualizar da maneira mais simples com qual versão estamos interagindo.

Repositório de infraestrutura

Neste repositório, usaremos o GitlabCI para implantar no Kubernetes, o arquivo .gitlab-ci.yml é o seguinte:

imagem: traherom/kustomize-dockerantes_do_script:
   - printenv
   - kubectl versãoestágios:
 - implantaçãodeploy teste:
   estágio: implantar
   antes_do_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    apenas:
     - master

Para executá-lo por conta própria, você precisará de um cluster, podendo usar o Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

Você precisa fazer um fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure e criar uma variável KUBECONFIG no GitlabCI, que conterá a configuração para acesso kubectl ao seu cluster.

Aqui pode-se ler sobre como obter credenciais para o cluster (Gcloud).

Yaml de infraestrutura

Dentro do repositório de infraestrutura, temos o serviço:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

e rollout.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Os Rollouts podem ser retomados manualmente executando `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # dois minutos

Rollout funciona da mesma forma que o Deployment. Se não definirmos uma estratégia de atualização (como canary aqui), ele se comportará como um Deployment de rolling-update padrão.

Definimos dois passos em yaml para implantação canary:

10% do tráfego para canary (aguardando autorização manual)
50% do tráfego para canary (aguardando 2 minutos e depois continuando para 100%)

Execução da implantação inicial

Após a implantação inicial, nossos recursos parecerão assim:

E recebemos resposta apenas da primeira versão do aplicativo:

Executando Canary Deployment

Passo 1: 10% do tráfego

Para iniciar a implantação canary, precisamos apenas alterar a versão da imagem, como costumamos fazer nas implantações:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

E fazemos o push das alterações, então o Gitlab CI faz o deploy e vemos as alterações:

Agora, se acessarmos o serviço:

Ótimo! Estamos no meio do nosso canary deployment. Podemos ver o progresso executando:

kubectl argo rollouts get rollout rollout-canary

Passo 2: 50% do tráfego:

Agora vamos para o próximo passo: redirecionamento de 50% do tráfego. Configuramos para que esse passo seja iniciado manualmente:

kubectl argo rollouts promote rollout-canary # continue para o passo 2

E nossa aplicação retornou 50% das respostas das novas versões:

E a visão geral do rollout:

Ótimo.

Passo 3: 100% do tráfego:

Configurações para que após 2 minutos, o passo com 50% seja concluído automaticamente e o passo com 100% comece:

E a saída da aplicação:

E a visão geral do rollout:

O deploy Canary foi concluído.

Mais exemplos com Argo Rollouts

Aqui estão mais exemplos, como configurar visualizações de ambiente e comparações baseadas em canary:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Vídeo sobre Argo Rollouts e Argo CI

Eu realmente recomendo este vídeo, ele mostra como Argo Rollouts e Argo CI funcionam juntos:

Por que no hosting comum a administração do PrestaShop é lenta, e no seu não é?

Resultado

Gosto muito da ideia de usar CRDs que gerenciam a criação de tipos adicionais de deployments ou replicasets, redirecionando tráfego, etc. A interação com eles é suave. Em seguida, gostaria de testar a integração com Argo CI.

No entanto, aparentemente, está a caminho uma grande fusão do Argo CI e Flux CI, então eu poderia esperar até que uma nova versão seja lançada: Argo Flux.

Você teve experiência com Argo Rollouts ou Argo CI?