Helmi turvalisus

Lugu kõige populaarsema paketihalduri Kubernetes'e jaoks võiks kirjeldada emoji-de abil:

• kast — see on Helm (see on kõige sobivam emoji viimasest väljaandest);
• lukk — turvalisus;
• inimene — probleemide lahendamine.

Tegelikkuses on kõik natuke keerulisem, ning jutt on täis tehnilisi üksikasju sellest, kuidas teha Helm turvaliseks.

• Lühidalt, mis on Helm, kui te ei teadnud või olete unustanud. Milliseid probleeme see lahendab ja kus see ekosüsteemis asub.
• Vaadakem Helmi arhitektuuri. Ükski vestlus turvalisusest ja sellest, kuidas muuta tööriist või lahendus turvalisemaks, ei saa mööda minna komponendi arhitektuuri mõistmisest.
• Arutame Helmi komponente.
• Kõige põletavam küsimus — tulevik — uus versioon Helm 3. 

Kogu see artikkel puudutab Helm 2. See versioon on hetkel tootmises ja tõenäoliselt just seda te kasutate, ning just selles on turvariskid.

Esinejast: Aleksandr Khayorov (allexx) on arendusega seotud olnud 10 aastat, aitab parandada sisu Moscow Python Conf++ ja liitus Helm Summit. Praegu töötab Chainstackis arenduse juhtimispositsioonil, mis on hübriid arendusjuhi ja final release delivery inimese vahel. See tähendab, et ollakse seal, kus toimub kõik toote loomise ja käitamise vahel.

Chainstack on väike, kiiresti kasvav idufirma, mille eesmärk on anda klientidele võimalus unustada infrastruktuuri ja keerukused, mis on seotud detsentraliseeritud rakenduste haldamisega. Arendustiim asub Singapuris. Ärge paluge Chainstackil müüa või osta krüptovaluutat, vaid pakkuge võimalust arutada ettevõtte blockchain raamistikke, ja neile vastatakse rõõmuga.

Helm

See on pakihaldur (chart) Kubernetes jaoks. Kõige arusaadavam ja universaalsem viis rakenduste toomiseks Kubernetes klastrisse.

Räägime selgelt struktureerituma ja tööstuslikuma lähenemise poole, mitte ainult oma YAML-manifestide loomise ja väikeste utiliitide kirjutamise suunas.

Helm on hetkel parim ja populaarne valik, mis on kergesti kättesaadav.

Miks Helm? Esiteks seetõttu, et seda toetab CNCF. Cloud Native on suur organisatsioon, mis on Kubernetes, etcd, Fluentd ja teiste projektide emafirma.

Teine oluline fakt on see, et Helm on väga populaarne projekt. Kui ma jaanuaris 2019 alles mõtlesin, kuidas Helm'i turvaliseks muuta, oli projektil GitHub'is tuhat tähte. Maiks oli neid juba 12 tuhat.

Paljud inimesed on huvitatud Helm'ist, seega, isegi kui te pole seda veel kasutanud, on teadmised selle turvalisusest kasulikud. Turvalisus on oluline.

Helm'i peamist meeskonda toetab Microsoft Azure, mistõttu on see üsna stabiilne projekt, erinevalt paljusid teistest. Helm 3 Alpha 2 väljalaskmine juuli keskpaiku tõendab, et projekti kallal töötab piisavalt palju inimesi, kes soovivad ja suudavad Helmi arendada ja täiustada.

Helm lahendab mitu põhihalduse probleemi Kubernetes'is rakenduste haldamisel.

• Rakenduse paketiseerimine. I isegi "Hello, World" tüüp rakendus WordPressis koosneb mitmest teenusest, mida tahaks kokku pakendada.
• Keskendumine keerukuse haldamisele, mis tuleneb nende rakenduste juhtimisest.
• Elutsükli ei lõppe pärast rakenduse installimist või juurutamist. See jätkab elu, vajab värskendamist, ning selles aitab Helm, tuues õigeid meetmeid ja poliitikaid.

Pakendamine on korraldatud arusaadavalt: metainformatsioon on täielikus kooskõlas tavapäraste Linuxi, Windowsi või MacOSi pakendihaldurite tööl. See tähendab, et on olemas hoidla, sõltuvused erinevatest pakettidest, rakenduste metainformatsioon, seadistused, konfiguratsiooni eripärad, informatsiooni indekseerimine jne. Kõik see on Helmiga saadaval ja rakenduste jaoks kasutatav.

