Canary Deployment ved hjælp af Jenkins-X Istio Flagger
Vi vil udføre Canary-implementeringen manuelt via GitOps og oprette/ændre de vigtigste Kubernetes-ressourcer. Denne artikel er primært beregnet til introduktion med hvordan udrulning fungerer i Kubernetes Canary, da der er mere effektive metoder til automatisering, som vi vil overveje i de følgende artikler.
Med Canary-strategien anvendes opdateringer først på kun en undergruppe af brugere. Gennem overvågning, logdata, manuel test eller andre feedbackkanaler testes udgivelsen, inden den frigives til alle brugere.
Kubernetes-implementering (rullende opdatering)
Standardstrategien for Kubernetes Deployment er rullende opdatering, hvor et vist antal pods lanceres med nye versioner af billederne. Hvis de blev oprettet uden problemer, afsluttes pods med gamle versioner af billeder, og nye pods oprettes parallelt.
GitOps
Vi bruger GitOps i dette eksempel, fordi vi:
ved at bruge Git som en enkelt kilde til sandhed
vi bruger Git Operations til opbygning og implementering (ingen andre kommandoer end git tag/merge er nødvendige)
Eksempel
Lad os tage en god praksis - at have ét lager til applikationskode og et til infrastruktur.
Applikationslager
Dette er en meget simpel Python+Flask API, der returnerer et svar som JSON. Vi vil bygge pakken via GitlabCI og skubbe resultatet til Gitlab Registry. I registreringsdatabasen har vi to forskellige udgivelsesversioner:
wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2
Den eneste forskel mellem dem er ændringen i den returnerede JSON-fil. Vi bruger denne applikation til så let som muligt at visualisere, hvilken version vi kommunikerer med.
Infrastrukturlager
I denne majro vil vi implementere via GitlabCI til Kubernetes, .gitlab-ci.yml er som følger:
Vi skubber disse ændringer til det lager, hvorfra implementeringen starter (via GitlabCI) og ser som et resultat:
Vores service vil pege på begge implementeringer, da begge har appvælgeren. På grund af Kubernetes' standard randomisering bør vi se forskellige svar for ~10 % af anmodningerne:
Den aktuelle tilstand af vores applikation (GitOps, taget fra Git as a Single Source Of Truth) er tilstedeværelsen af to implementeringer med aktive replikaer, en for hver version.
~10 % af brugerne bliver bekendt med en ny version og tester den utilsigtet. Nu er det tid til at tjekke for fejl i logfilerne og overvågningsdata for at finde problemer.
Trin 2: Frigiv den nye version til alle brugere
Vi besluttede, at alt gik godt, og nu skal vi udrulle den nye version til alle brugere. For at gøre dette opdaterer vi blot deploy.yaml installation af en ny version af billedet og antallet af replikaer svarende til 10. In deploy-canary.yaml vi sætter antallet af replikaer tilbage til 0. Efter implementering vil resultatet være som følger:
Opsummering
For mig hjælper det at køre installationen manuelt på denne måde med at forstå, hvor nemt det kan konfigureres ved hjælp af k8s. Da Kubernetes giver dig mulighed for at opdatere alt via en API, kan disse trin automatiseres gennem scripts.
En anden ting, der skal implementeres, er et testindgangspunkt (LoadBalancer eller via Ingress), hvorigennem kun den nye version kan tilgås. Den kan bruges til manuel browsing.
I fremtidige artikler vil vi tjekke andre automatiserede løsninger, der implementerer det meste af det, vi har gjort.