Við munum framkvæma Canary dreifinguna handvirkt í gegnum GitOps og búa til/breyta helstu Kubernetes auðlindum. Þessi grein er fyrst og fremst ætluð til kynningar með því hvernig dreifing virkar á Kubernetes Canary, þar sem það eru skilvirkari aðferðir við sjálfvirkni, sem við munum íhuga í eftirfarandi greinum.
Með Kanarístefnunni er uppfærslum fyrst beitt á aðeins undirmengi notenda. Með vöktun, gagnaskrárgögnum, handvirkum prófunum eða öðrum endurgjöfarrásum er útgáfan prófuð áður en hún er gefin út til allra notenda.
Kubernetes dreifing (uppfærsla)
Sjálfgefin stefna fyrir Kubernetes Deployment er rúllandi uppfærsla, þar sem ákveðinn fjöldi fræbelgja er settur af stað með nýjum útgáfum af myndunum. Ef þeir voru búnir til án vandræða er belg með gömlum útgáfum af myndum hætt og nýir belg eru búnir til samhliða.
gitops
Við notum GitOps í þessu dæmi vegna þess að við:
að nota Git sem eina uppsprettu sannleikans
við notum Git Operations fyrir byggingu og dreifingu (engar skipanir aðrar en git tag/merge eru nauðsynlegar)
Dæmi
Við skulum taka góða æfingu - að hafa eina geymslu fyrir forritakóða og eina fyrir innviði.
Umsóknargeymsla
Þetta er mjög einfalt Python+Flask API sem skilar svari sem JSON. Við munum byggja pakkann í gegnum GitlabCI og ýta niðurstöðunni í Gitlab Registry. Í skránni höfum við tvær mismunandi útgáfur:
wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2
Eini munurinn á milli þeirra er breytingin á JSON skránni sem skilað er. Við notum þetta forrit til að sjá eins auðveldlega og mögulegt er hvaða útgáfu við erum í samskiptum við.
Innviðageymsla
Í þessari rófu munum við dreifa í gegnum GitlabCI til Kubernetes, .gitlab-ci.yml lítur svona út:
Við ýtum þessum breytingum á geymsluna sem dreifingin mun hefjast frá (í gegnum GitlabCI) og sjáum í kjölfarið:
Þjónustan okkar mun benda á báðar uppsetningarnar þar sem báðar eru með forritavalið. Vegna sjálfgefna slembivals Kubernetes ættum við að sjá mismunandi svör fyrir ~10% beiðna:
Núverandi staða forritsins okkar (GitOps, tekið úr Git as a Single Source Of Truth) er tilvist tveggja dreifinga með virkum eftirmyndum, ein fyrir hverja útgáfu.
~10% notenda kynnast nýrri útgáfu og prófa hana óviljandi. Nú er kominn tími til að athuga hvort villur séu í annálum og eftirlitsgögnum til að finna vandamál.
Skref 2: Gefa út nýju útgáfuna fyrir alla notendur
Við ákváðum að allt gengi vel og nú þurfum við að setja nýju útgáfuna út fyrir alla notendur. Til að gera þetta uppfærum við einfaldlega deploy.yaml uppsetning nýrrar útgáfu af myndinni og fjöldi eftirmynda sem jafngildir 10. Í deploy-canary.yaml við setjum fjölda eftirmynda aftur á 0. Eftir uppsetningu verður niðurstaðan sem hér segir:
Toppur upp
Fyrir mig hjálpar það að keyra uppsetninguna handvirkt á þennan hátt til að skilja hversu auðvelt er að stilla hana með k8s. Þar sem Kubernetes gerir þér kleift að uppfæra allt í gegnum API er hægt að gera þessi skref sjálfvirk í gegnum forskriftir.
Annað sem þarf að útfæra er inngangsstaður prófunaraðila (LoadBalancer eða í gegnum Ingress) þar sem aðeins er hægt að nálgast nýju útgáfuna. Það er hægt að nota til handvirkrar vafra.
Í framtíðargreinum munum við skoða aðrar sjálfvirkar lausnir sem útfæra flest það sem við höfum gert.