Implementación de Canary en Kubernetes #1: Gitlab CI

Usaremos Gitlab CI e GitOps manual para implementar e usar a implantación de Canary en Kubernetes

Artigos desta serie:

• (Este artigo)
• Despliegue Canary usando ArgoCI
• Despliegue Canary usando Istio
• Implementación de Canary usando Jenkins-X Istio Flagger

Realizaremos o despregamento de Canary manualmente a través de GitOps e creando/modificando os principais recursos de Kubernetes. Este artigo está destinado principalmente á introdución con como funciona a implantación en Kubernetes Canary, xa que existen métodos de automatización máis eficaces, que teremos en conta nos seguintes artigos.

https://www.norberteder.com/canary-deployment/

Despliegue Canario

Coa estratexia Canary, as actualizacións aplícanse primeiro só a un subconxunto de usuarios. Mediante o seguimento, os datos de rexistro, as probas manuais ou outras canles de comentarios, a versión probárase antes de que se lance a todos os usuarios.

Implementación de Kubernetes (actualización continua)

A estratexia predeterminada para a implementación de Kubernetes é a actualización continua, onde se lanzan un certo número de pods con novas versións das imaxes. Se se crearon sen problemas, as vainas con versións antigas de imaxes rematan e créanse novas en paralelo.

GitOps

Usamos GitOps neste exemplo porque:

• usando Git como fonte única de verdade
• usamos Git Operations para a compilación e a implantación (non se necesitan comandos distintos de git tag/merge)

Exemplo

Tomemos unha boa práctica: ter un repositorio para o código da aplicación e outro para a infraestrutura.

Repositorio de aplicacións

Esta é unha API de Python+Flask moi sinxela que devolve unha resposta como JSON. Construiremos o paquete a través de GitlabCI e enviaremos o resultado ao Rexistro de Gitlab. No rexistro temos dúas versións diferentes:

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

A única diferenza entre eles é o cambio no ficheiro JSON devolto. Usamos esta aplicación para visualizar o máis facilmente posible con que versión nos estamos comunicando.

Repositorio de infraestruturas

Neste nabo implementaremos a través de GitlabCI en Kubernetes, .gitlab-ci.yml parece así:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

Para executalo vostede mesmo, necesitará un clúster, pode usar Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

Necesitas bifurcar https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure e crea unha variable KUBECONFIG en GitlabCI, que conterá a configuración de acceso kubectl ao teu clúster.

Podes ler sobre como obter credenciais para un clúster (Gcloud) aquí.

Infraestrutura Yaml

No repositorio de infraestruturas temos o servizo:

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

E despregamento en deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

E outra implantación en deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Teña en conta que app-deploy aínda non ten ningunha réplica definida.

Realización da implantación inicial

Para iniciar a implantación inicial, pode iniciar manualmente a canalización de GitlabCI na rama mestra. Despois diso kubectl debería producir o seguinte:

Vemos app despregamento con 10 réplicas e app-canary con 0. Tamén hai un LoadBalancer desde o que podemos acceder a través curl vía IP externa:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

Vemos que a nosa aplicación de proba só devolve "v1".

Execución do despregamento de Canary

Paso 1: lanzar unha nova versión para algúns usuarios

Establecemos o número de réplicas en 1 no ficheiro deploy-canary.yaml e na imaxe da nova versión:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

En arquivo deploy.yaml cambiamos o número de réplicas a 9:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

Impulsamos estes cambios no repositorio desde o que comezará a implementación (a través de GitlabCI) e vemos como resultado:

O noso servizo apuntará a ambas as implementacións, xa que ambas teñen o selector de aplicacións. Debido á aleatorización predeterminada de Kubernetes, deberíamos ver respostas diferentes para ~10 % das solicitudes:

O estado actual da nosa aplicación (GitOps, tomado de Git as a Single Source Of Truth) é a presenza de dúas implementacións con réplicas activas, unha para cada versión.

~10 % dos usuarios familiarízanse cunha nova versión e proban sen querer. Agora é o momento de comprobar se hai erros nos rexistros e os datos de seguimento para atopar problemas.

Paso 2: lanza a nova versión para todos os usuarios

Decidimos que todo saíu ben e agora necesitamos lanzar a nova versión a todos os usuarios. Para iso simplemente actualizamos deploy.yaml instalando unha nova versión da imaxe e o número de réplicas igual a 10. En deploy-canary.yaml volvemos establecer o número de réplicas en 0. Despois da implantación, o resultado será o seguinte:

Resumo

Para min, executar a implementación manualmente deste xeito axuda a comprender a facilidade con que se pode configurar usando k8s. Dado que Kubernetes permíteche actualizar todo mediante unha API, estes pasos pódense automatizar mediante scripts.

Outra cousa que hai que implementar é un punto de entrada do probador (LoadBalancer ou vía Ingress) a través do cal só se pode acceder á nova versión. Pódese usar para a navegación manual.

En artigos futuros, consultaremos outras solucións automatizadas que implementan a maior parte do que fixemos.

Lea tamén outros artigos no noso blog:

• En que provocou a migración de ClickHouse sen autorización a ClickHouse con autorización?
• Creación de módulos dinámicos para Nginx
• Actualiza nxs-build-tools: un asistente para crear paquetes deb e rpm
• Introdución á autorización Kubernetes de Hashicorp Consul
• O que tivemos que facer fronte ao usar a utilidade Csync2
• Bot de Telegram para Redmine. Como simplificar a vida para ti e para os demais

Fonte: www.habr.com