Kasutusmugavuse juhtimine. Kui teil on palju sarnaseid rakendusi, on vajalik parameetriseerimine. Sellest tulenevad mallid, kuid et mitte leiutada omi mallide loomise meetodeid, saab kasutada seda, mida Helm pakub.

Rakenduste elutsükli haldamine — minu arvates on see kõige huvitavam ja lahendamatu küsimus. Just seetõttu tulin ma Helm’i juurde. Me peame jälgima rakenduse elutsüklit, soovisime viia oma CI/CD ja rakenduste tsüklid sellesse paradigmasse.

Helm võimaldab:

• deploide hallata, toob sisse konfiguratsiooni ja revisjoni mõisted;
• edukalt teostada rollback;
• kasutada erinevate sündmuste jaoks hook'e;
• lisada rakendustele täiendavaid kontrollpunkte ja reageerida nende tulemustele.

Lisaks on Helm'il "aku" — tohutu hulk maitsvaid asju, mida saab pluginatena sisse lülitada, muutes elu lihtsamaks. Pluginaid on võimalik iseseisvalt kirjutada, need on piisavalt isoleeritud ega nõua keerulist arhitektuuri. Kui soovite midagi ellu viia, soovitan teha seda pluginana ja seejärel võimalusel lisada upstream'i.

Helm põhineb kolmel peamisel kontseptsioonil:

• Chart Repo — kirjeldus ja parameetrite massiiv, mis on teie manifestile võimalikud. 
• Konfiguratsioon — see tähendab väärtusi, mis rakendatakse (tekst, numbrilised väärtused jne).
• Release koondab kaks ülemist komponenti, ning koos need muutuvad Release'iks. Väljalaskeid saab versioonida, saavutades seeläbi elutsükli korralduse: väike paigaldamise hetkel ja suur värskendamise, allapoole viimise või rollback'i hetkel.

Helmi arhitektuur

Scheemil on kontseptuaalselt esitatud Helmi kõrgetasemeline arhitektuur.

Tulet meelde, et Helm on seotud Kubernetesega. Seetõttu vajame Kubernetes-klassi (ristkülikut). Komponent kube-apiserver asub masteris. Ilma Helmita on meil Kubeconfig. Helm toob endaga kaasa väikese binaarse utiliidi, mida nimetatakse Helm CLI, mis installitakse arvutisse, sülearvutisse, peamisse või kuhu iganes.

Kuid sellest ei piisa. Helmil on serveri komponent Tiller. See esindab Helmi klastris, olles rakendus, mis asub Kubernetes-klastris, nagu iga teinegi.

Järgmine komponent on Chart Repo – chartide hoidla. On ametlik hoidla ja võib olla ka ettevõtte või projekti privaatne hoidla.

Koostoime

Vaadakem, kuidas arhitektuuri komponendid omavahel suhtlevad, kui soovime rakendust Helmiga installida.

• Me ütlem Helm install, ühendame hoidla (Chart Repo) ja saame Helm-charti.

