🥇Canary-distribusjon i Kubernetes #1: Gitlab CI

Vi vil bruke Gitlab CI og manuell GitOps for å implementere og bruke Canary-distribusjon i Kubernetes

Artikler fra denne serien:

(Denne artikkelen)
Canary Deployment med ArgoCI
Canary Deployment med Istio
Canary Deployment med Jenkins-X Istio Flagger

Vi vil utføre Canary-distribusjonen manuelt via GitOps og opprette/endre de viktigste Kubernetes-ressursene. Denne artikkelen er først og fremst ment for en introduksjon med hvordan distribusjon fungerer i Kubernetes Canary, siden det er mer effektive metoder for automatisering, som vi vil vurdere i de følgende artiklene.

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

Kanariøyeutplassering

Med Canary-strategien blir oppdateringer først brukt på bare en undergruppe av brukere. Gjennom overvåking, loggdata, manuell testing eller andre tilbakemeldingskanaler, testes utgivelsen før den frigis til alle brukere.

Kubernetes Deployment (rullende oppdatering)

Standardstrategien for Kubernetes Deployment er rullende oppdatering, hvor et visst antall pods lanseres med nye versjoner av bildene. Hvis de ble opprettet uten problemer, avsluttes poder med gamle versjoner av bilder, og nye poder opprettes parallelt.

gitops

Vi bruker GitOps i dette eksemplet fordi vi:

bruker Git som en enkelt kilde til sannhet
vi bruker Git Operations for bygg og distribusjon (ingen andre kommandoer enn git tag/merge er nødvendig)

Eksempel

La oss ta en god praksis - å ha ett depot for applikasjonskode og ett for infrastruktur.

Applikasjonslager

Dette er en veldig enkel Python+Flask API som returnerer et svar som JSON. Vi vil bygge pakken via GitlabCI og sende resultatet til Gitlab-registeret. I registret har vi to forskjellige utgivelsesversjoner:

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

Den eneste forskjellen mellom dem er endringen i den returnerte JSON-filen. Vi bruker denne applikasjonen for å visualisere så enkelt som mulig hvilken versjon vi kommuniserer med.

Infrastrukturlager

I denne kålroten vil vi distribuere via GitlabCI til Kubernetes, .gitlab-ci.yml er som følger:

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

For å kjøre det selv trenger du en klynge, du kan bruke Gcloud:

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

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

Du må gaffel https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure og lag en variabel KUBECONFIG i GitlabCI, som vil inneholde konfigurasjonen for tilgang kubectl til klyngen din.

Du kan lese om hvordan du får legitimasjon for en klynge (Gcloud) her.

Infrastruktur Yaml

I infrastrukturlageret har vi tjenesten:

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

Og utplassering i 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

Og en annen utplassering i 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

Merk at app-deploy ikke har noen replikaer definert ennå.

Utfører innledende distribusjon

For å starte den første distribusjonen, kan du starte GitlabCI-rørledningen manuelt på mastergrenen. Etter det kubectl skal skrive ut følgende:

Vi ser app distribusjon med 10 replikaer og app-canary med 0. Det er også en LoadBalancer som vi kan få tilgang fra via curl via ekstern IP:

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

Vi ser at testapplikasjonen vår bare returnerer "v1".

Utfører Canary-distribusjon

Trinn 1: lanser en ny versjon for noen brukere

Vi setter antallet replikaer til 1 i filen deploy-canary.yaml og det nye versjonsbildet:

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

I fil deploy.yaml vi endret antall replikaer til 9:

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

Vi skyver disse endringene til depotet som distribusjonen vil starte fra (via GitlabCI) og ser som et resultat:

Tjenesten vår vil peke på begge distribusjonene, siden begge har appvelgeren. På grunn av Kubernetes' standard randomisering, bør vi se forskjellige svar for ~10 % av forespørslene:

Den nåværende tilstanden til applikasjonen vår (GitOps, hentet fra Git as a Single Source Of Truth) er tilstedeværelsen av to distribusjoner med aktive replikaer, en for hver versjon.

~10 % av brukerne blir kjent med en ny versjon og tester den utilsiktet. Nå er tiden inne for å se etter feil i loggene og overvåkingsdata for å finne problemer.

Trinn 2: Slipp den nye versjonen til alle brukere

Vi bestemte oss for at alt gikk bra, og nå må vi rulle ut den nye versjonen til alle brukere. For å gjøre dette oppdaterer vi ganske enkelt deploy.yaml installere en ny versjon av bildet og antall replikaer lik 10. In deploy-canary.yaml vi setter antall replikaer tilbake til 0. Etter utplassering vil resultatet bli som følger:

Oppsummering

For meg hjelper det å kjøre distribusjonen manuelt på denne måten å forstå hvor enkelt den kan konfigureres ved hjelp av k8s. Siden Kubernetes lar deg oppdatere alt via et API, kan disse trinnene automatiseres gjennom skript.

En annen ting som må implementeres er et tester-inngangspunkt (LoadBalancer eller via Ingress) som bare den nye versjonen kan nås gjennom. Den kan brukes til manuell surfing.

I fremtidige artikler vil vi sjekke ut andre automatiserte løsninger som implementerer det meste av det vi har gjort.

Les også andre artikler på bloggen vår:

Kilde: www.habr.com

Canary Deployment i Kubernetes #1: Gitlab CI