Sagatavot Kubernetes klasteri ir vienkārši un ērti? Paziņojam par addon-operatoru

Sekojot . Izmantojot to, var šo izveidot bez Go zināšanām, bet ar administratoriem pierastām metodēm: uz Bash, Python utt. mēs iepazīstinām ar tā vecāko brāli — addon-operator. Tas ir Open Source projekts, kas tiek izmantots sistēmas komponentu instalēšanai Kubernetes klasterī, ko var apzīmēt ar kopīgu terminu — papildinājumi.

Kāpēc vispār nepieciešami kādi papildinājumi?

Nav noslēpums, ka Kubernetes nav gatavs produktu komplekts viss-vienā, un, lai izveidotu “nopietnu” klasteri, būs nepieciešami dažādi papildinājumi. Addon-operator palīdzēs instalēt, konfigurēt un uzturēt šos papildinājumus aktuālā stāvoklī.

Papildu komponentu nepieciešamība klasterī ir izklāstīta prezentācijā kolēģi driusha. Īsumā, situācija ar Kubernetes pašlaik ir tāda, ka vienkāršai instalēšanai “paspēlēties” var iztikt ar izejas komponentiem, izstrādātājiem un testēšanai var pievienot Ingress, bet, lai veiktu pilnvērtīgu uzstādīšanu, par kuru var teikt “jūsu ražošanas vide ir gatava”, nepieciešams pievienot apmēram desmit dažādus papildinājumus: kaut kas monitorēšanai, kaut kas žurnāliem, neaizmirstot par ingress un cert-manager, nodalot mezglu grupas, pievienot tīkla politikas, kārtot ar sysctl iestatījumiem un pod autoscaler’u…

Kādas ir to izmantošanas īpatnības?

Kā rāda pieredze, vienīgi instalācija nav pietiekama. Lai ērti strādātu ar klasteri, papildinājumus būs jāatjaunina, jāizslēdz (jāmērina no klastera) un kaut ko var būt vēlēsities izmēģināt pirms instalācijas ražošanas klasterī.

Tātad, varbūt Ansible būs pietiekami? Varbūt. Bet pilnvērtīgi papildinājumi parasti nevar dzīvot bez iestatījumiem. Šie iestatījumi var atšķirties atkarībā no klastera varianta (aws, gce, azure, bare-metal, do, ...). Dažus iestatījumus nevar noteikt iepriekš — tos ir jāiegūst no klastera. Un klasteris nav statisks: dažu iestatījumu dēļ būs jāseko izmaiņām. Un šajā brīdī Ansible nepietiek: nepieciešama programma, kas dzīvo klasterī, t.i., Kubernetes Operators.

Tie, kas ir mēģinājuši darbā . Izmantojot to, var šo izveidot bez Go zināšanām, bet ar administratoriem pierastām metodēm: uz Bash, Python utt., teiks, ka papildinājumu uzstādīšanas un atjaunināšanas uzdevumus un iestatījumu uzraudzību var diezgan labi atrisināt ar hooku shell-operator. Var uzrakstīt skriptu, kas darīs nosacītu kubectl apply un uzraudzīs, piemēram, ConfigMap, kurā tiks glabāti iestatījumi. Aptuveni tas ir īstenots addon-operator.

Kā tas organizēts addon-operator?

Izstrādājot jaunu risinājumu, mēs izvirzījām šādus principus:

• Papildinājumu uzstādītājam jāatbalsta šablonizācija un deklaratīvā konfigurācija. Mēs neveidojam maģiskas skriptus, kas instalē paplašinājumus. Addon-operator izmanto Helm, lai instalētu paplašinājumus. Lai uzstādītu, ir jāizveido charts un jāpiekārto vērtības, kas tiks izmantotas konfigurēšanai.
• Iestatījumus var ģenerēt uzstādīšanas laikā, tos var iegūt no klastera, vai saņemt atjauninājumus, uzraugot klastera resursus. Šīs darbības var īstenot, izmantojot hookus.
• Iestatījumus var glabāt klasterī. Lai saglabātu iestatījumus klasterī, tiek izveidots ConfigMap/addon-operator, un Addon-operator uzrauga šī ConfigMap izmaiņas. Addon-operator piešķir hookiem piekļuvi iestatījumiem, izmantojot vienkāršas vienošanās.
• Paplašinājums ir atkarīgs no iestatījumiem. Ja iestatījumi mainās, tad Addon-operator ievieš Helm-chart ar jaunām vērtībām. Helm-charta, vērtību tam un hooku apvienošanai mēs saucam par moduli (lasiet plašāk zemāk).
• Posmā. Nav maģisku izlaides skriptu. Atjaunināšanas mehānisms ir līdzīgs parastam lietojumam — apkopot paplašinājumus un addon-operatoru attēlā, piegādāt un izlaist.
• Rezultāta kontrole. Addon-operator spēj sniegt metriku Prometheus.