• Helmi utiliit (Helm CLI) suhtleb Kubeconfigiga, et välja selgitada, millise klastri poole pöörduda. 
• Saades selle teabe, pöördub utiliit Tilleri poole, mis asub meie klastris, rakendusena. 
• Tiller suunab Kube-apiserverile, et teostada toiminguid Kuberneteses, luua erinevaid objekte (teenuseid, pod'e, replikaid, salajasi jne).

Seejärel keerame skeemi keerulisemaks, et näha rünnakusuundi, millega kogu Helm arhitektuur kokku puutub. Ja siis püüame seda kaitsta.

Rünnakusuund

Esimene potentsiaalselt nõrk koht — privileegitud API—kasutaja. Skeemi kohaselt on see häkker, kes on saanud administraatori juurdepääsu Helm CLI-le.

Privileegita API-kasutaja võib samuti ohtuda, kui ta on kuskil läheduses. Sellisel kasutajal on erinev kontekst, näiteks võib ta olla seotud teatud namespace'iga klastris Kubeconfigi seadetes.

Kõige huvitavam rünnakusuund võib olla protsess, mis asub klastris kuskil lähedal Tillerile ja saab sellele juurdepääsu. See võib olla veebiserver või mikroteenus, mis näeb klastrivõrgu keskkonda.

Eksootiline, kuid kiiresti populaarsust koguv rünne on seotud Chart Repo'ga. Väärkasutaja loodud chart võib sisaldada ebaturvalisi ressursse, ja te võite selle tõsiselt võtta. Või siis võib see asendada chart'i, mille te laadite alla ametlikust hoidlast, ja näiteks luua ressurssi poliitikate näol ning endale juurdepääsu suurendada.

Püüame kaitsta end rünnakute eest kõigist neljast suunast ja analüüsida, kus on Helmi arhitektuuris probleemid ning kus võib-olla neid pole.

Suurendame skeemi, lisame rohkem komponente, kuid säilitame kõik põhielemendid.

Helm CLI suhtub Chart Repo'sse, suhtleb Kubeconfig'i kaudu, töö edastatakse klastrisse komponendi Tiller kaudu.

Tiller on esindatud kahe objektiga:

• Tiller-deploy svc, mis pakub teatud teenust;
• Tiller-deploy pod (skeemil ühes eksemplaris ühes replikas), kus koormus töötab ja mis pöördub klastrisse.

Suhtlemiseks kasutatakse erinevaid protokolle ja skeeme. Turvalisuse seisukohalt on meile kõige huvitavamad:

• Mehhanism, millega Helm CLI pöördub chart repo'sse: milline on protokoll, kas on olemas autentimine ja mida sellega teha saab.
• Protokoll, mille kaudu Helm CLI suhtleb Tilleriga, kasutades kubectl'i. See on RPC-server, mis on paigaldatud klastrisse.
• Ise Tiller on ligipääsetav mikroteenustele, mis asuvad klastris, ja suhtleb Kube-apiserveriga.

Arutame neid kõiki suundi järjekorras.

RBAC

Pole mõtet rääkida Helm'i või muu teenuse turvalisusest klastris, kui RBAC ei ole lubatud.

Tundub, et see ei ole kõige värskem soovitus, kuid olen kindel, et paljud pole RBAC'i isegi tootmises lubanud, kuna see on suur vaev ja nõuab palju seadistamist. Siiski kutsun üles seda tegema.

https://rbac.dev/ — veebileht RBAC'i kohta. Seal on kogutud tohutul hulgal huvitavat materjali, mis aitab RBAC'i seadistada, näitab, miks see on hea ja kuidas sellega tootmises elada.

Püüan selgitada, kuidas Tiller ja RBAC töötavad. Tiller töötab klastri sees mingi teenusekonto alt. Reeglina, kui RBAC pole seadistatud, on see superkasutaja. Algses konfiguratsioonis on Tiller administraator. Just seetõttu räägitakse sageli, et Tiller on SSH-tunnel teie klastrisse. Tegelikult on see nii, seega on võimalik kasutada eraldi spetsialiseeritud teenusekontot Default Service Account'i asemel ülaltoodud skeemis.

Kui te algatate Helm'i, installides seda esmakordselt serverisse, saate määrata teenusekonto, kasutades --service-account. See võimaldab kasutada kasutajat, kellel on minimaalne vajalik õiguste paket. Tõsi, peate looma sellise "pärja": Role ja RoleBinding.

Kahjuks ei tee Helm seda teie eest. Teie või teie Kubernetes klastri administraator peab eelnevalt ette valmistama Role'd ja RoleBinding'i teenusekonto jaoks, et edastada Helm'ile.

Küsimus on — milles seisneb erinevus Role ja ClusterRole vahel? Erinevus on selles, et ClusterRole kehtib kõigi namespaces, erinevalt tavalisest Role ja RoleBinding'ist, mis töötab ainult spetsialiseeritud namespace'is. Poliitikaid saab seadistada nii kogu klastri kui ka individuaalselt iga namespace'i jaoks.

Tasub mainida, et RBAC lahendab veel ühe suure probleemi. Paljud kurdavad, et Helm ei toeta multitenancy't (mitmeüürilisust). Kui mitu meeskonda kasutavad klastri ja Helm'i, ei ole võimalik seadistada poliitikaid ega piirata nende ligipääsu selle klastri piires, kuna helm töötab teenusekonto kaudu ja loob sellest kõik ressursid klastri sees, mis mõnikord on väga ebamugav. See on tõsi — nagu binaarfail, nagu protsess. Helm Tiller ei mõista multitenancy't..

Kuid on olemas suurepärane võimalus, mis võimaldab Tillerit klastris mitu korda käivitada. Sellega ei ole mingeid probleeme, Tillerit saab käivitada igas namespace'is. Nii saate kasutada RBAC-d, Kubeconfig'i konteksti ja piirata juurdepääsu spetsiaalsele Helmile.

See näeb välja järgmiselt.

Näiteks on kaks Kubeconfig'i konteksti erinevate meeskondade jaoks (kaks namespace'i): X Team arendajate meeskonnale ja administraatori klaster. Administratiivsel klastril on oma laiem Tiller, mis asub Kube-system namespace'is, seega edasijõudnud teenusekontoga. Ja eraldi namespace arendajate meeskonnale, kes saavad oma teenuseid eraldi namespace'is deployida.

