🥇Implantação Canary no Kubernetes #2: Implementações do Argo

Usaremos o controlador de implantação Argo Rollouts nativo de k8s e GitlabCI para executar implantações Canary no Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Artigos desta série

Implantação Canary no Kubernetes nº 1: Gitlab CI
(Este artigo)
Implantação canário usando Istio
Implantação Canary usando Jenkins-X Istio Flagger

Implantação canário

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

Lançamentos do Argo

Argo Rollouts é um controlador de implantação nativo do Kubernetes. Ele fornece um CRD (definição de recursos personalizados) para Kubernetes. Graças a isso, podemos usar uma nova entidade: Rollout, que gerencia implantações azul-verde e canário com diversas opções de configuração.

Controlador Argo Rollouts usado por um recurso personalizado Rollout, Permite estratégias de implantação adicionais, como azul-verde e canário para Kubernetes. Recurso Rollout fornece funcionalidade equivalente Deployment, apenas com estratégias de implantação adicionais.
recurso Deployments tem duas estratégias para implantação: RollingUpdate и Recreate. Embora essas estratégias sejam adequadas para a maioria dos casos, para implantação em servidores em grande escala, são utilizadas estratégias adicionais, como azul-verde ou canário, que não estão disponíveis no controlador de implantação. Para usar essas estratégias no Kubernetes, os usuários tiveram que escrever scripts além de suas implantações. O Argo Rollouts Controller expõe essas estratégias como parâmetros simples, declarativos e configuráveis.
https://argoproj.github.io/argo-rollouts

Há também o Argo CI, que fornece uma interface web conveniente para uso com Rollouts, veremos isso no próximo artigo.

Instalando implementações Argo

Lado do servidor

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

Em nosso nabo de infraestrutura (veja abaixo) já adicionamos install.yaml como i/k8s/argo-rollouts/install.yaml. Desta forma, o GitlabCI irá instalá-lo no cluster.

Lado do cliente (plug-in kubectl)

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

Exemplo de aplicação

É uma boa prática ter repositórios separados para código e infraestrutura de aplicativos.

Repositório para o aplicativo

Kim Wuestkamp/k8s-deployment-example-app

Esta é uma API Python+Flask muito simples que retorna uma resposta como JSON. Construiremos o pacote usando GitlabCI e enviaremos o resultado para o Registro Gitlab. No registro, temos duas versões de lançamento diferentes:

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 o mais facilmente possível com qual versão estamos nos comunicando.

Repositório de infraestrutura

Neste repositório usaremos GitlabCI para implantação no Kubernetes, .gitlab-ci.yml se parece com isto:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

Para executá-lo você mesmo precisará de um cluster, você pode 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 de um garfo https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure e crie uma variável KUBECONFIG no GitlabCI, que conterá a configuração para acesso kubectl para o seu cluster.

é Você pode ler sobre como obter credenciais para um cluster (Gcloud).

Infraestrutura Yaml

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
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout funciona da mesma forma que a implantação. Se não definirmos uma estratégia de atualização (como canário aqui), ela se comportará como a implantação de atualização contínua padrão.

Definimos duas etapas no yaml para implantação canário:

10% do tráfego para canário (aguarde OK manual)
50% do tráfego para canário (espere 2 minutos e continue até 100%)

Executando a implantação inicial

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

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

Executando implantação canário

Etapa 1: 10% de tráfego

Para iniciar uma implantação canário, precisamos apenas alterar a versão da imagem como normalmente fazemos com 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 nós enviamos mudanças, então o Gitlab CI implanta e vemos as mudanças:

Agora se acessarmos o serviço:

Ótimo! Estamos no meio de nossa implantação canário. Podemos ver o progresso executando:

kubectl argo rollouts get rollout rollout-canary

Etapa 2: 50% de tráfego:

Agora vamos para a próxima etapa: redirecionar 50% do tráfego. Configuramos esta etapa para ser executada manualmente:

kubectl argo rollouts promote rollout-canary # continue to step 2

E nosso aplicativo retornou 50% das respostas das novas versões:

E revisão de lançamento:

Ótimo.

Etapa 3: 100% de tráfego:

Configuramos para que após 2 minutos o passo de 50% termine automaticamente e o passo de 100% comece:

E a saída do aplicativo:

E revisão de lançamento:

A implantação canário foi concluída.

Mais exemplos com Argo Rollouts

Há mais exemplos aqui, como configurar visualizações e comparações de ambiente com base em canário:

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

Vídeo sobre lançamentos do Argo e Argo CI

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

Total

Gosto muito da ideia de usar CRDs que gerenciam a criação de tipos adicionais de implantações ou replicasets, redirecionam tráfego, etc. Trabalhar com eles é tranquilo. A seguir gostaria de testar a integração com Argo CI.

No entanto, parece haver uma grande fusão entre Argo CI e Flux CI, então posso esperar até que a nova versão seja lançada: Fluxo Argo.

Você já teve alguma experiência com Argo Rollouts ou Argo CI?