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.
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:
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.