Kas ir paplašinājums addon-operator?

Paplašinājumu var uzskatīt par visu, kas pievieno klasterim jaunas funkcionalitātes. Piemēram, Ingress uzstādīšana ir lielisks paplašinājuma piemērs. Tas var būt jebkurš operators vai kontrolieris ar savu CRD: prometheus-operator, cert-manager, kube-controller-manager utt. Vai kaut kas mazs, bet atvieglojošs darbību — piemēram, slepeno datu kopētājs, kas kopē reģistra slepenās datu uz jauniem nosaukuma ierāmēm, vai sysctl tuner, kas nosaka sysctl parametrus uz jaunajiem mezgliem.

Paplašinājumu īstenošanai Addon-operator piedāvā vairākas koncepcijas:

• Helm-chart tiek izmantots, lai instalētu klasterī dažādu programmatūru — piemēram, Prometheus, Grafana, nginx-ingress. Ja attiecīgajam komponentam ir Helm-chart, tad tā uzstādīšana, izmantojot Addon-operator, būs ļoti vienkārša.
• Vērtību krātuve. Helm-chartiem parasti ir daudz dažādu iestatījumu, kas var mainīties ar laiku. Addon-operator atbalsta šo iestatījumu glabāšanu un spēj sekot to izmaiņām, lai atjaunotu Helm-chart ar jaunām vērtībām.
• Hooki — ir izpildāmi faili, kurus Addon-operator izpilda notikumu rezultātā un kuriem ir piekļuve vērtību krātuvēm. Hooks var uzraudzīt izmaiņas klasterī un atjaunināt vērtības vērtību krātuvē. T.i., izmantojot hookus, var veikt discovery, lai vāktu vērtības no klastera palaišanas vai pēc grafika, kā arī nepārtrauktu discovery, vācot vērtības no klastera, reaģējot uz izmaiņām klasterī.
• Modulis — ir Helm grafika, vērtību krātuves un hooku apvienojums. Moduļus var ieslēgt un izslēgt. Moduļa izslēgšana nozīmē visu Helm grafika relīžu noņemšanu. Moduļi var automātiski iekļaut sevi, piemēram, ja ir ieslēgti visi nepieciešamie moduļi vai ja discovery hookos ir atrasti vajadzīgie parametri — tas tiek veikts ar palīgskopu enabled skriptu.
• Globālie hooki. Tie ir hooki „paši par sevi”, tie nav iekļauti modulī un tiem ir piekļuve globālajai vērtību krātuvei, kuras vērtības ir pieejamas visiem hookiem modulī.

Kā šīs daļas darbojas kopā? Apskatīsim attēlu no dokumentācijas:

Darba scenāriji ir divi:

1. Globālais hook tiek aktivizēts notikuma rezultātā — piemēram, mainoties resursam klasterī. Šis hook apstrādā izmaiņas un ieraksta jaunas vērtības globālajā vērtību krātuvē. Addon-operator pamanīs, ka globālā krātuve ir mainījusies, un aktivizēs visus moduļus. Katrs modulis, izmantojot savus hookus, nosaka, vai tam ir jāieslēdzas, un atjaunina savu vērtību krātuvi. Ja modulis ir ieslēgts, tad Addon-operator uzsāk Helm grafika uzstādīšanu. Helm grafikā šajā procesā ir pieejamas vērtības no moduļa krātuves un no globālās krātuves.
2. Otrais scenārijs ir vienkāršāks: modulārais hook tiek aktivizēts notikuma rezultātā un maina vērtības modulī esošajā vērtību krātuvē. Addon-operator to pamanīs un uzsāks Helm grafika uzstādīšanu ar atjauninātajām vērtībām.

Papildinājums var tikt īstenots kā viens vienīgs hook vai kā viens Helm grafiks, vai pat kā vairāki atkarīgi moduļi — tas ir atkarīgs no uzstādāmā komponenta sarežģītības klasterī un nepieciešamā pielāgojamo iestatījumu līmeņa. Piemēram, repozitorijā (/examples) ir papildinājums sysctl-tuner, kas īstenots gan kā vienkāršs modulis ar hooku un Helm grafiku, gan, izmantojot vērtību krātuvi, kas ļauj pievienot iestatījumus, rediģējot ConfigMap.

Atjauninājumu piegāde

