Canary Deployment i Kubernetes #1: Gitlab CI

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

Artiklene i denne serien:

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

Vi vil utføre Canary-deployment manuelt gjennom GitOps og oppretting/endring av grunnleggende Kubernetes-ressurser. Denne artikkelen er primært ment for å bli introdusert for hvordan Canary-deployment fungerer i Kubernetes, ettersom det finnes mer effektive automatiseringsmetoder som vi vil se nærmere på i de kommende artiklene.

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

Canary Deployment

Med Canary-strategien for oppdatering blir endringene først brukt på bare en del av brukerne. Gjennom overvåking, loggdata, manuell testing eller andre tilbakemeldingskanaler blir versjonen testet før den brukes av alle brukere.

Kubernetes Deployment (rolling update)

Standard strategien for Kubernetes Deployment er rolling-update, hvor et bestemt antall podder med de nye versjonene av bildene blir startet. Hvis de opprettes uten problemer, avsluttes poddene med de gamle versjonene av bildene, og nye podder blir opprettet parallelt.

GitOps

Vi bruker GitOps i dette eksemplet fordi vi:

• bruker Git som den eneste sannhetskilden
• bruger Git Operations for bygging og distribusjon (ingen kommandoer annet enn git tag/merge er nødvendig)

Eksempel

La oss ta en god praksis — ha ett repository for applikasjonskode og ett for infrastruktur.

Repository for applikasjoner

Dette er et veldig enkelt API i Python+Flask som returnerer et svar i JSON-format. Vi vil bygge pakken gjennom GitlabCI og pushe resultatet til Gitlab Registry. I registrering har vi to forskjellige versjoner av utgivelser:

• 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 å gi en svært enkel visualisering av hvilken versjon vi kommuniserer med.

Infrastrukturrepository

I denne repoen vil vi deploye gjennom GitlabCI i Kubernetes, .gitlab-ci.yml ser slik ut:

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 et 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å gjøre en fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure og opprette en variabel KUBECONFIG i GitlabCI, som vil inneholde konfigurasjonen for tilgang kubectl til klyngen din.

Hvordan du får tilgang til legitimasjonen for klyngen (Gcloud) kan du lese om her.

Infrastruktur-YAML

I infrastruktur-repositoriet har vi service:

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

Og deployment 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 deployment 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 for tiden ikke har definerte replikasjoner.

Utføring av initial deployment

For å starte den initiale deployment kan du manuelt kjøre GitlabCI-pipelinen i master-grenen. Etter dette kubectl bør det gi følgende:

Vi ser app deployment med 10 replikasjoner og app-canary med 0. Det er også LoadBalancer som vi kan nå via wget på ekstern IP:

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

Vi ser at vår test-applikasjon kun returnerer “v1”.

Utføring av Canary-deployment

Trinn 1: utgi en ny versjon for en del av brukerne

Vi satte antallet replikasjoner til 1 i filen deploy-canary.yaml og bildet for den nye versjonen:

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 filen deploy.yaml vi endret antallet replikasjoner til 9:

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

Vi pusher disse endringene til repositoriet hvor deployen vil bli utført (via GitlabCI) og ser til slutt:

Vår Service vil peke på begge deploys, siden begge har selektor app. På grunn av tilfeldig fordeling som standard i Kubernetes bør vi se ulike svar på ~ 10% av forespørslene:

Den nåværende tilstanden til applikasjonen vår (GitOps, hentet fra Git som Single Source Of Truth) er tilstedeværelsen av to deployments med aktive replikasjoner, én for hver versjon.

~10% av brukerne blir kjent med den nye versjonen og tester den utilsiktet. Nå er det på tide å sjekke for feil i loggene og overvåkingsdata for å finne problemer.

Trinn 2: utgi en ny versjon for alle brukere

Vi har bestemt oss for at alt har gått bra, og nå må vi distribuere den nye versjonen til alle brukere. For dette oppdaterer vi bare deploy.yaml ved å installere den nye bildeversjonen og sette antall replikaer til 10. I deploy-canary.yaml setter vi antall replikaer tilbake til 0. Etter distribusjonen vil resultatet bli som følger:

Oppsummering

For meg hjelper det å starte distribusjonen manuelt på denne måten for å forstå hvor enkelt det kan konfigureres ved hjelp av k8s. Siden Kubernetes tillater oppdateringer via API, kan disse trinnene automatiseres gjennom skript.

En annen ting som må implementeres er inngangspunktet for testeren (LoadBalancer eller via Ingress), som gir tilgang bare til den nye versjonen. Dette kan brukes for manuell gjennomgang.

I følgende artikler skal vi se på andre automatiserte løsninger som implementerer det meste av det vi har gjort.

Les også andre artikler i bloggen vår:

• Hva førte migrasjonen fra ClickHouse uten autentisering til ClickHouse med autentisering
• Bygging av dynamiske moduler for Nginx
• Oppdatering av nxs-build-tools - verktøyet for bygging av deb- og rpm-pakker
• Introduksjon til Hashicorp Consul’s Kubernetes Autorisasjon
• Hva vi måtte håndtere ved bruk av verktøyet Csync2
• Telegram-bot for Redmine. Hvordan forenkle livet for seg selv og folk

Kilde: habr.com