Kanāriju izvietošana, izmantojot Jenkins-X Istio Flagger
Mēs veiksim Canary izvietošanu manuāli, izmantojot GitOps un izveidojot/pārveidojot galvenos Kubernetes resursus. Šis raksts galvenokārt ir paredzēts ievadam ar to, kā izvietošana darbojas Kubernetes Canary, jo ir efektīvākas automatizācijas metodes, kuras mēs apsvērsim turpmākajos rakstos.
Izmantojot Canary stratēģiju, atjauninājumi vispirms tiek lietoti tikai lietotāju apakškopai. Izmantojot pārraudzību, žurnāla datus, manuālu testēšanu vai citus atgriezeniskās saites kanālus, laidiens tiek pārbaudīts, pirms tas tiek izlaists visiem lietotājiem.
Kubernetes izvietošana (pastāvīgs atjauninājums)
Kubernetes izvietošanas noklusējuma stratēģija ir nepārtraukta atjaunināšana, kurā tiek palaists noteikts skaits aplikumu ar jaunām attēlu versijām. Ja tie tika izveidoti bez problēmām, pāksti ar vecām attēlu versijām tiek pārtraukti un paralēli tiek izveidoti jauni podi.
GitOps
Šajā piemērā mēs izmantojam GitOps, jo mēs:
izmantojot Git kā vienotu patiesības avotu
mēs izmantojam Git Operations izveidei un izvietošanai (nav vajadzīgas citas komandas, izņemot git tagu/merge)
Piemērs
Pieņemsim labu praksi – lai būtu viens repozitorijs lietojumprogrammas kodam un viens infrastruktūrai.
Lietojumprogrammu repozitorijs
Šī ir ļoti vienkārša Python+Flask API, kas atgriež atbildi kā JSON. Mēs izveidosim pakotni, izmantojot GitlabCI, un nosūtīsim rezultātu Gitlab reģistram. Reģistrā mums ir divas dažādas laidiena versijas:
wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2
Vienīgā atšķirība starp tām ir izmaiņas atgrieztajā JSON failā. Mēs izmantojam šo lietojumprogrammu, lai pēc iespējas vienkāršāk vizualizētu, ar kuru versiju mēs sazināmies.
Infrastruktūras repozitorijs
Šajā rāceņā mēs caur GitlabCI izvietosim Kubernetes, .gitlab-ci.yml ir šāds:
Mēs virzām šīs izmaiņas repozitorijā, no kuras sāksies izvietošana (izmantojot GitlabCI), un rezultātā redzam:
Mūsu pakalpojums norādīs uz abiem izvietojumiem, jo abiem ir lietotņu atlasītājs. Kubernetes noklusējuma randomizācijas dēļ mums vajadzētu redzēt dažādas atbildes uz ~ 10% pieprasījumu:
Pašreizējais mūsu lietojumprogrammas stāvoklis (GitOps, kas ņemts no Git kā vienots patiesības avots) ir divu izvietojumu klātbūtne ar aktīvām replikām, viena katrai versijai.
~10% lietotāju iepazīst jaunu versiju un netīši to testē. Tagad ir pienācis laiks pārbaudīt, vai žurnālos un pārraudzības datos nav kļūdu, lai atrastu problēmas.
2. darbība: izlaidiet jauno versiju visiem lietotājiem
Mēs nolēmām, ka viss noritēja labi, un tagad mums ir jāizlaiž jaunā versija visiem lietotājiem. Lai to izdarītu, mēs vienkārši atjauninām deploy.yaml instalējot jaunu attēla versiju un reprodukciju skaitu, kas vienāds ar 10. In deploy-canary.yaml mēs iestatām repliku skaitu atpakaļ uz 0. Pēc izvietošanas rezultāts būs šāds:
Summējot
Manuāla izvietošanas palaišana šādā veidā palīdz saprast, cik viegli to var konfigurēt, izmantojot k8s. Tā kā Kubernetes ļauj atjaunināt visu, izmantojot API, šīs darbības var automatizēt, izmantojot skriptus.
Vēl viena lieta, kas jāievieš, ir testētāja ieejas punkts (LoadBalancer vai caur Ingress), caur kuru var piekļūt tikai jaunajai versijai. To var izmantot manuālai pārlūkošanai.
Nākamajos rakstos mēs apskatīsim citus automatizētus risinājumus, kas ievieš lielāko daļu mūsu paveiktā.