Implementazione di Canary in Kubernetes #1: Gitlab CI

Useremu Gitlab CI è GitOps manuale per implementà è aduprà a implementazione di Canary in Kubernetes

Articuli di sta serie:

• (Stu articulu)
• Implementazione di Canary cù ArgoCI
• Implementazione Canaria cù Istio
• Implementazione di Canary cù Jenkins-X Istio Flagger

Eseguiremu a implementazione di Canary manualmente via GitOps è creendu / mudificà e risorse principali di Kubernetes. Questu articulu hè destinatu principalmente à l'intruduzioni cù cumu u travagliu di implementazione in Kubernetes Canary, postu chì ci sò metudi più efficaci d'automatizazione, chì avemu da cunsiderà in l'articuli seguenti.

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

Impiegazione Canaria

Cù a strategia Canary, l'aghjurnamenti sò prima appiicati à solu un subset di utilizatori. Attraversu u monitoraghju, i dati di log, a prova manuale, o altri canali di feedback, a liberazione hè pruvata prima di esse liberata à tutti l'utilizatori.

Implementazione di Kubernetes (aggiornamentu rolling)

A strategia predeterminata per Kubernetes Deployment hè rolling-update, induve un certu numaru di pods sò lanciati cù novi versioni di l'imaghjini. S'elli sò stati creati senza prublemi, i baccelli cù versioni antichi di l'imaghjini sò terminati, è i novi podi sò creati in parallelu.

GitOps

Usemu GitOps in questu esempiu perchè avemu:

• utilizendu Git cum'è una sola fonte di verità
• usemu Git Operations per a custruzione è l'implementazione (nessun cumandamentu altru ch'è git tag / merge sò necessarii)

Esempiu:

Pigliemu una bona pratica - per avè un repository per u codice di l'applicazione è unu per l'infrastruttura.

Repositoriu di l'applicazioni

Questa hè una API Python + Flask assai simplice chì torna una risposta cum'è JSON. Custruiremu u pacchettu via GitlabCI è spinghje u risultatu à u Registru Gitlab. In u registru avemu duie versioni di liberazione diverse:

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

L'unica diferenza trà elli hè u cambiamentu in u schedariu JSON restituitu. Utilizemu sta applicazione per visualizà u più faciule pussibule cù quale versione avemu cumunicatu.

Repositoriu di l'infrastruttura

In questu turnip, implementeremu via GitlabCI à Kubernetes, .gitlab-ci.yml Hè cum'è a siguenti manera:

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

Per eseguisce sè stessu, avete bisognu di un cluster, pudete aduprà Gcloud:

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

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

Avete bisognu di furchetta https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure è crea una variabile KUBECONFIG in GitlabCI, chì cuntene a cunfigurazione per l'accessu kubectl à u vostru cluster.

Pudete leghje cumu uttene credenziali per un cluster (Gcloud) quì quì.

Infrastruttura Yaml

In u repositoriu di l'infrastruttura avemu u serviziu:

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

E implementazione in 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

È un altru implementazione in 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

Nota chì l'app-deploy ùn hà micca ancora definite rèpliche.

Esecuzione di implementazione iniziale

Per inizià a implementazione iniziale, pudete inizià a pipeline GitlabCI manualmente in u ramu maestru. Eppo kubectl duverebbe pruduce i seguenti:

Avemu vistu app implementazione cù 10 replicas è app-canary cù 0. Ci hè ancu un LoadBalancer da quale pudemu accede à traversu curl via IP Esterna:

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

Avemu vistu chì a nostra applicazione di prova torna solu "v1".

Esecuzione di implementazione di Canary

Passu 1: liberate una nova versione per alcuni utilizatori

Fixemu u numeru di repliche à 1 in u schedariu deploy-canary.yaml è l'imaghjini di a nova versione:

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

In u schedariu deploy.yaml avemu cambiatu u numeru di repliche à 9:

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

Impulsemu questi cambiamenti à u repository da quale u implementazione principiarà (via GitlabCI) è vedemu u risultatu:

U nostru serviziu indicà à e duie implementazioni, postu chì tutti dui anu u selettore di app. A causa di a randomizazione predeterminata di Kubernetes, duvemu vede diverse risposte per ~ 10% di e dumande:

U statu attuale di a nostra applicazione (GitOps, pigliatu da Git cum'è una sola fonte di verità) hè a prisenza di duie implementazioni cù rèpliche attive, una per ogni versione.

~ 10% di l'utilizatori diventanu familiarizati cù una nova versione è a prova involontariamente. Avà hè u tempu di verificà l'errore in i logs è i dati di monitoraghju per truvà prublemi.

Passu 2: Release a nova versione à tutti l'utilizatori

Avemu decisu chì tuttu hè andatu bè è avà avemu bisognu di sparghje a nova versione à tutti l'utilizatori. Per fà questu avemu solu aghjurnà deploy.yaml installendu una nova versione di l'imaghjini è u nùmeru di repliche uguali à 10. In deploy-canary.yaml avemu stabilitu u nùmeru di rèpliche torna à 0. Dopu a distribuzione, u risultatu serà cusì:

Per sintetizà

Per mè, eseguisce a implementazione manualmente in questu modu aiuta à capisce quantu facilmente pò esse cunfiguratu cù k8s. Siccomu Kubernetes vi permette di aghjurnà tuttu via una API, sti passi ponu esse automatizati per scripts.

Un'altra cosa chì deve esse implementata hè un puntu d'entrata di tester (LoadBalancer o via Ingress) attraversu quale solu a nova versione pò esse accessu. Pò esse usatu per a navigazione manuale.

In articuli futuri, cuntrolleremu altre soluzioni automatizate chì implementanu a maiò parte di ciò chì avemu fattu.

Leghjite ancu altri articuli nantu à u nostru blog:

• Chì hà purtatu a migrazione da ClickHouse senza autorizazione à ClickHouse cù l'autorizazione?
• Custruì moduli dinamichi per Nginx
• Aghjurnate nxs-build-tools - un assistente in a custruzione di pacchetti deb è rpm
• Introduzione à l'Autorizazione Kubernetes di Hashicorp Consul
• Ciò chì avemu avutu affruntà quandu utilizendu l'utilità Csync2
• Telegram bot per Redmine. Cumu fà a vita più faciule per sè stessu è per l'altri

Source: www.habr.com