Zbatimi i Kanarit duke përdorur Jenkins-X Istio Flagger
Ne do të kryejmë vendosjen Canary manualisht nëpërmjet GitOps dhe duke krijuar/modifikuar burimet kryesore të Kubernetes. Ky artikull është menduar kryesisht për hyrje me mënyrën se si funksionon vendosja në Kubernetes Canary, pasi ka metoda më efektive të automatizimit, të cilat do t'i shqyrtojmë në artikujt vijues.
Me strategjinë Canary, përditësimet aplikohen fillimisht vetëm për një nëngrup përdoruesish. Nëpërmjet monitorimit, të dhënave të regjistrit, testimit manual ose kanaleve të tjera të reagimit, lëshimi testohet përpara se të lëshohet për të gjithë përdoruesit.
Vendosja e Kubernetes (përditësim i vazhdueshëm)
Strategjia e parazgjedhur për Kubernetes Deployment është përditësimi i përsëritur, ku një numër i caktuar pods lëshohen me versione të reja të imazheve. Nëse ato u krijuan pa probleme, podet me versionet e vjetra të imazheve mbyllen dhe podet e reja krijohen paralelisht.
GitOps
Ne përdorim GitOps në këtë shembull sepse ne:
duke përdorur Git si një burim të vetëm të së vërtetës
ne përdorim Operacionet Git për ndërtimin dhe vendosjen (nuk nevojiten komanda të tjera përveç etiketës/bashkimit të git)
Shembull
Le të marrim një praktikë të mirë - të kemi një depo për kodin e aplikacionit dhe një për infrastrukturën.
Depoja e aplikacionit
Ky është një API shumë i thjeshtë Python+Flask që kthen një përgjigje si JSON. Ne do të ndërtojmë paketën përmes GitlabCI dhe do ta shtyjmë rezultatin në Regjistrin Gitlab. Në regjistër kemi dy versione të ndryshme të lëshimit:
wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2
Dallimi i vetëm midis tyre është ndryshimi në skedarin JSON të kthyer. Ne e përdorim këtë aplikacion për të vizualizuar sa më lehtë se me cilin version po komunikojmë.
Depoja e infrastrukturës
Në këtë rrepë ne do të vendosemi nëpërmjet GitlabCI në Kubernetes, .gitlab-ci.yml duket si kjo:
Ne i shtyjmë këto ndryshime në depo nga e cila do të fillojë vendosja (nëpërmjet GitlabCI) dhe shohim si rezultat:
Shërbimi ynë do të tregojë për të dy vendosjet, pasi të dyja kanë përzgjedhësin e aplikacionit. Për shkak të rastësisë së paracaktuar të Kubernetes, ne duhet të shohim përgjigje të ndryshme për ~ 10% të kërkesave:
Gjendja aktuale e aplikacionit tonë (GitOps, marrë nga Git si një burim i vetëm i së vërtetës) është prania e dy vendosjeve me kopje aktive, një për çdo version.
~10% e përdoruesve njihen me një version të ri dhe e testojnë pa dashje. Tani është koha për të kontrolluar për gabime në regjistrat dhe të dhënat e monitorimit për të gjetur probleme.
Hapi 2: Lëshoni versionin e ri për të gjithë përdoruesit
Ne vendosëm që gjithçka shkoi mirë dhe tani duhet të prezantojmë versionin e ri për të gjithë përdoruesit. Për ta bërë këtë, ne thjesht përditësojmë deploy.yaml instalimi i një versioni të ri të imazhit dhe numri i kopjeve të barabarta me 10. In deploy-canary.yaml ne vendosëm përsëri numrin e kopjeve në 0. Pas vendosjes, rezultati do të jetë si më poshtë:
Duke përmbledhur
Për mua, ekzekutimi manual i vendosjes në këtë mënyrë ndihmon për të kuptuar se sa lehtë mund të konfigurohet duke përdorur k8s. Meqenëse Kubernetes ju lejon të përditësoni gjithçka përmes një API, këto hapa mund të automatizohen përmes skripteve.
Një tjetër gjë që duhet të zbatohet është një pikë hyrëse e testuesit (LoadBalancer ose nëpërmjet Ingress) përmes së cilës mund të aksesohet vetëm versioni i ri. Mund të përdoret për shfletim manual.
Në artikujt e ardhshëm, ne do të shqyrtojmë zgjidhje të tjera të automatizuara që zbatojnë pjesën më të madhe të asaj që kemi bërë.
Lexoni gjithashtu artikuj të tjerë në blogun tonë: