Bistvo zgodbe o najbolj priljubljenem upravljalniku paketov za Kubernetes bi lahko upodobili z emojijem:
- škatla je Helm (kar je najbližje zadnji izdaji Emoji);
- ključavnica - varnost;
- mali človek je rešitev problema.
Pravzaprav bo vse malo bolj zapleteno, zgodba pa je polna tehničnih podrobnosti o Kako narediti Helm varen.
- Na kratko, kaj je Helm, če niste vedeli ali ste pozabili. Katere težave rešuje in kje v ekosistemu se nahaja.
- Poglejmo si arhitekturo Helma. Noben pogovor o varnosti in o tem, kako narediti orodje ali rešitev bolj varno, ni popoln brez razumevanja arhitekture komponente.
- Pogovorimo se o komponentah Helm.
- Najbolj pereče vprašanje je prihodnost - nova različica Helm 3.
Vse v tem članku velja za Helm 2. Ta različica je trenutno v izdelavi in je najverjetneje tista, ki jo trenutno uporabljate, in je različica, ki vsebuje varnostna tveganja.
O govorniku: Aleksander Khayorov () se razvija že 10 let in pomaga izboljšati vsebino in se pridružil odboru . Zdaj dela pri Chainstacku kot vodja razvoja - to je hibrid med vodjo razvoja in osebo, ki je odgovorna za dostavo končnih objav. To pomeni, da se nahaja na bojišču, kjer se dogaja vse od nastanka izdelka do njegovega delovanja.
Chainstack je majhno, aktivno rastoče zagonsko podjetje, katerega naloga je strankam omogočiti, da pozabijo na infrastrukturo in kompleksnost delovanja decentraliziranih aplikacij; razvojna ekipa se nahaja v Singapurju. Ne zahtevajte od Chainstacka, da proda ali kupi kriptovaluto, ampak ponudite pogovor o podjetniških ogrodjih blockchain in z veseljem vam bodo odgovorili.
Helm
To je upravitelj paketov (grafov) za Kubernetes. Najbolj intuitiven in univerzalen način za prenos aplikacij v gručo Kubernetes.
Seveda govorimo o bolj strukturnem in industrijskem pristopu kot o ustvarjanju lastnih manifestov YAML in pisanju majhnih pripomočkov.
Helm je najboljše, kar je trenutno na voljo in priljubljeno.
Zakaj Helm? Predvsem zato, ker ga podpira CNCF. Cloud Native je velika organizacija in je matično podjetje za projekte Kubernetes itd., Fluentd in druge.
Pomembno dejstvo je tudi, da je Helm zelo priljubljen projekt. Ko sem januarja 2019 začel govoriti o tem, kako narediti Helm varen, je imel projekt na GitHubu tisoč zvezdic. Do maja jih je bilo 12 tisoč.
Veliko ljudi se zanima za Helm, zato vam bo koristno vedeti o njegovi varnosti, tudi če ga še ne uporabljate. Varnost je pomembna.
Jedro ekipe Helm podpira Microsoft Azure in je zato dokaj stabilen projekt, za razliko od mnogih drugih. Izid Helm 3 Alpha 2 sredi julija nakazuje, da na projektu dela precej ljudi, ki imajo željo in energijo za razvoj in izboljšanje Helma.
Helm rešuje več temeljnih problemov upravljanja aplikacij v Kubernetesu.
- Embalaža aplikacije. Tudi aplikacija, kot je »Hello, World« na WordPressu, je že sestavljena iz več storitev in želite jih zapakirati skupaj.
- Upravljanje zapletenosti, ki jo prinaša upravljanje teh aplikacij.
- Življenjski cikel, ki se ne konča po namestitvi ali uvedbi aplikacije. Še naprej živi, treba ga je posodabljati, Helm pa pri tem pomaga in skuša za to prinesti prave ukrepe in politike.
Vrečkanje organiziran je na jasen način: metapodatki so popolnoma v skladu z delom običajnega upravitelja paketov za Linux, Windows ali MacOS. To je repozitorij, odvisnosti od različnih paketov, meta informacije za aplikacije, nastavitve, konfiguracijske funkcije, indeksiranje informacij itd. Helm vam omogoča, da vse to pridobite in uporabite za aplikacije.
Upravljanje kompleksnosti. Če imate veliko aplikacij istega tipa, je potrebna parametrizacija. Predloge izhajajo iz tega, a da se izognete ustvarjanju lastnega načina ustvarjanja predlog, lahko uporabite tisto, kar ponuja Helm takoj po izdelavi.
Upravljanje življenjskega cikla aplikacije - po mojem mnenju je to najbolj zanimivo in nerešeno vprašanje. Zato sem nekoč prišel na Helm. Morali smo paziti na življenjski cikel aplikacije in želeli smo premakniti naše CI/CD in aplikacijske cikle na to paradigmo.
Helm vam omogoča:
- upravljanje razmestitev, uvaja koncept konfiguracije in revizije;
- uspešno izvedite povrnitev;
- uporabite kljuke za različne dogodke;
- dodajte dodatna preverjanja aplikacij in se odzovite na njihove rezultate.
Poleg tega Čelada ima "baterije" - ogromno okusnih stvari, ki jih je mogoče vključiti v obliki vtičnikov, ki vam poenostavljajo življenje. Vtičnike je mogoče napisati samostojno, so precej izolirani in ne zahtevajo harmonične arhitekture. Če želite nekaj implementirati, priporočam, da to naredite kot vtičnik in nato po možnosti vključite v navzgor.
Helm temelji na treh glavnih konceptih:
- Chart Repo — opis in niz možnih parametrizacij za vaš manifest.
- config —to je vrednosti, ki bodo uporabljene (besedilo, številske vrednosti itd.).
- Sprostite zbere dve zgornji komponenti in skupaj se spremenita v Release. Izdajam je mogoče omogočiti različice, s čimer se doseže organiziran življenjski cikel: majhen v času namestitve in velik v času nadgradnje, znižanja ali povrnitve.
Helmova arhitektura
Diagram konceptualno prikazuje arhitekturo Helma na visoki ravni.
Naj vas spomnim, da je Helm nekaj sorodnega Kubernetesu. Brez gruče (pravokotnik) Kubernetes torej ne moremo. Komponenta kube-apiserver se nahaja na masterju. Brez Helma imamo Kubeconfig. Helm prinaša en majhen binarni, če temu lahko tako rečemo, pripomoček Helm CLI, ki se namesti na računalnik, prenosnik, mainframe - na karkoli.
Vendar to ni dovolj. Helm ima strežniško komponento, imenovano Tiller. Zastopa interese Helma znotraj gruče, je aplikacija znotraj gruče Kubernetes, kot vsaka druga.
Naslednja komponenta Chart Repo je repozitorij z grafikoni. Obstaja uradni repozitorij, lahko pa tudi zasebni repozitorij podjetja ali projekta.
Interakcija
Poglejmo, kako komponente arhitekture medsebojno delujejo, ko želimo namestiti aplikacijo s Helmom.
- Govorimo
Helm install, odprite repozitorij (Chart Repo) in pridobite Helmov grafikon.
- Pripomoček Helm (Helm CLI) sodeluje s Kubeconfig, da ugotovi, s katero gručo se obrniti.
- Po prejemu te informacije se pripomoček nanaša na Tiller, ki se nahaja v naši gruči, kot aplikacijo.
- Tiller pokliče Kube-apiserver, da izvede dejanja v Kubernetesu, ustvari nekatere objekte (storitve, pode, replike, skrivnosti itd.).
Nato bomo zapletli diagram, da bomo videli vektor napada, ki mu je lahko izpostavljena celotna arhitektura Helm kot celota. In potem jo bomo poskušali zaščititi.
Vektor napada
Prva potencialna šibka točka je privilegiran API -Uporabnik. Kot del sheme je to heker, ki je pridobil skrbniški dostop do Helm CLI.
Uporabnik API brez pravic lahko predstavlja tudi nevarnost, če je nekje v bližini. Tak uporabnik bo imel drugačen kontekst, na primer, lahko ga določite v enem imenskem prostoru gruče v nastavitvah Kubeconfig.
Najbolj zanimiv vektor napada je lahko proces, ki se nahaja v gruči nekje blizu Tillerja in lahko dostopa do njega. To je lahko spletni strežnik ali mikrostoritev, ki vidi omrežno okolje gruče.
Eksotična, a vedno bolj priljubljena različica napada vključuje Chart Repo. Grafikon, ki ga je ustvaril brezobzirni avtor, lahko vsebuje nevarne vire in dopolnili ga boste tako, da ga boste verjeli. Lahko pa nadomesti grafikon, ki ga prenesete iz uradnega repozitorija, in na primer ustvari vir v obliki pravilnikov ter poveča dostop do njega.
Poskusimo ubraniti napade z vseh teh štirih strani in ugotoviti, kje so težave v arhitekturi Helm in kje jih morda ni.
Povečajmo diagram, dodamo več elementov, vendar ohranimo vse osnovne komponente.
Helm CLI komunicira s Chart Repo, sodeluje s Kubeconfig in delo se prenese v gručo na komponento Tiller.
Tiller je predstavljen z dvema predmetoma:
- Tiller-deploy svc, ki izpostavi določeno storitev;
- Tiller-deploy pod (na diagramu v enem izvodu v eni replici), na katerem teče celotno breme, ki dostopa do gruče.
Za interakcijo se uporabljajo različni protokoli in sheme. Z varnostnega vidika nas najbolj zanima:
- Mehanizem, s katerim Helm CLI dostopa do repoja grafikona: kateri protokol, ali obstaja avtentikacija in kaj je mogoče storiti z njo.
- Protokol, po katerem Helm CLI z uporabo kubectl komunicira s Tillerjem. To je strežnik RPC, nameščen znotraj gruče.
- Sam Tiller je dostopen mikrostoritvam, ki se nahajajo v gruči in sodelujejo s strežnikom Kube-apiser.
Razpravljajmo o vseh teh področjih po vrsti.
RBAC
Nima smisla govoriti o kakršni koli varnosti za Helm ali katero koli drugo storitev znotraj gruče, razen če je omogočen RBAC.
Zdi se, da to ni zadnje priporočilo, vendar sem prepričan, da veliko ljudi še vedno ni omogočilo RBAC niti v produkciji, ker je veliko razburjanja in je treba konfigurirati veliko stvari. Vendar vas spodbujam, da to storite.
— spletni odvetnik za RBAC. Vsebuje ogromno zanimivih materialov, ki vam bodo pomagali vzpostaviti RBAC, pokazati, zakaj je dober in kako v bistvu živeti z njim v produkciji.
Poskušal bom razložiti, kako delujeta Tiller in RBAC. Tiller deluje znotraj gruče pod določenim računom storitve. Običajno bo to superuporabnik, če RBAC ni konfiguriran. V osnovni konfiguraciji bo Tiller skrbnik. Zato se pogosto reče, da je Tiller tunel SSH do vaše gruče. Pravzaprav je to res, tako da lahko uporabite ločen namenski storitveni račun namesto privzetega storitvenega računa v zgornjem diagramu.
Ko inicializirate Helm in ga prvič namestite na strežnik, lahko nastavite storitveni račun z uporabo --service-account. To vam bo omogočilo uporabo uporabnika z minimalnim zahtevanim naborom pravic. Res je, da boste morali ustvariti takšno "garlando": Role in RoleBinding.
Na žalost Helm tega ne bo naredil namesto vas. Vi ali vaš skrbnik gruče Kubernetes morate vnaprej pripraviti nabor vlog in vezav vlog za storitveni račun, da lahko prenesete Helm.
Postavlja se vprašanje - kakšna je razlika med Role in ClusterRole? Razlika je v tem, da ClusterRole deluje za vse imenske prostore, za razliko od navadnih Roles in RoleBindings, ki delujejo samo za specializiran imenski prostor. Politike lahko konfigurirate za celotno gručo in vse imenske prostore ali jih prilagodite za vsak imenski prostor posebej.
Omeniti velja, da RBAC rešuje še en velik problem. Veliko ljudi se pritožuje, da Helm na žalost ni večnajemniški (ne podpira večnajemniškega). Če več ekip porabi gručo in uporablja Helm, je v bistvu nemogoče nastaviti politike in jim omejiti dostop znotraj te gruče, ker obstaja določen servisni račun, pod katerim teče Helm, in izpod njega ustvarja vse vire v gruči , kar je včasih zelo neprijetno. To je res - tako kot sama binarna datoteka, kot proces, Helm Tiller nima koncepta večnajemništva.
Vendar pa obstaja odličen način, ki vam omogoča, da Tiller večkrat zaženete v gruči. S tem ni težav, Tiller je mogoče zagnati v vsakem imenskem prostoru. Tako lahko kot kontekst uporabite RBAC, Kubeconfig in omejite dostop na poseben Helm.
Videti bo takole.
Na primer, obstajata dve konfiguraciji Kubeconfig s kontekstom za različne ekipe (dva imenska prostora): X Team za razvojno ekipo in skrbniško gručo. Skrbniška gruča ima lasten širok Tiller, ki se nahaja v imenskem prostoru sistema Kube, ustrezno napreden servisni račun. In ločen imenski prostor za razvojno ekipo, svoje storitve bodo lahko namestili v poseben imenski prostor.
To je uporaben pristop, Tiller ni tako lačen energije, da bi to močno vplivalo na vaš proračun. To je ena izmed hitrih rešitev.
Tiller lahko konfigurirate ločeno in zagotovite Kubeconfig s kontekstom za ekipo, za določenega razvijalca ali za okolje: Dev, Staging, Production (dvomljivo je, da bo vse v isti gruči, vendar je to mogoče).
Če nadaljujemo našo zgodbo, preklopimo z RBAC in govorimo o ConfigMaps.
ConfigMaps
Helm uporablja ConfigMaps kot shrambo podatkov. Ko smo govorili o arhitekturi, ni bilo nikjer baze podatkov, ki bi hranila informacije o izdajah, konfiguracijah, povrnitvah itd. Za to se uporablja ConfigMaps.
Glavna težava s ConfigMaps je znana - načeloma niso varni; nemogoče je shraniti občutljive podatke. Govorimo o vsem, kar ne bi smelo presegati storitve, na primer o geslih. Najbolj domači način za Helm trenutno je preklop z uporabe ConfigMaps na skrivnosti.
To se naredi zelo preprosto. Preglasite nastavitev Tiller in določite, da bo shramba skrivnost. Nato za vsako uvedbo ne boste prejeli ConfigMap, ampak skrivnost.
Lahko trdite, da so same skrivnosti čuden koncept in premalo varen. Vendar je vredno razumeti, da to počnejo sami razvijalci Kubernetes. Od različice 1.10, tj. Že kar nekaj časa je vsaj v javnih oblakih možno povezati pravilno shrambo za shranjevanje skrivnosti. Ekipa zdaj dela na načinih za boljšo distribucijo dostopa do skrivnosti, posameznih sklopov ali drugih entitet.
Storage Helm je bolje prenesti na skrivnosti, te pa so zaščitene centralno.
Seveda bo ostalo omejitev shranjevanja podatkov na 1 MB. Helm tukaj uporablja etcd kot porazdeljeno shrambo za ConfigMaps. In tam so menili, da je to primeren kos podatkov za replikacijo itd. Na Redditu poteka zanimiva razprava o tem, priporočam, da si za konec tedna poiščete to smešno branje ali preberete izvleček .
Grafikon Repos
Grafikoni so socialno najbolj ranljivi in lahko postanejo vir »človeka v sredini«, še posebej, če uporabljate standardno rešitev. Najprej govorimo o repozitorijih, ki so izpostavljeni prek HTTP.
Vsekakor morate Helm Repo izpostaviti prek HTTPS - to je najboljša možnost in je poceni.
Bodite pozorni mehanizem za podpis grafikona. Tehnologija je preprosta kot hudič. To je ista stvar, ki jo uporabljate na GitHubu, običajni napravi PGP z javnimi in zasebnimi ključi. Nastavite in se prepričajte, da imate potrebne ključe in vse podpišete, da je to res vaš grafikon.
poleg tega Odjemalec Helm podpira TLS (ne v smislu HTTP na strani strežnika, ampak medsebojni TLS). Za komunikacijo lahko uporabite ključe strežnika in odjemalca. Iskreno povedano, takega mehanizma ne uporabljam, ker ne maram medsebojnih potrdil. v bistvu, - glavno orodje za nastavitev Helm Repo za Helm 2 - podpira tudi osnovno avt. Uporabite lahko osnovno avtorizacijo, če je bolj priročno in tišje.
Obstaja tudi vtičnik , ki vam omogoča gostovanje Chart Repos v storitvi Google Cloud Storage. To je zelo priročno, odlično deluje in je precej varno, saj so vsi opisani mehanizmi reciklirani.
Če omogočite HTTPS ali TLS, uporabite mTLS in omogočite osnovno avtorizacijo za nadaljnje zmanjšanje tveganj, boste dobili varen komunikacijski kanal s Helm CLI in Chart Repo.
gRPC API
Naslednji korak je zelo pomemben - zavarovati Tiller, ki se nahaja v gruči in je na eni strani strežnik, na drugi strani pa sam dostopa do drugih komponent in se poskuša pretvarjati, da je nekdo.
Kot sem že rekel, je Tiller servis, ki izpostavlja gRPC, odjemalec Helm pride do njega preko gRPC. Privzeto je seveda TLS onemogočen. Zakaj je bilo to narejeno, je sporno vprašanje, zdi se mi, da bi poenostavili nastavitev na začetku.
Za produkcijo in celo uprizarjanje priporočam, da omogočite TLS na gRPC.
Po mojem mnenju je to za razliko od mTLS za grafikone tukaj primerno in se naredi zelo preprosto - ustvarite infrastrukturo PQI, ustvarite potrdilo, zaženite Tiller, prenesite potrdilo med inicializacijo. Po tem lahko izvedete vse ukaze Helm, pri čemer se predstavite z ustvarjenim potrdilom in zasebnim ključem.
Tako se boste zaščitili pred vsemi zahtevami Tillerju izven gruče.
Tako smo zavarovali povezovalni kanal s Tillerjem, že smo razpravljali o RBAC in prilagodili pravice apiserverja Kubernetes ter zmanjšali domeno, s katero lahko komunicira.
Zaščiten Helm
Poglejmo končni diagram. To je ista arhitektura z enakimi puščicami.
Vse povezave lahko zdaj varno narišete zeleno:
- za Chart Repo uporabljamo TLS ali mTLS in osnovno avtorizacijo;
- mTLS za Tiller in je izpostavljen kot storitev gRPC s TLS, uporabljamo certifikate;
- gruča uporablja poseben storitveni račun z Role in RoleBinding.
Grozd smo precej zavarovali, pa je nekdo pameten rekel:
"Popolnoma varna rešitev je lahko samo ena - ugasnjen računalnik, ki se nahaja v betonski škatli in ga varujejo vojaki."
Obstajajo različni načini za manipulacijo podatkov in iskanje novih vektorjev napadov. Vendar sem prepričan, da bodo ta priporočila dosegla osnovni industrijski standard za varnost.
bonus
Ta del ni neposredno povezan z varnostjo, vendar bo prav tako koristen. Pokazal vam bom nekaj zanimivih stvari, ki jih malokdo ve. Na primer, kako iskati grafikone - uradne in neuradne.
V skladišču Zdaj je približno 300 grafikonov in dva toka: stabilen in inkubator. Kdor prispeva, dobro ve, kako težko je priti iz inkubatorja v hlev in kako enostavno je poleteti iz hleva. Vendar pa to ni najboljše orodje za iskanje grafikonov za Prometheus in kar koli drugega, kar vam je všeč, iz enega preprostega razloga - ni portal, kjer bi lahko udobno iskali pakete.
Ampak obstaja služba , zaradi česar je iskanje grafikonov veliko bolj priročno. Najpomembneje je, da je na voljo veliko več zunanjih skladišč in skoraj 800 čarovnikov. Poleg tega lahko svoje skladišče povežete, če iz nekega razloga ne želite poslati svojih grafikonov v stable.
Preizkusite hub.helm.sh in ga skupaj razvijajmo. Ta storitev je v okviru projekta Helm in lahko celo prispevate k njenemu uporabniškemu vmesniku, če ste front-end razvijalec in želite le izboljšati videz.
Prav tako bi vas rad opozoril na Open Service Broker API integracija. Sliši se okorno in nejasno, a rešuje težave, s katerimi se srečuje vsak. Naj pojasnim s preprostim primerom.
Obstaja gruča Kubernetes, v kateri želimo poganjati klasično aplikacijo – WordPress. Na splošno je za popolno delovanje potrebna baza podatkov. Obstaja veliko različnih rešitev, na primer lahko zaženete lastno storitev s polnim stanjem. To ni zelo priročno, vendar veliko ljudi to počne.
Drugi, kot mi v Chainstacku, za svoje strežnike uporabljajo upravljane baze podatkov, kot sta MySQL ali PostgreSQL. Zato se naše baze podatkov nahajajo nekje v oblaku.
Toda pojavi se težava: našo storitev moramo povezati z bazo podatkov, ustvariti okus baze podatkov, prenesti poverilnico in jo nekako upravljati. Vse to navadno ročno naredi skrbnik sistema ali razvijalec. In ni problema, ko je malo aplikacij. Ko jih je veliko, rabiš kombajn. Obstaja tak kombajn - to je Service Broker. Omogoča vam uporabo posebnega vtičnika za gručo v javnem oblaku in naročanje virov pri ponudniku prek posrednika, kot da bi šlo za API. Če želite to narediti, lahko uporabite domača orodja Kubernetes.
Je zelo preprosto. Poizvedujete lahko na primer po Managed MySQL v Azure z osnovno plastjo (to je mogoče konfigurirati). Z uporabo Azure API bo baza podatkov ustvarjena in pripravljena za uporabo. V to se vam ni treba vmešavati, za to je odgovoren vtičnik. Na primer, OSBA (vtičnik Azure) bo vrnil poverilnico storitvi in jo posredoval Helmu. WordPress boste lahko uporabljali z oblakom MySQL, se sploh ne boste ukvarjali z upravljanimi bazami podatkov in ne boste skrbeli za storitve s popolnim stanjem v njih.
Lahko rečemo, da Helm deluje kot lepilo, ki na eni strani omogoča postavitev storitev, na drugi strani pa porablja vire ponudnikov v oblaku.
Lahko napišete svoj vtičnik in uporabite celotno zgodbo na mestu uporabe. Potem boste preprosto imeli svoj vtičnik za korporativnega ponudnika oblaka. Priporočam, da preizkusite ta pristop, še posebej, če imate velik obseg in želite hitro uvesti razvijalce, priprave ali celotno infrastrukturo za funkcijo. To bo olajšalo življenje za vaše operacije ali DevOps.
Druga ugotovitev, ki sem jo že omenil, je vtičnik helm-gcs, ki vam omogoča uporabo Google-buckets (shramba predmetov) za shranjevanje grafikonov Helm.
Za uporabo potrebujete samo štiri ukaze:
- namestite vtičnik;
- sproži ga;
- nastavite pot do vedra, ki se nahaja v gcp;
- objavite grafikone na standarden način.
Lepota je v tem, da bo za avtorizacijo uporabljena izvorna metoda gcp. Uporabite lahko storitveni račun, račun razvijalca, karkoli želite. Je zelo priročno in delovanje ne stane nič. Če tako kot jaz promovirate filozofijo brez opsov, potem bo to zelo priročno, zlasti za majhne ekipe.
Alternativa
Helm ni edina rešitev za upravljanje storitev. O njem je veliko vprašanj, zato se je verjetno tako hitro pojavila tretja različica. Seveda obstajajo alternative.
To so lahko specializirane rešitve, na primer Ksonnet ali Metaparticle. Svoja klasična orodja za upravljanje infrastrukture (Ansible, Terraform, Chef itd.) lahko uporabite za iste namene, o katerih sem govoril.
Končno obstaja rešitev , katerega priljubljenost narašča.
Operator Framework je najboljša alternativa Helmu, ki jo je treba upoštevati.
Bolj izviren je iz CNCF in Kubernetes, vendar je ovira za vstop veliko večja, morate več programirati in manj opisovati manifeste.
Obstajajo različni dodatki, kot so Draft, Scaffold. Zelo olajšajo življenje, na primer poenostavijo cikel pošiljanja in zagona programa Helm za razvijalce, da uvedejo testno okolje. Imenoval bi jih opolnomočevalci.
Tukaj je vizualni grafikon, kje vse je.
Na osi x je raven vašega osebnega nadzora nad dogajanjem, na osi y je stopnja domorodnosti Kubernetesa. Helm verzija 2 je nekje na sredini. V različici 3 ne izjemno, vendar sta izboljšana nadzor in stopnja domorodnosti. Rešitve na nivoju Ksonnet so še vedno slabše tudi od Helm 2. Vendar se jih splača pogledati, da veste, kaj je še na tem svetu. Seveda bo vaš upravitelj konfiguracije pod vašim nadzorom, vendar nikakor ni izviren iz Kubernetesa.
Operator Framework je popolnoma izviren iz Kubernetesa in vam omogoča, da ga upravljate veliko bolj elegantno in natančno (vendar ne pozabite na vstopno raven). To je bolj primerno za specializirano aplikacijo in ustvarjanje upravljanja zanjo, ne pa za masovni žetvenik za pakiranje ogromnega števila aplikacij z uporabo Helma.
Razširitve preprosto nekoliko izboljšajo nadzor, dopolnijo potek dela ali zmanjšajo vogale na cevovodih CI/CD.
Prihodnost Helma
Dobra novica je, da prihaja Helm 3. Alfa različica Helm 3.0.0-alpha.2 je že izšla, lahko jo preizkusite. Je precej stabilen, vendar je funkcionalnost še vedno omejena.
Zakaj potrebujete Helm 3? Najprej je to zgodba o izginotje Tillerja, kot sestavni del. To je, kot že razumete, velik korak naprej, saj je z vidika varnosti arhitekture vse poenostavljeno.
Ko je bil ustvarjen Helm 2, kar je bilo približno v času Kubernetesa 1.8 ali celo prej, je bilo veliko konceptov nezrelih. Na primer, koncept CRD se zdaj aktivno izvaja in Helm ga bo uporabite CRDza shranjevanje struktur. Možno bo uporabljati samo odjemalca in ne vzdrževati strežniškega dela. V skladu s tem uporabite izvorne ukaze Kubernetes za delo s strukturami in viri. To je velik korak naprej.
Se bo prikazal podpora za izvorne repozitorije OCI (Pobuda za odprte zabojnike). To je ogromna pobuda in Helm se zanima predvsem zato, da objavi svoje karte. Pride do točke, ko na primer Docker Hub podpira številne standarde OCI. Ne ugibam, toda morda vam bodo klasični ponudniki repozitorija Docker začeli dajati priložnost, da gostite svoje karte Helm.
Zame je kontroverzna zgodba Podpora za Lua, kot mehanizem za predloge za pisanje skriptov. Nisem velik oboževalec Lue, vendar bi bila to popolnoma neobvezna funkcija. To sem preveril 3-krat - uporaba Lua ne bo potrebna. Zato se tisti, ki želite uporabljati Lua, tisti, ki imate radi Go, pridružite našemu ogromnemu taboru in za to uporabite go-tmpl.
Končno je tisto, kar sem zagotovo pogrešal nastanek sheme in preverjanje vrste podatkov. Ne bo več težav z int ali nizom, ni potrebe po zavijanju ničle v dvojne narekovaje. Pojavila se bo shema JSONS, ki vam bo omogočila, da to izrecno opišete za vrednosti.
Bo močno predelan model, ki temelji na dogodkih. Konceptualno je že opisano. Poglejte vejo Helm 3 in videli boste, koliko dogodkov in kavljev in drugih stvari je dodanih, kar bo močno poenostavilo in po drugi strani dodalo nadzor nad procesi uvajanja in odzivi nanje.
Helm 3 bo preprostejši, varnejši in bolj zabaven, ne zato, ker nam Helm 2 ni všeč, ampak zato, ker Kubernetes postaja vse naprednejši. V skladu s tem lahko Helm uporabi razvoj Kubernetesa in na njem ustvari odlične upravitelje za Kubernetes.
Druga dobra novica je, da Alexander Khayorov vam bo povedal, Spomnimo, konferenca o integraciji procesov razvoja, testiranja in delovanja bo potekala v Moskvi 30. septembra in 1. oktobra. To lahko storite še do 20. avgusta in nam povejte svoje izkušnje z rešitvijo naloge pristopa DevOps.
Spremljajte konferenčne kontrolne točke in novice na и .
Vir: www.habr.com