Kjarni sögunnar um vinsælasta pakkastjórann fyrir Kubernetes gæti verið lýst með því að nota emoji:
- kassinn er Helm (sem er næst nýjustu Emoji útgáfunni);
- læsa - öryggi;
- litli maðurinn er lausn vandans.
Reyndar verður allt aðeins flóknara og sagan er full af tæknilegum smáatriðum um Hvernig á að gera Helm öruggan.
- Stuttlega hvað Helm er ef þú vissir það ekki eða gleymdir. Hvaða vandamál leysir það og hvar er það staðsett í vistkerfinu.
- Við skulum skoða Helm arkitektúrinn. Ekkert samtal um öryggi og hvernig á að gera tól eða lausn öruggari getur verið fullkomið án þess að skilja arkitektúr íhlutsins.
- Við skulum ræða Helm hluti.
- Mest brennandi spurningin er framtíðin - nýja útgáfan af Helm 3.
Allt í þessari grein á við um Helm 2. Þessi útgáfa er nú í framleiðslu og er líklega sú sem þú ert að nota núna og það er útgáfan sem inniheldur öryggisáhættuna.
Um ræðumanninn: Alexander Khayorov () hefur verið að þróa í 10 ár og hjálpað til við að bæta efni og kom inn í nefndina . Nú starfar hann hjá Chainstack sem þróunarleiðtogi - þetta er blendingur á milli þróunarstjóra og einstaklings sem ber ábyrgð á að skila lokaútgáfum. Það er, það er staðsett á vígvellinum, þar sem allt gerist frá sköpun vöru til notkunar hennar.
Chainstack er lítið, virkt vaxandi sprotafyrirtæki sem hefur það hlutverk að gera viðskiptavinum kleift að gleyma innviðum og flóknum rekstri dreifðra forrita; þróunarteymið er staðsett í Singapúr. Ekki biðja Chainstack um að selja eða kaupa dulritunargjaldmiðil, en býðst til að tala um blockchain ramma fyrirtækja og þeir munu svara þér með ánægju.
Helm
Þetta er pakka (kortastjóri) fyrir Kubernetes. Leiðandi og alhliða leiðin til að koma forritum í Kubernetes klasa.
Við erum að sjálfsögðu að tala um uppbyggingu og iðnaðar nálgun en að búa til þínar eigin YAML upplýsingaskrár og skrifa lítil tól.
Helm er það besta sem er í boði núna og vinsælt.
Af hverju Helm? Fyrst og fremst vegna þess að það er stutt af CNCF. Cloud Native er stór stofnun og er móðurfyrirtæki fyrir verkefni Kubernetes, etcd, Fluentd og fleiri.
Önnur mikilvæg staðreynd er að Helm er mjög vinsælt verkefni. Þegar ég byrjaði að tala um hvernig á að gera Helm öruggan í janúar 2019 var verkefnið með þúsund stjörnur á GitHub. Í maí voru þeir orðnir 12 þúsund.
Margir hafa áhuga á Helm, þannig að jafnvel þótt þú notir það ekki ennþá muntu njóta góðs af því að vita um öryggi þess. Öryggi er mikilvægt.
Kjarna Helm teymið er stutt af Microsoft Azure og er því nokkuð stöðugt verkefni, ólíkt mörgum öðrum. Útgáfa Helm 3 Alpha 2 um miðjan júlí gefur til kynna að það sé ansi mikið af fólki að vinna að verkefninu og þeir hafa löngun og orku til að þróa og bæta Helm.
Helm leysir nokkur rótvandamál við stjórnun forrita í Kubernetes.
- Umbúðir umsóknar. Jafnvel forrit eins og „Halló, heimur“ á WordPress samanstendur nú þegar af nokkrum þjónustum og þú vilt pakka þeim saman.
- Stjórna flókninni sem fylgir stjórnun þessara forrita.
- Lífsferill sem endar ekki eftir að forritið er sett upp eða sett í notkun. Það heldur áfram að lifa, það þarf að uppfæra það og Helm hjálpar til við þetta og reynir að koma með réttar ráðstafanir og stefnur fyrir þetta.
Pokað það er skipulagt á skýran hátt: það eru lýsigögn í fullu samræmi við vinnu venjulegs pakkastjóra fyrir Linux, Windows eða MacOS. Það er, geymsla, ósjálfstæði á ýmsum pökkum, metaupplýsingar fyrir forrit, stillingar, stillingareiginleikar, upplýsingaskráning osfrv. Helm gerir þér kleift að fá og nota allt þetta fyrir forrit.
Flækjustig. Ef þú ert með mörg forrit af sömu gerð, þá er þörf á breytustillingu. Sniðmát koma frá þessu, en til að forðast að þurfa að finna upp þína eigin leið til að búa til sniðmát geturðu notað það sem Helm býður upp á beint úr kassanum.
Umsókn lífsferilsstjórnun - að mínu mati er þetta áhugaverðasta og óútkljáða spurningin. Þess vegna kom ég til Helm á sínum tíma. Við þurftum að hafa auga með líftíma forritsins og vildum færa CI/CD og umsóknarlotur yfir á þessa hugmyndafræði.
Helm gerir þér kleift að:
- stjórna dreifingum, kynnir hugmyndina um uppsetningu og endurskoðun;
- framkvæma afturköllun með góðum árangri;
- nota króka fyrir mismunandi viðburði;
- bæta við fleiri umsóknarathugunum og svara niðurstöðum þeirra.
Ennfremur Hjálmur er með „rafhlöður“ - gríðarlegur fjöldi af bragðgóðum hlutum sem hægt er að fylgja með í formi viðbóta, sem einfaldar líf þitt. Hægt er að skrifa viðbætur sjálfstætt, þau eru nokkuð einangruð og þurfa ekki samræmdan arkitektúr. Ef þú vilt innleiða eitthvað, þá mæli ég með því að gera það sem viðbót, og hugsanlega setja það inn í andstreymis.
Helm er byggt á þremur meginhugtökum:
- Myndaskrá — lýsing og úrval af breytum mögulegum fyrir upplýsingaskrána þína.
- Config — það er gildin sem verða notuð (texti, tölugildi osfrv.).
- Slepptu safnar tveimur efri hlutunum og saman breytast þeir í Losun. Hægt er að útgáfa útgáfur og ná þannig skipulögðum lífsferli: lítill við uppsetningu og stór við uppfærslu, niðurfærslu eða afturköllun.
Hjálmar arkitektúr
Skýringarmyndin sýnir huglægan arkitektúr Helm á háu stigi.
Leyfðu mér að minna þig á að Helm er eitthvað tengt Kubernetes. Þess vegna getum við ekki verið án Kubernetes þyrpingar (rétthyrningur). Kube-apiserver hluti er staðsettur á masternum. Án Helm höfum við Kubeconfig. Helm kemur með eitt lítið tvöfaldur, ef þú getur kallað það það, Helm CLI gagnsemi, sem er sett upp á tölvu, fartölvu, mainframe - á hvað sem er.
En þetta er ekki nóg. Helm er með netþjónshluta sem heitir Tiller. Það stendur fyrir hagsmuni Helm innan klasans; það er forrit innan Kubernetes klasans, eins og hver önnur.
Næsti hluti af Chart Repo er geymsla með töflum. Það er opinber geymsla og það getur verið einkageymsla fyrirtækis eða verkefnis.
Samskipti
Við skulum skoða hvernig arkitektúrhlutirnir hafa samskipti þegar við viljum setja upp forrit með Helm.
- Við erum að tala saman
Helm install, fáðu aðgang að geymslunni (Chart Repo) og fáðu hjálmtöflu.
- Helm tólið (Helm CLI) hefur samskipti við Kubeconfig til að finna út hvaða þyrping á að hafa samband við.
- Eftir að hafa fengið þessar upplýsingar vísar tólið til Tiller, sem er staðsett í klasanum okkar, sem umsókn.
- Tiller kallar á Kube-apiserver til að framkvæma aðgerðir í Kubernetes, búa til nokkra hluti (þjónustur, belg, eftirlíkingar, leyndarmál osfrv.).
Næst munum við flækja skýringarmyndina til að sjá árásarvektorinn sem allur Helm arkitektúrinn í heild getur orðið fyrir. Og þá reynum við að vernda hana.
Árásarvektor
Fyrsti hugsanlegi veiki punkturinn er forréttinda API-notandi. Sem hluti af kerfinu er þetta tölvuþrjótur sem hefur fengið stjórnandaaðgang að Helm CLI.
Forréttindalaus API notandi getur líka skapað hættu ef það er einhvers staðar nálægt. Slíkur notandi mun hafa annað samhengi, til dæmis er hægt að laga hann í einu nafnarými þyrpingarinnar í Kubeconfig stillingunum.
Áhugaverðasti árásarvektorinn gæti verið ferli sem er innan klasa einhvers staðar nálægt Tiller og getur fengið aðgang að honum. Þetta getur verið vefþjónn eða örþjónusta sem sér netumhverfi klasans.
Framandi, en sífellt vinsælli, árásarafbrigði felur í sér Chart Repo. Kort sem búið er til af óprúttnum höfundi getur innihaldið óöruggar heimildir og þú munt klára það með því að taka það í trú. Eða það getur komið í stað töflunnar sem þú halar niður af opinberu geymslunni og til dæmis búið til auðlind í formi stefnu og aukið aðgang þess.
Við skulum reyna að bægja árásum frá öllum þessum fjórum hliðum og komast að því hvar vandamál eru í Helm-arkitektúrnum og hvar, ef til vill, eru engin.
Við skulum stækka skýringarmyndina, bæta við fleiri þáttum, en halda öllum grunnþáttum.
Helm CLI hefur samskipti við Chart Repo, hefur samskipti við Kubeconfig og verkið er flutt yfir í þyrpinguna yfir í Tiller íhlutinn.
Tiller er táknað með tveimur hlutum:
- Tiller-deploy svc, sem afhjúpar ákveðna þjónustu;
- Tiler-deploy pod (á skýringarmyndinni í einu eintaki í einni eftirmynd), sem allt álagið keyrir á, sem kemst í þyrpinguna.
Mismunandi samskiptareglur og kerfi eru notuð fyrir samskipti. Frá öryggissjónarmiði höfum við mestan áhuga á:
- Vélbúnaðurinn sem Helm CLI hefur aðgang að kortaskránni: hvaða samskiptareglur, er auðkenning og hvað er hægt að gera við það.
- Samskiptareglur sem Helm CLI, með kubectl, hefur samskipti við Tiller. Þetta er RPC þjónn sem er settur upp inni í þyrpingunni.
- Tiller sjálft er aðgengilegt fyrir örþjónustur sem eru í þyrpingunni og hafa samskipti við Kube-apiserver.
Við skulum ræða öll þessi svæði í röð.
RBAC
Það þýðir ekkert að tala um öryggi fyrir Helm eða aðra þjónustu innan klasans nema RBAC sé virkt.
Svo virðist sem þetta séu ekki nýjustu tilmælin, en ég er viss um að margir hafa enn ekki virkjað RBAC jafnvel í framleiðslu, því það er mikið vesen og margt sem þarf að stilla. Hins vegar hvet ég þig til að gera þetta.
— vefsíða lögfræðingur RBAC. Það inniheldur mikið magn af áhugaverðu efni sem mun hjálpa þér að setja upp RBAC, sýna hvers vegna það er gott og hvernig á að lifa með því í framleiðslu.
Ég ætla að reyna að útskýra hvernig Tiller og RBAC virka. Tiller vinnur inni í klasanum undir ákveðnum þjónustureikningi. Venjulega, ef RBAC er ekki stillt, mun þetta vera ofurnotandinn. Í grunnstillingunni verður Tiller stjórnandi. Þess vegna er oft sagt að Tiller séu SSH göng að þyrpingunni þinni. Reyndar er þetta satt, þannig að þú getur notað sérstakan þjónustureikning í stað sjálfgefinn þjónustureiknings á skýringarmyndinni hér að ofan.
Þegar þú frumstillir Helm og setur hann upp á netþjóninum í fyrsta skipti geturðu stillt þjónustureikninginn með því að nota --service-account. Þetta gerir þér kleift að nota notanda með lágmarks réttindi. Að vísu verður þú að búa til slíkan „krans“: Hlutverk og hlutverkabinding.
Því miður mun Helm ekki gera þetta fyrir þig. Þú eða Kubernetes klasastjórnandinn þinn þarft að undirbúa sett af hlutverkum og hlutverkabindingum fyrir þjónustureikninginn fyrirfram til að standast Helm.
Spurningin vaknar - hver er munurinn á hlutverki og ClusterRole? Munurinn er sá að ClusterRole virkar fyrir öll nafnrými, ólíkt venjulegum hlutverkum og hlutverkabindingum, sem virka aðeins fyrir sérhæft nafnrými. Þú getur stillt stefnur fyrir allan klasann og öll nafnarými, eða sérsniðnar fyrir hvert nafnrými fyrir sig.
Þess má geta að RBAC leysir annað stórt vandamál. Margir kvarta yfir því að Helm sé því miður ekki fjöleignarhús (styður ekki fjölbýli). Ef nokkur teymi neyta klasa og nota Helm er í rauninni ómögulegt að setja upp stefnur og takmarka aðgang þeirra innan þessa klasa, vegna þess að það er ákveðinn þjónustureikningur sem Helm rekur undir og hann býr til öll tilföng í klasanum undir honum. , sem stundum mjög óþægilegt. Þetta er satt - eins og tvíundarskráin sjálf, eins og ferlið, Helm Tiller hefur ekki hugmynd um fjölbýli.
Hins vegar er frábær leið sem gerir þér kleift að keyra Tiller mörgum sinnum í klasa. Það er ekkert vandamál með þetta, Tiller er hægt að ræsa í hverju nafnarými. Þannig geturðu notað RBAC, Kubeconfig sem samhengi og takmarkað aðgang að sérstökum hjálm.
Þetta mun líta svona út.
Til dæmis eru tvær Kubeconfigs með samhengi fyrir mismunandi teymi (tvö nafnrými): X Team fyrir þróunarteymið og admin þyrpinguna. Stjórnandaþyrpingin hefur sinn eigin breiðan Tiller, sem er staðsettur í Kube-kerfi nafnarýminu, samsvarandi háþróuðum þjónustureikningi. Og sérstakt nafnrými fyrir þróunarteymið, þeir munu geta sent þjónustu sína á sérstakt nafnrými.
Þetta er framkvæmanleg nálgun, Tiller er ekki svo orkusvangur að það muni hafa mikil áhrif á fjárhagsáætlun þína. Þetta er ein af fljótu lausnunum.
Ekki hika við að stilla Tiller sérstaklega og veita Kubeconfig samhengi fyrir teymið, fyrir ákveðinn þróunaraðila eða fyrir umhverfið: Dev, Staging, Production (það er vafasamt að allt verði á sama þyrpingunni, þó er hægt að gera þetta).
Áfram sögu okkar, við skulum skipta úr RBAC og tala um ConfigMaps.
ConfigMaps
Helm notar ConfigMaps sem gagnageymslu. Þegar við ræddum um arkitektúr var enginn gagnagrunnur til sem geymdi upplýsingar um útgáfur, stillingar, afturköllun o.s.frv. ConfigMaps er notað fyrir þetta.
Helsta vandamálið með ConfigMaps er þekkt - þau eru óörugg í grundvallaratriðum; það er ómögulegt að geyma viðkvæm gögn. Við erum að tala um allt sem á ekki að fara út fyrir þjónustuna, til dæmis lykilorð. Innfæddasta leiðin fyrir Helm núna er að skipta úr notkun ConfigMaps yfir í leyndarmál.
Þetta er gert mjög einfaldlega. Hnekktu Tiller stillingunni og tilgreindu að geymslan verði leyndarmál. Síðan færðu ekki ConfigMap fyrir hverja uppsetningu, heldur leyndarmál.
Þú gætir haldið því fram að leyndarmál sjálft séu undarlegt hugtak og ekki mjög öruggt. Hins vegar er þess virði að skilja að Kubernetes verktaki sjálfir eru að gera þetta. Frá og með útgáfu 1.10, þ.e. Í nokkuð langan tíma hefur verið hægt, að minnsta kosti í opinberum skýjum, að tengja rétta geymslu til að geyma leyndarmál. Teymið vinnur nú að leiðum til að dreifa betri aðgangi að leyndarmálum, einstökum belgjum eða öðrum aðilum.
Það er betra að flytja Storage Helm yfir á leyndarmál og þau eru aftur á móti tryggð miðlægt.
Auðvitað verður það áfram gagnageymsluhámark 1 MB. Helm notar hér etcd sem dreifða geymslu fyrir ConfigMaps. Og þar töldu þeir að þetta væri hentugur gagnaklumpur til afritunar o.s.frv. Það er áhugaverð umræða um þetta á Reddit, ég mæli með að finna þessa skemmtilegu lesningu fyrir helgina eða lesa útdráttinn .
Myndaskrá
Töflur eru félagslega viðkvæmustu og geta orðið uppspretta „Mann í miðjunni“, sérstaklega ef þú notar stofnlausn. Fyrst af öllu erum við að tala um geymslur sem eru afhjúpaðar í gegnum HTTP.
Þú þarft örugglega að afhjúpa Helm Repo yfir HTTPS - þetta er besti kosturinn og er ódýr.
Athugið að töflu undirskrift vélbúnaður. Tæknin er einföld eins og helvíti. Þetta er það sama og þú notar á GitHub, venjulegri PGP vél með almennum og einkalyklum. Settu upp og vertu viss um að hafa nauðsynlega lykla og undirrita allt, að þetta sé í raun grafið þitt.
Að auki, Helm viðskiptavinur styður TLS (ekki í HTTP skilningi miðlara, heldur gagnkvæmum TLS). Þú getur notað miðlara og biðlara lykla til að eiga samskipti. Til að vera heiðarlegur, ég nota ekki slíkt kerfi vegna þess að mér líkar ekki gagnkvæm vottorð. Í grundvallaratriðum, - aðal tólið til að setja upp Helm Repo fyrir Helm 2 - styður einnig grunnauth. Þú getur notað grunnauth ef það er þægilegra og hljóðlátara.
Það er líka viðbót , sem gerir þér kleift að hýsa Chart Repos á Google Cloud Storage. Þetta er mjög þægilegt, virkar frábærlega og er alveg öruggt, vegna þess að öll aðferðin sem lýst er eru endurunnin.
Ef þú virkjar HTTPS eða TLS, notar mTLS og virkjar grunnauðkenningu til að draga enn frekar úr áhættu, færðu örugga samskiptarás með Helm CLI og Chart Repo.
gRPC API
Næsta skref er mjög mikilvægt - að tryggja Tiller, sem er staðsettur í þyrpingunni og er annars vegar þjónn, hins vegar kemst hann sjálfur í aðra hluti og reynir að þykjast vera einhver.
Eins og ég sagði þegar, Tiller er þjónusta sem afhjúpar gRPC, Helm viðskiptavinurinn kemur að henni í gegnum gRPC. Sjálfgefið er að sjálfsögðu TLS óvirkt. Hvers vegna þetta var gert er umdeilanleg spurning, mér sýnist það einfalda uppsetninguna í upphafi.
Fyrir framleiðslu og jafnvel sviðsetningu mæli ég með því að virkja TLS á gRPC.
Að mínu mati, ólíkt mTLS fyrir töflur, er þetta viðeigandi hér og er gert mjög einfaldlega - búa til PQI innviði, búa til vottorð, ræsa Tiller, flytja vottorðið meðan á frumstillingu stendur. Eftir þetta geturðu framkvæmt allar Helm skipanir, framvísað skilríkinu og einkalyklinum sem búið er til.
Þannig munt þú vernda þig fyrir öllum beiðnum til Tiller utan þyrpingarinnar.
Þannig að við höfum tryggt tengingarrásina við Tiller, við höfum þegar rætt RBAC og aðlagað réttindi Kubernetes apiserversins, minnkað lénið sem það getur haft samskipti við.
Verndaður Helm
Við skulum líta á lokamyndina. Þetta er sami arkitektúrinn með sömu örvunum.
Nú er hægt að teikna allar tengingar á öruggan hátt með grænu:
- fyrir Chart Repo notum við TLS eða mTLS og grunnauth;
- mTLS fyrir Tiller, og það er afhjúpað sem gRPC þjónusta með TLS, við notum vottorð;
- klasinn notar sérstakan þjónustureikning með hlutverki og hlutverkabindingu.
Við höfum tryggt þyrpinguna verulega, en einhver klár sagði:
„Það getur aðeins verið ein algerlega örugg lausn - slökkt tölva, sem er staðsett í steyptum kassa og er gætt af hermönnum.
Það eru mismunandi leiðir til að vinna með gögn og finna nýja árásarvektora. Hins vegar er ég þess fullviss að þessar ráðleggingar nái grunnstaðli iðnaðarins fyrir öryggi.
Bónus
Þessi hluti er ekki beintengdur öryggi, en mun einnig vera gagnlegur. Ég skal sýna þér áhugaverða hluti sem fáir vita um. Til dæmis, hvernig á að leita að töflum - opinberum og óopinberum.
Í geymslunni Nú eru um 300 töflur og tveir straumar: hesthús og útungunarvél. Allir sem leggja sitt af mörkum vita mætavel hversu erfitt er að komast úr hitakassa í hesthús og hversu auðvelt það er að fljúga úr hesthúsi. Hins vegar er þetta ekki besta tólið til að leita að töflum fyrir Prometheus og hvaðeina sem þú vilt, af einni einfaldri ástæðu - það er ekki gátt þar sem þú getur auðveldlega leitað að pakka.
En það er þjónusta , sem gerir það mun þægilegra að finna töflur. Mikilvægast er að það eru miklu fleiri ytri geymslur og næstum 800 heillar í boði. Auk þess geturðu tengt geymsluna þína ef þú vilt af einhverjum ástæðum ekki senda töflurnar þínar í stöðugleika.
Prófaðu hub.helm.sh og við skulum þróa það saman. Þessi þjónusta er undir Helm verkefninu og þú getur jafnvel lagt þitt af mörkum til notendaviðmótsins ef þú ert framhlið verktaki og vilt bara bæta útlitið.
Ég vil líka vekja athygli á hv Opna Service Broker API samþættingu. Það hljómar fyrirferðarmikið og óljóst, en það leysir vandamál sem allir standa frammi fyrir. Leyfðu mér að útskýra með einföldu dæmi.
Það er Kubernetes þyrping þar sem við viljum keyra klassískt forrit - WordPress. Almennt þarf gagnagrunn fyrir fulla virkni. Það eru margar mismunandi lausnir, til dæmis geturðu hleypt af stokkunum eigin fullkomnu þjónustu. Þetta er ekki mjög þægilegt, en margir gera það.
Aðrir, eins og við hjá Chainstack, nota stýrða gagnagrunna eins og MySQL eða PostgreSQL fyrir netþjóna sína. Þess vegna eru gagnagrunnar okkar staðsettir einhvers staðar í skýinu.
En vandamál koma upp: við þurfum að tengja þjónustu okkar við gagnagrunn, búa til gagnagrunnsbragð, flytja skilríkin og stjórna því einhvern veginn. Allt þetta er venjulega gert handvirkt af kerfisstjóra eða þróunaraðila. Og það er ekkert vandamál þegar það eru fáar umsóknir. Þegar það er mikið af þeim þarftu að sameina. Það er svo uppskerutæki - það er þjónustumiðlari. Það gerir þér kleift að nota sérstaka viðbót fyrir opinberan skýjaklasa og panta auðlindir frá þjónustuveitunni í gegnum Broker, eins og það væri API. Til að gera þetta geturðu notað innfædd Kubernetes verkfæri.
Það er mjög einfalt. Þú getur spurt, til dæmis, Managed MySQL í Azure með grunnstigi (þetta er hægt að stilla). Með því að nota Azure API verður gagnagrunnurinn búinn til og undirbúinn til notkunar. Þú þarft ekki að trufla þetta, viðbótin er ábyrg fyrir þessu. Til dæmis mun OSBA (Azure tappi) skila skilríkjum til þjónustunnar og senda það til Helm. Þú munt geta notað WordPress með MySQL skýinu, alls ekki tekist á við stýrða gagnagrunna og ekki hafa áhyggjur af fullkominni þjónustu inni.
Við getum sagt að Helm virki sem lím sem annars vegar gerir þér kleift að dreifa þjónustu og hins vegar neyta auðlinda skýjaveitna.
Þú getur skrifað þitt eigið viðbót og notað alla þessa sögu á staðnum. Þá muntu einfaldlega hafa þitt eigið viðbót fyrir fyrirtækjaskýjaveituna. Ég mæli með að prófa þessa nálgun, sérstaklega ef þú ert með stóran mælikvarða og vilt fljótt innleiða dev, sviðsetningu eða allan innviði fyrir eiginleika. Þetta mun gera lífið auðveldara fyrir aðgerðir þínar eða DevOps.
Önnur uppgötvun sem ég hef þegar nefnt er helm-gcs viðbót, sem gerir þér kleift að nota Google-buckets (hlutgeymsla) til að geyma Helm töflur.
Þú þarft aðeins fjórar skipanir til að byrja að nota það:
- settu upp viðbótina;
- hefja það;
- stilltu slóðina að fötunni, sem er staðsett í gcp;
- birta töflur á hefðbundinn hátt.
Fegurðin er sú að innfædda gcp aðferðin verður notuð fyrir heimild. Þú getur notað þjónustureikning, þróunarreikning, hvað sem þú vilt. Það er mjög þægilegt og kostar ekkert í rekstri. Ef þú, eins og ég, stuðlar að opslausu hugmyndafræðinni, þá mun þetta vera mjög þægilegt, sérstaklega fyrir lítil teymi.
Valkostir
Helm er ekki eina þjónustustjórnunarlausnin. Það eru margar spurningar um það, sem er líklega ástæðan fyrir því að þriðja útgáfan birtist svo fljótt. Auðvitað eru til valkostir.
Þetta geta verið sérhæfðar lausnir, til dæmis Ksonnet eða Metaparticle. Þú getur notað klassísku innviðastjórnunartækin þín (Ansible, Terraform, Chef, osfrv.) í sömu tilgangi og ég talaði um.
Loksins er lausn , þar sem vinsældir þeirra fara vaxandi.
Operator Framework er besti Helm valkosturinn til að íhuga.
Það er meira innfæddur maður til CNCF og Kubernetes, en aðgangshindrunin er miklu hærri, þú þarft að forrita meira og lýsa birtingum minna.
Það eru ýmsar viðbætur, svo sem Draft, Scaffold. Þeir gera lífið miklu auðveldara, til dæmis einfalda þeir hringrásina við að senda og ræsa Helm fyrir forritara til að dreifa prófunarumhverfi. Ég myndi kalla þá valdhafa.
Hér er sjónræn töflu yfir hvar allt er.
Á x-ásnum er stig persónulegrar stjórnunar þinnar á því sem er að gerast, á y-ásnum er innfæddastig Kubernetes. Helm útgáfa 2 fellur einhvers staðar í miðjunni. Í útgáfu 3, ekki gríðarlega, en bæði stjórn og innfæddur stigi hefur verið bætt. Lausnir á Ksonnet stigi eru enn lakari jafnvel en Helm 2. Hins vegar eru þær þess virði að skoða til að vita hvað annað er í þessum heimi. Auðvitað mun stillingarstjórinn þinn vera undir þinni stjórn, en hann er alls ekki innfæddur í Kubernetes.
Rekstrarramminn er algerlega innfæddur í Kubernetes og gerir þér kleift að stjórna honum mun glæsilegri og vandvirkari (en mundu um inngangsstigið). Frekar, þetta er hentugur fyrir sérhæfða notkun og stofnun stjórnunar fyrir það, frekar en fjöldauppskeru til að pakka gríðarlegum fjölda forrita með Helm.
Framlengingar bæta einfaldlega stjórnina aðeins, bæta við verkflæði eða skera horn á CI/CD leiðslum.
Framtíð Helms
Góðu fréttirnar eru þær að Helm 3 er að koma. Alfa útgáfan af Helm 3.0.0-alpha.2 hefur þegar verið gefin út, þú getur prófað hana. Það er nokkuð stöðugt, en virkni er enn takmörkuð.
Af hverju þarftu Helm 3? Í fyrsta lagi er þetta saga um hvarf Tiller, sem þáttur. Þetta, eins og þú skilur nú þegar, er mikið skref fram á við, því frá sjónarhóli öryggis arkitektúrsins er allt einfaldað.
Þegar Helm 2 var búið til, sem var í kringum Kubernetes 1.8 eða jafnvel fyrr, voru mörg hugtökin óþroskuð. Til dæmis er nú verið að innleiða CRD hugmyndina á virkan hátt og Helm mun gera það nota CRDað geyma mannvirki. Það verður aðeins hægt að nota biðlarann en ekki viðhalda miðlarahlutanum. Í samræmi við það, notaðu innfæddar Kubernetes skipanir til að vinna með mannvirki og tilföng. Þetta er stórt skref fram á við.
Mun birtast stuðningur við innfæddar OCI geymslur (Opið Container Initiative). Þetta er risastórt framtak og Helm hefur fyrst og fremst áhuga á því að birta töflurnar sínar. Það kemur að því að til dæmis Docker Hub styður marga OCI staðla. Ég giska ekki á það, en kannski munu klassískir Docker geymsluveitur byrja að gefa þér tækifæri til að hýsa Helm töflurnar þínar.
Umdeild sagan fyrir mér er Lua stuðningur, sem sniðmátsvél til að skrifa handrit. Ég er ekki mikill aðdáandi Lua, en þetta væri algjörlega valfrjáls eiginleiki. Ég athugaði þetta 3 sinnum - það er ekki nauðsynlegt að nota Lua. Þess vegna, þeir sem vilja geta notað Lua, þeir sem líkar við Go, skrá sig í risastóru búðirnar okkar og nota go-tmpl fyrir þetta.
Að lokum, það sem ég var örugglega að sakna var tilkoma skema og sannprófun gagnategunda. Það verða engin vandamál lengur með int eða streng, engin þörf á að vefja núll inn í tvöfaldar gæsalappir. JSONS skema mun birtast sem gerir þér kleift að lýsa þessu sérstaklega fyrir gildi.
Verður mikið endurunnið atburðadrifið líkan. Því hefur þegar verið lýst hugmyndalega. Horfðu á Helm 3 útibúið og þú munt sjá hversu mörgum atburðum og krókum og öðru hefur verið bætt við, sem mun einfalda til muna og á hinn bóginn bæta stjórn á dreifingarferlunum og viðbrögðum við þeim.
Helm 3 verður einfaldari, öruggari og skemmtilegri, ekki vegna þess að okkur líkar ekki við Helm 2, heldur vegna þess að Kubernetes er að verða fullkomnari. Í samræmi við það getur Helm notað þróun Kubernetes og búið til framúrskarandi stjórnendur fyrir Kubernetes á henni.
Aðrar góðar fréttir eru þær Alexander Khayorov mun segja þér, Minnum á að ráðstefnan um samþættingu þróunar-, prófunar- og rekstrarferla verður haldin í Moskvu 30. september og 1. október. Þú getur enn gert það til 20. ágúst og segðu okkur frá reynslu þinni af lausninni verkefni DevOps nálgunarinnar.
Fylgstu með ráðstefnustöðvum og fréttum kl и .
Heimild: www.habr.com