See on tõhus lähenemine, Tiller ei ole nii ressursinõudlik, et see võiks teie eelarvet tõsiselt mõjutada. See on üks kiiremaid lahendusi.

Ärge kartke seadistada Tiller eraldi ja anda Kubeconfig koos konteksti meeskonnale, konkreetsele arendajale või keskkonnale: Dev, Staging, Production (on ebatõenäoline, et kõik oleks ühes klastris, kuid seda on võimalik teha).

Jätkates meie lugu, liigume edasi RBAC-lt ja räägime ConfigMapsist.

ConfigMaps

Helm kasutab ConfigMaps andmete salvestamiseks. Kui me rääkisime arhitektuurist, siis seal ei olnud andmebaasi, kus hoida teavet väljaannete, konfiguratsioonide, tagasi võtmiseks ja muu kohta. Selle jaoks kasutatakse ConfigMaps'i.

ConfigMaps'iga seonduv peamine probleem on tuntud — need ei ole põhimõtteliselt turvalised, neis ei saa hoida tundlikke andmeid. See puudutab kõike, mis ei peaks minema kaugemale teenusest, näiteks paroole. Helm jaoks on kõige loomulikum viis praegu liikuda ConfigMaps'i kasutamiselt saladuste (secrets) suunas.

Seda on väga lihtne teha. Ümberdefineerite Tilleri seadistuse ja määrate, et salvestamiseks on saladused. Siis saate igal juurutamisel mitte ConfigMap'i, vaid salajase (secret).

Võite väita, et saladused ise on kummaline kontseptsioon ja see ei ole eriti turvaline. Siiski, tuleb mõista, et sellega tegelevad Kubernetes'i arendajad ise. Alates versioonist 1.10, st üsna ammu, on vähemalt avalikes pilvedes olemas võimalus ühendada õige salvestus ruum saladuste hoidmiseks. Praegu töötab meeskond selle nimel, et veelgi paremini jagada juurdepääsu saladustele, eraldi podidele või muudele üksustele.

Storage Helm on parem tõlkida saladusteks, mis omakorda tuleb tsentraliseeritult kaitsta.

Loomulikult jääb andmete salvestuslimiit 1 MB. Helm kasutab siin etcd-d jaotatud salvestusena ConfigMapide jaoks. Seal arvati, et see on sobiv andmechunk replikatsioonideks ja nii edasi. Selle kohta on huvitav arutelu Redditis, soovitan leida see mõnus lugemine nädalavahetuseks või lugeda kokkuvõtet. siin.

Chart Repos

Chardid on kõige sotsiaalselt haavatavad ja võivad saada "mehe keset" rünnaku allikaks, eriti kui kasutada default lahendust. Esiteks räägime HTTP kaudu eksponeeritud repositooriumidest.

Selgelt tuleb Helm Repo eksponeerida HTTPS-i kaudu — see on parim variant ja ei maksa palju.

Pange tähele chartide allkirjastamise mehhanismi. Tehnoloogia on üllatavalt lihtne. See on sama, mida kasutate GitHubis, tavaline PGP mehhanism avalike ja privaatsete võtmetega. Seadistage see ja saate olla kindel, et omades õigeid võtmeid allkirjastate kõik, mis on tõepoolest teie chart.

Lisaks toetab Helm-klient TLS-i. (mitte HTTP serveri poolt, vaid vastastikune TLS). Saate kasutada serveri ja kliendi võtmeid suhtlemiseks. Pean ausalt ütlema, et ma ei kasuta sellist mehhanismi, kuna ei care vastastikute sertifikaatide vastu. Ühesõnaga, chartmuseum — peamine tööriist Helm Repo eksponeerimiseks Helm 2 jaoks — toetab ka baasauthentimist. Baasauthentimist saab kasutada, kui see on mugavam ja rahulikum.