Daži vārdi par komponentu atjaunināšanas organizāciju, kuras instalē Addon-operator.

Lai palaistu Addon-operator klasterī, ir nepieciešams sagatavot attēlu ar papildinājumiem kā skriptu un Helm chartu failus, pievienot bināro failu addon-operator un visu pārējo, kas nepieciešams skriptiem: bash, kubectl, jq, python utt. Pēc tam šo attēlu var izvietot klasterī kā parastu lietotni un, iespējams, vēlēsities organizēt kādu tagošanas shēmu. Ja klasteru ir maz, var izdoties izmantot to pašu pieeju kā ar lietotnēm: jauns izlaidums, jauna versija, doties cauri visiem klasteriem un labot attēlu Pod’iem. Tomēr, ja ir jāuzsāk liela skaita klasteri, vairāk derēs pašatjaunināšanas koncepcija no kanāla.

Mums tas ir organizēts šādi:

• Kanāls — būtībā tas ir identifikators, ko var definēt kā jebko (piemēram, dev/stage/ea/stable).
• Kanāla nosaukums — tas ir attēla tags. Kad ir jāsagatavo atjauninājumi kanālam, tiek sagatavots jauns attēls un tas tiek marķēts ar kanāla nosaukumu.
• Kad reģistrā parādās jauns attēls, Addon-operator tiek pārstartēts un tiek palaists ar jauno attēlu.

Tas nav labākais praksē, par ko ir rakstīts Kubernetes dokumentācija. Tā darīt nav ieteicams, bet runa ir par parastu lietotni, kas dzīvo vienā klasterī. Pievienojot Addon-operator, lietotne ir daudzas izvietojumi, kas izkliedēti pa klasteriem, un pašatjaunināšana ļoti palīdz un vienkāršo dzīvi.

Kanāli palīdz arī testēšanā: ja ir palīgklasteris, var to iestatīt uz kanālu stage un testēt atjauninājumus tajā pirms to izlaides kādā no kanāliem ea un stable. Ja ar klasteri kanālā ea notika kļūda, to var pārslēgt uz stable, kamēr notiek problēmas izmeklēšana ar šo klasteri. Ja klasteris tiek izslēgts no aktīvās atbalsta, tas tiek pārslēgts uz savu "sasalstošo" kanālu — piemēram, freeze-2019-03-20.

Papildus skriptu un Helm chartu atjauninājumiem var būt nepieciešams atjaunināt arī trešo pušu komponentu. Piemēram, ja esat pamanījis kļūdu nosacītajā node-exporter un pat esat izdomājuši, kā to salabot. Pēc tam atvēra PR un gaidāt jauno izlaidumu, lai varētu apiet visus klasterus un palielināt attēla versiju. Lai negaidītu nenoteiktu laiku, varat sagatavot savu node-exporter un pārslēgties uz to līdz PR pieņemšanai.

Lai gan to var izdarīt arī bez Addon-operator, ar Addon-operator modulis node-exporter instalēšanai būs redzams vienā krātuvē, Dockerfile savam attēlam var turēt tepat, un visiem procesa dalībniekiem kļūst vieglāk saprast, kas notiek... Ja ir vairāki klasteri, pārbaudīt savu PR un uzstādīt jauno versiju kļūst vieglāk!

Šī komponentu atjaunināšanas organizācija pie mums darbojas veiksmīgi, bet var īstenot arī jebkuru citu piemērotu shēmu — jo šajā gadījumā Addon-operator ir vienkāršs binārais fails..

Secinājums

Principi, kas īstenoti Addon-operator, ļauj izveidot caurredzamu procesu papildinājumu izstrādē, testēšanā, uzstādē un atjaunināšanā klasterī, līdzīgu parastās lietojumprogrammu izstrādes procesiem.

Addon-operator papildinājumi modulāru formātā (Helm-chart + hooki) būs pieejami plašam lietotāju lokam. Mēs, uzņēmums Flant, plānojam vasarā publicēt mūsu izstrādājumus šādu papildinājumu veidā. Pievienojieties attīstībai GitHub (. Izmantojot to, var šo izveidot bez Go zināšanām, bet ar administratoriem pierastām metodēm: uz Bash, Python utt., addon-operator), mēģiniet izveidot savu papildinājumu, balstoties uz piemēriem un dokumentācijā, gaidiet ziņas Habrē un mūsu YouTube kanālā!

P.S.

Lasiet arī mūsu emuāra rakstos:

• «Paplašinām un papildinām Kubernetes (pārskats un video prezentācija)»;
• «Iepazīstinām ar shell-operator: veidot operatorus Kubernetes tagad ir vēl vieglāk.».

Avots: habr.com