Eftir við kynnum eldri bróður hans - . Þetta er Open Source verkefni sem er notað til að setja upp kerfishluta í Kubernetes klasa, sem kalla má viðbætur.
Hvers vegna einhverjar viðbætur yfirleitt?
Það er ekkert leyndarmál að Kubernetes er ekki tilbúin allt-í-einn vara, og til að byggja upp „fullorðins“ þyrping þarftu ýmsar viðbætur. Addon-operator mun hjálpa þér að setja upp, stilla og halda þessum viðbótum uppfærðum.
Þörfin fyrir viðbótaríhluti í klasanum er birt í samstarfsmenn . Í stuttu máli er staðan með Kubernetes í augnablikinu þannig að fyrir einfalda „leik“ uppsetningu geturðu komist af með íhlutina úr kassanum, fyrir forritara og prófanir geturðu bætt Ingress við, en fyrir fulla uppsetningu, um það bil þú getur sagt "framleiðslan þín er tilbúin", þú þarft að bæta við með tugi mismunandi viðbóta: eitthvað til að fylgjast með, eitthvað til að skrá þig, ekki gleyma inngöngu og vottunarstjóra, velja hópa af hnútum, bæta við netstefnu, árstíð með sysctl og pod autoscaler stillingum...
Hver er sérstaða þess að vinna með þeim?
Eins og venjan sýnir er málið ekki bundið við eina uppsetningu. Til að vinna á þægilegan hátt með klasanum þarf að uppfæra viðbætur, gera þær óvirkar (fjarlægja úr klasanum) og þú vilt prófa nokkrar áður en þú setur þær upp í framleiðsluklasanum.
Svo, kannski verður Ansible nóg hér? Kannski. En Almennt séð lifa fullgildar viðbætur ekki án stillinga. Þessar stillingar geta verið mismunandi eftir klasaafbrigðinu (aws, gce, azure, bare-metal, do, ...). Ekki er hægt að tilgreina sumar stillingar fyrirfram; þær verða að fást úr þyrpingunni. Og þyrpingin er ekki kyrrstæð: fyrir sumar stillingar verður þú að fylgjast með breytingum. Og hér vantar Ansible nú þegar: þú þarft forrit sem býr í klasa, þ.e. Kubernetes rekstraraðili.
Þeir sem reyndu það í vinnunni , munu þeir segja að hægt sé að leysa verkefnin við að setja upp og uppfæra viðbætur og eftirlitsstillingar með því að nota fyrir skeljarstjóra. Þú getur skrifað handrit sem gerir skilyrt kubectl apply og fylgjast með, til dæmis, ConfigMap, þar sem stillingarnar verða geymdar. Þetta er um það bil það sem er útfært í addon-operator.
Hvernig er þetta skipulagt í addon-operator?
Þegar við bjuggum til nýja lausn fórum við út frá eftirfarandi meginreglum:
- Uppsetningarforritið verður að styðja sniðmát og uppsetningu yfirlýsinga. Við gerum ekki töfraforskriftir sem setja upp viðbætur. Addon-operator notar Helm til að setja upp viðbætur. Til að setja upp þarftu að búa til töflu og velja gildin sem verða notuð fyrir uppsetningu.
- Stillingar geta verið mynda við uppsetningu, þeir geta verið fá úr klasaEða fá uppfærslur, eftirlit með klasaauðlindum. Þessar aðgerðir er hægt að útfæra með því að nota króka.
- Stillingar geta verið geyma í klasa. Til að geyma stillingar í þyrpingunni er ConfigMap/addon-operator búinn til og Addon-operatorinn fylgist með breytingum á þessu ConfigMap. Addon-operator gefur krókum aðgang að stillingum með einföldum venjum.
- Viðbót fer eftir stillingum. Ef stillingarnar hafa breyst, þá rúllar Addon-stjórnandinn út Helm töfluna með nýjum gildum. Við kölluðum samsetningu Helm töflunnar, gildi fyrir það og krókar einingu (sjá nánar hér að neðan).
- Sviðsetning. Það eru engin töfraútgáfuhandrit. Uppfærsluaðferðin er svipuð og venjulegt forrit - safnaðu viðbótum og viðbótarstýrendum í mynd, merktu þær og rúllaðu þeim út.
- Niðurstöðustýring. Addon-operator getur veitt mælikvarða fyrir Prometheus.
Hvað er padding í addon-operator?
Viðbót getur talist allt sem bætir nýjum aðgerðum við klasann. Til dæmis er uppsetning Ingress frábært dæmi um viðbót. Þetta getur verið hvaða rekstraraðili eða stjórnandi sem er með sitt eigið CRD: prometheus-rekstraraðili, cert-manager, kube-controller-manager, osfrv. Eða eitthvað lítið, en auðveldara í notkun - til dæmis, leyndarmál ljósritunarvél, sem afritar leyndarmál skrásetningar í ný nafnrými, eða sysctl útvarpstæki, sem stillir sysctl breytur á nýjum hnútum.
Til að innleiða viðbætur býður Addon-operator upp á nokkur hugtök:
- Hjálmarkort notað til að setja upp ýmsan hugbúnað inn í klasann - til dæmis Prometheus, Grafana, nginx-ingress. Ef nauðsynlegur íhlutur er með Helm töflu, þá er mjög einfalt að setja það upp með Addon-operator.
- Gildi geymsla. Hjálmarkort hafa venjulega margar mismunandi stillingar sem geta breyst með tímanum. Addon-operator styður að geyma þessar stillingar og getur fylgst með breytingum þeirra til að setja upp Helm töfluna aftur með nýjum gildum.
- Krókar eru keyranlegar skrár sem Addon-stjórnandinn keyrir á atburðum og hafa aðgang að gildisgeymslunni. Krókurinn getur fylgst með breytingum á klasanum og uppfært gildin í gildisgeymslunni. Þeir. Með því að nota króka geturðu gert uppgötvun til að safna gildum úr klasanum við ræsingu eða samkvæmt áætlun, eða þú getur gert stöðuga uppgötvun, safnað gildum úr klasanum byggt á breytingum á klasanum.
- Module er sambland af Helm töflu, verðmætaverslun og krókum. Hægt er að virkja eða slökkva á einingar. Að slökkva á einingu þýðir að eyða öllum Helm chart útgáfum. Einingar geta virkjað sjálfar sig á virkan hátt, til dæmis ef allar einingarnar sem þær þurfa eru virkar eða ef uppgötvun hefur fundið nauðsynlegar breytur í krókunum - þetta er gert með því að nota hjálparforrit sem virkt er.
- Global krókar. Þetta eru krókar „einir og sér“, þeir eru ekki innifaldir í einingum og hafa aðgang að alþjóðlegri verðmætaverslun, þar sem gildin eru í boði fyrir alla króka í einingum.
Hvernig vinna þessir hlutar saman? Við skulum skoða myndina úr skjölunum:
Það eru tvær vinnusviðsmyndir:
- Hnattræni krókurinn er ræstur af atburði - til dæmis þegar auðlind í þyrpingunni breytist. Þessi krók vinnur úr breytingunum og skrifar nýju gildin í alþjóðlegu gildisverslunina. Addon-stjórnandi tekur eftir því að alheimsgeymslan hefur breyst og ræsir allar einingar. Hver eining, með því að nota krókana sína, ákvarðar hvort það þurfi að virkja hana og uppfærir gildisgeymslu sína. Ef einingin er virkjuð byrjar Addon-stjórnandinn uppsetningu á Helm töflunni. Í þessu tilviki hefur Helm töfluna aðgang að gildum úr einingageymslunni og frá alheimsgeymslunni.
- Önnur atburðarásin er einfaldari: einingarkrók er ræst af atburði og breytir gildum í gildisgeymslu einingarinnar. Addon-operator tekur eftir þessu og setur hjálmtöfluna með uppfærðum gildum.
Hægt er að útfæra viðbótina sem einn krók, eða sem eitt hjálmtöflu, eða jafnvel sem nokkrar háðar einingar - þetta fer eftir því hversu flókinn íhluturinn er sem verið er að setja upp í þyrpingunni og á æskilegri sveigjanleika í stillingum. Til dæmis, í geymslunni () það er sysctl-tuner viðbót, sem er útfærð bæði sem einföld eining með krók og Helm töflu, og með því að nota gildisgeymsluna, sem gerir það mögulegt að bæta við stillingum með því að breyta ConfigMap.
Afhending uppfærslur
Nokkur orð um að skipuleggja íhlutauppfærslur sem Addon-operator setur upp.
Til að keyra Addon-operator í klasa þarftu búa til mynd með viðbótum í formi króka- og Helm-kortaskráa, bætið við tvíundarskrá addon-operator og allt sem þú þarft fyrir króka: bash, kubectl, jq, python o.s.frv. Síðan er hægt að rúlla þessari mynd út í þyrpinguna sem venjulegt forrit og líklegast viltu skipuleggja eitt eða annað merkingarkerfi. Ef það eru fáir klasar gæti sama nálgun og með forrit hentað: ný útgáfa, ný útgáfa, farðu í alla klasa og leiðréttu myndina af Pods. Hins vegar, ef um er að ræða útfærslu í umtalsverðan fjölda klasa, hentaði hugmyndin um sjálfsuppfærslu frá rás betur fyrir okkur.
Svona gerum við það:
- Rás er í raun auðkenni sem hægt er að stilla á hvað sem er (til dæmis dev/stage/ea/stable).
- Heiti rásarinnar er myndamerkið. Þegar þú þarft að setja upp uppfærslur á rás er ný mynd sett saman og merkt með rásarnafni.
- Þegar ný mynd birtist í skránni er Addon-operator endurræst og ræst með nýju myndinni.
Þetta er ekki besti aðferðin, eins og skrifað er í . Það er ekki mælt með því að gera þetta, en við erum að tala um venjulegt forrit sem býr í sama klasa. Þegar um er að ræða Addon-operator er forrit mikið af dreifingum á víð og dreif um klasa og sjálfsuppfærsla hjálpar mikið og gerir lífið auðveldara.
Rásir hjálpa og í prófun: ef það er aukaþyrping geturðu stillt hann á rásina stage og rúlla uppfærslum inn í það áður en það er rúllað út á rásir ea и stable. Ef með klasa á rásinni ea villa kom upp, þú getur skipt yfir í stable, á meðan verið er að rannsaka vandamálið með þennan klasa. Ef klasinn er tekinn úr virkum stuðningi skiptir hann yfir í „frosna“ rás sína - td. freeze-2019-03-20.
Auk þess að uppfæra króka og Helm töflur gætirðu þurft uppfærslu og þriðja aðila hluti. Til dæmis, þú tókst eftir villu í skilyrta hnútaútflytjandanum og komst jafnvel að því hvernig ætti að laga hana. Næst opnaðir þú PR og bíður eftir að nýja útgáfan fari í gegnum alla klasana og auki útgáfu myndarinnar. Til þess að bíða ekki endalaust geturðu byggt upp hnútaútflytjanda og skipt yfir í hann áður en þú samþykkir PR.
Almennt er hægt að gera þetta án Addon-operator, en með Addon-operator verður einingin til að setja upp node-exporter sýnileg í einni geymslu, Dockerfile til að byggja upp myndina þína er hægt að geyma þar, það verður auðveldara fyrir alla þátttakendur í ferlið til að skilja hvað gerist... Og ef það eru nokkrir klasar, þá verður auðveldara að bæði prófa PR og setja út nýja útgáfu!
Þetta skipulag á uppfærslu íhluta virkar vel fyrir okkur, en hægt er að innleiða hvaða annað viðeigandi kerfi sem er - þegar allt kemur til alls í þessu tilfelli er Addon-operator einföld tvíundarskrá.
Ályktun
Meginreglurnar sem innleiddar eru í Addon-operator gera þér kleift að byggja upp gagnsætt ferli til að búa til, prófa, setja upp og uppfæra viðbætur í klasa, svipað og þróunarferli venjulegra forrita.
Hægt er að gera viðbætur fyrir Addon-operator á einingasniði (Hjálmartafla + krókar) aðgengilegar almenningi. Við, Flant fyrirtækið, ætlum að birta þróun okkar í formi slíkra viðbóta í sumar. Vertu með í þróun á GitHub (, ), reyndu að búa til þína eigin viðbót út frá и , bíddu eftir fréttum um Habré og á okkar !
PS
Lestu líka á blogginu okkar:
- «»;
- «'.
Heimild: www.habr.com