On ka plugin helm-gcs, mis võimaldab paigutada Chart Repos Google Cloud Storage'isse. See on üsna mugav, töötab hästi ja on piisavalt безопасно, kuna kõik kirjeldatud mehhanismid on aktiveeritud.

Kui aktiveerida HTTPS või TLS, kasutada mTLS, sisse lülitada baasauthentimine, et veelgi vähendada riske, saab turvalise suhtluskanaali Helm CLI ja Chart Repo vahel.

gRPC API

Järgmine samm on väga vastutustundlik — kaitsta Tilleri, mis asub klastris ja on ühelt poolt server, teiselt poolt — pöördub ta teiste komponentide poole ja proovib esindada kedagi.

Nagu ma juba ütlesin, Tiller on teenus, mis pakub gRPC-d, Helm-klient pääseb sellele gRPC kaudu juurde. Vaikimisi on TLS loomulikult välja lülitatud. Miks see nii on — see on vaieldav küsimus, kuid arvan, et see lihtsustab algse seadistamise protsessi.

Soovitan angažerluse ja isegi staging’i jaoks TLS gRPC-s sisse lülitada.

Minu arvates, erinevalt mTLS-ist chartide puhul, on see siin asjakohane ning teostatakse väga lihtsalt — genereerite PQI infrastruktuuri, loote sertifikaadi, käivitate Tilleri, edastate sertifikaadi initsialiseerimise käigus. Pärast seda saab täita kõik Helm-käsud, kasutades genereeritud sertifikaati ja privaatvõtmen.

Nii kaitsete end kõikide Tilleri välisklusteri päringute eest.

Nii oleme kaitsnud ühenduskanali Tilleriga, arutanud RBAC-i ja seadnud Kubernetes apiserveri õigused korda, vähendanud domeeni, millega see suudab suhelda.

Kaitstud Helm

Vaatame lõppskeemi. See on sama arhitektuur sama noolekujuga.

Kõik ühendused võib nüüd julgelt kujutada rohelisega:

• Chart Repo puhul kasutame TLS-i või mTLS-i ja basic auth'i;
• mTLS Tilleri jaoks, ja see on gRPC teenusena välja pakutud koos TLS-iga, kasutame sertifikaate;
• klassis kasutatakse spetsiaalset teenusekontot koos Rolli ja Rolli sidumisega. 

Oleme märkimisväärselt turvanud klastri, kuid keegi tark ütles:

„Ainus täiesti ohutu lahendus on välja lülitatud arvuti, mis asub betoonkastis ja mida kaitsevad sõdurid.”

Andmete manipuleerimiseks ja uute rünnakuvektorite leidmiseks on erinevaid viise. Kuid ma olen kindel, et need soovitused võimaldavad rakendada põhitasemel tööstuslikku turvastandardit.

Boonus

See osa ei ole otseselt seotud turvalisusega, kuid on samuti kasulik. Näitan mõningaid huvitavaid asju, millest paljud ei tea. Näiteks, kuidas otsida graafikuid – ametlikke ja mitte ametlikke.

Repo github.com/helm/charts on praegu umbes 300 graafikut ja kaks voogu: stable ja incubator. Need, kes panustavad, teavad hästi, kui raske on incubator'ist stable'i jõuda ja kui lihtne on stable'ist välja kukkuda. Kuid see ei ole parim tööriist, et otsida graafikuid Prometheus'e ja kõike muud, mis sulle meeldib, ühe lihtsa põhjuse tõttu – see ei ole portaal, kus oleks mugav pakette otsida.

Kuid on teenus hub.helm.sh, millega on graafikute leidmine palju mugavam. Peamine, et seal on palju rohkem väliseid hoidlaid ja saadaval on peaaegu 800 graafikut. Lisaks saate oma hoidla ühendada, kui te mingil põhjusel ei soovi oma graafikuid stable'i saata.

Proovige hub.helm.sh ja arendame seda koos. See teenus on Helm-projekti all ja saate panustada isegi selle kasutajaliidesesse, kui olete frontend arendaja ja soovite lihtsalt välimust parandada.

Soovin veel teie tähelepanu juhtida Open Service Broker API integratsioon. See võib tunduda keeruline ja arusaamatu, kuid lahendab probleeme, millega kõik silmitsi seisavad. Selgitan lihtsa näitega.

On Kubernetes klaster, kus soovime käivitada klassikalist rakendust - WordPressi. Üldiselt on täieõiguslikkuseks vajalik andmebaas. On palju erinevaid lahendusi, näiteks saate käivitada oma statefull-teenuse. See ei ole väga mugav, kuid paljud teevad seda.

Teised, näiteks meie Chainstackis, kasutavad hallatavaid andmebaase, nagu MySQL või PostgreSQL, serverite jaoks. Seega on meie andmebaasid kuskil pilves.

Kuid problema on see, et meie teenus tuleb ühendada andmebaasiga, luua andmebaasi flavor, edastada volitused ja hallata neid kuidagi. Kõik see tehakse tavaliselt käsitsi süsteemiadministraatori või arendaja poolt. Ja probleemi ei ole, kui rakendusi on vähe. Kui neid on palju, on vaja kombaini. Selline kombain on olemas — see on Service Broker. See võimaldab kasutada spetsiaalset plugina avaliku pilve klastrile ja tellida ressursse teenusepakkujalt Brokeri kaudu, nagu oleks see API. Selleks võib kasutada Kubernetes'e natiivseid tööriistu.

See on väga lihtne. Näiteks saab taotleda Azure'is Hallatud MySQL põhitasemel (seda saab seadistada). Azure'i API abil luuakse ja valmistatakse andmebaas kasutamiseks ette. Te ei pea sekkuma, selle eest vastutab plugin. Näiteks OSBA (Azure'i plugin) tagastab volitused teenusele ja edastab need Helm'ile. Saate kasutada WordPressi koos pilvepõhise MySQL'iga, tegelemata hallatud andmebaasidega ja muretsemata stateful teenuste üle.

Võib öelda, et Helm toimib liimina, mis ühest küljest võimaldab teenuseid juurutada ja teisest küljest tarbida pilveteenuse pakkujate ressursse.

Saate kirjutada oma plugina ja kasutada kogu seda infrastruktuuri on-premise. Siis on teil lihtsalt oma plugin ettevõtte pilveteenuse pakkujaga. Soovitan proovida sellist lähenemist, eriti kui teie ulatus on suur ja soovite kiiresti häälestada dev, staging või kogu infrastruktuuri funktsiooni jaoks. See lihtsustab teie operations või DevOpsi elu.

Veel üks leid, millest olen juba rääkinud — see on plugin helm-gcs, mis võimaldab kasutada Google'i bucket'e (objekthoidlat), et salvestada Helm'i graafikud.

Selle kasutamise alustamiseks on vaja ainult nelja käsku:

1. paigaldada plugin;
2. algatada see;
3. määrata tee bucket'ile, mis asub gcp-s;
4. avalikustada graafikud standardsel viisil.

Ilus on see, et GCP autoriseerimiseks kasutatakse natiivset meetodit. Saate kasutada teenusekontot, arendajate kontot — kõike, mis sobib. See on väga mugav ja ei maksa midagi kasutuses. Kui te, nagu mina, toetate opsless filosoofiat, siis on see väga mugav, eriti väikeste meeskondade jaoks.

Alternatiivid

Helm ei ole ainus lahendus teenuste haldamiseks. Selle kohta on palju küsimusi ja tõenäoliselt seetõttu on kiiresti ilmunud kolmas versioon. Loomulikult on ka alternatiive.

Need võivad olla nii spetsialiseeritud lahendused, nagu Ksonnet või Metaparticle, kui ka teie klassikalised infrastruktuuri haldamise tööriistad (Ansible, Terraform, Chef jne), et saavutada samu eesmärke, millest ma rääkisin.

Lõpuks on olemas lahendus Operator Framework, mille populaarsus kasvab.

Operator Framework on peamine alternatiiv Helmile, millele tasub tähelepanu pöörata.

See on CNCF ja Kubernetesiga palju loomulikum, aga sisenemiskünnis on oluliselt kõrgem, vajab rohkem programmeerimist ja vähem manifeste kirjeldamist.

On erinevaid lisasid, nagu Draft, Scaffold. Need muudavad elu oluliselt lihtsamaks, näiteks arendajatele, vähendades Helm'i saatmise ja testkeskkonna käivitamise tsüklit. Nimetaksin neid võimaluste laiendajateks.

Siin on selge diagramm, kus on esitatud erinevad asukohad.

X-teljel on teie isikliku kontrolli tase, Y-teljel on Kubernetes'i natiivsuse tase. Helm versioon 2 asub kuskil keskel. Versioonis 3 pole suuri muutusi, kuid nii kontroll kui natiivsuse tase on paranenud. Ksonneti taseme lahendused jäävad siiski isegi Helm 2-le alla. Siiski tasub neid vaadata, et näha, mida veel selles maailmas leidub. Loomulikult on teie konfiguratsioonihaldur teie kontrolli all, kuid see pole Kubernetes'ile täiesti natiivne.

Operator Framework on täiesti natiivne Kubernetes'ile ning võimaldab seda hallata palju elegantselt ja täpselt (aga pidage meeles sisenemistaset). Pigem sobib see spetsialiseeritud rakenduste haldamiseks, mitte massiliseks rakenduste pakendamise kombinatsiooniks Helmiga.

Täpsemad laiendused parandavad lihtsalt veidi kontrolli, täiendavad töövoogu või vähendavad CI/CD pipeline'ide nurki.

Helmi tulevik

Hea uudis on see, et on saabumas Helm 3. Helm 3.0.0-alpha.2 beetaversioon on juba välja antud ja seda saab proovida. See on piisavalt stabiilne, kuid funktsionaalsus on hetkel piiratud.

Miks on vajalik Helm 3? Esiteks on see lugu Tilleri kadumisest, kui komponendi. See, nagu te juba aru saanud olete, on suur edasimineku samm, kuna arhitektuuri turvalisuse vaates muutub kõik lihtsamaks.

Helm 2 loomise ajal, mis toimus Kubernetes 1.8 või isegi varem, olid paljud kontseptsioonid veel arendamata. Näiteks on CRD kontseptsioon praegu aktiivselt juurutamisel, ja Helm hakkab kasutama CRD, et hoida struktuure. On võimalik kasutada ainult klienti ja mitte hoida serveripoolset osa. Vastavalt sellele saavad kasutada natiivseid Kubernetes'i käske struktuuride ja ressurssidega töötamiseks. See on suur edasiminek.

Ilmub natiivsete OCI repositooriumide (Open Container Initiative) tugi. See on suur algatus ja Helm on sellest huvitatud eeskätt selleks, et paigutada oma chart'id. Seda toetab isegi Docker Hub, mis toetab paljusid OCI standardeid. Ma ei ütle, et see kindlasti juhtub, aga võib-olla klassikalised Docker repositooriumide pakkujad hakkavad võimaldama teil oma Helm chart'e paigutada.

Minu jaoks on vaieldav teema — see on Lua toimetamine, kui templating engine skriptide kirjutamiseks. Ma ei ole väga suur Lua fänn, kuid see on täiesti valikuline võimalus. Olen seda kolm korda kontrollinud — Lua kasutamine ei ole kohustuslik. Seega, kes soovib, võib kasutada Lua, kes armastab Go — liituge meie suure laagriga ja kasutage go-tmpl selleks.

Lõpuks, mida ma tõeliselt igatsesin — see on skeemide ilmumine ja andmetüüpide valideerimine. Probleemid int või stringiga on kadunud, ei ole enam vaja nulli topeltjutumärkidesse panna. Tekib JSONS-skeem, mis võimaldab seda väärtuste selgelt kirjeldada.

Seda sündmustepõhist mudeliton tugevasti ümber töötatud. See on juba kontseptuaalselt kirjeldatud. Vaadake Helm 3 haru ja näete, kui palju sündmusi ja haake on lisatud, mis oluliselt lihtsustab ja samas annab rohkem kontrolli juurutamise protsesside ja nende reageerimise üle.

Helm 3 on lihtsam, turvalisem ja huvitavam mitte sellepärast, et me ei armasta Helm 2, vaid seetõttu, et Kubernetes areneb edasi. Vastavalt sellele saab Helm kasutada Kubernetes'i arendusi ja luua selle põhjal suurepäraseid juhte Kubernetes'i jaoks.

Veel üks hea uudis on see, et DevOpsConf Aleksandr Khayorov räägib, kas konteinerid võivad olla ohutud? Tuletame meelde, et arengute, testimise ja kasutuselemise protsesside integreerimise konverents toimub Moskvas 30. septembril ja 1. oktoobril. Kuni 20. augustini on veel võimalik esituda ettekanne ja jagada oma kogemusi ühe paljude DevOps lähenemise probleemide lahendamisega.

Konverentsi ja uudiste jälgimiseks liitu uudiskirjaga ja telegrami kanaliga.

Allikas: habr.com