Helmi turvalisus

Looja rääkimine Kubernetes'i kõige populaarsemast paketihaldurist võiks kokku võtta emodži kaudu:

• karp — see on Helm (see on kõige sobivam, mis on viimases emodžide väljaandes);
• lukk — turvalisus;
• inimene — probleemi lahendus.

Tegelikult on kõik natuke keerulisem ja jutt on täis tehnilisi üksikasju, kuidas teha Helm turvaliseks.

• Lühidalt öeldes, mis on Helm, kui te ei teadnud või olete unustanud. Milliseid probleeme ta lahendab ja kus ta ekosüsteemis asub.
• Vaatame Helm'i arhitektuuri. Ükski arutelu turvalisuse üle ja selle üle, kuidas muuta tööriist või lahendus turvalisemaks, ei saa toimumata olla komponente arusaamisest.
• Räägime Helm'i komponentidest.
• Kõige põletavam küsimus — tulevik — uus versioon Helm 3. 

Kõik, mis antud artiklis on, kehtib Helm 2 kohta. See versioon on praegu tootmises ja tõenäoliselt kasutasite just seda, milles on turvaprobleemid.

Esinejast: Aleksandr Khajurov (allexx) on töötanud arendajana 10 aastat ja aitab sisu parandada Moscow Python Conf++ ja liitus komiteega Helm Summit. Praegu töötab Chainstackis arenduse juhtimise positsioonil — see on hübriid arendusjuhi ja isiku vahel, kes vastutab lõppversioonide tarnimise eest. See tähendab, et ta on seal, kus toimub kõik alates toote loomise kuni selle kasutuselevõtmiseni.

Chainstack on väike, aktiivselt kasvav start-up, mille eesmärk on anda klientidele võimalus unustada infrastruktuuri ja jaotatud rakenduste haldamise keerukused, arendustiim asub Singapuris. Ärge paluge Chainstackil müüa või osta krüptovaluutat, vaid pakkuge rääkida ettevõtte plokiahela raamistike üle, ja teile vastatakse rõõmuga.

Helm

See on paketihaldur (chartide) jaoks Kubernetesile. Kõige arusaadavam ja universaalsem viis rakenduste toomiseks Kubernetes'i klastrisse.

Räägime muidugi struktureeritud ja tööstuslikumast lähenemisviisist, mitte oma YAML-manifestide koostamisest ja väikeste utiliidide kirjutamisest.

Helm on parim, mis praegu saadaval ja populaarne on.

Miks Helm? Esiteks, sest seda toetab CNCF. Cloud Native on suur organisatsioon, mis on ematäidise ettevõtteks Kubernetes'i, etcd, Fluentd ja teiste projektide jaoks.

Teine oluline fakt on see, et Helm on väga populaarne projekt. Kui ma jaanuaris 2019 hakkasin mõtlema, kuidas teha Helmi turvaliseks, oli projektil GitHubis tuhandeid tähti. Mais oli neid juba 12 tuhat.

Paljud inimesed on huvitatud Helmist, seega, isegi kui te ei kasuta seda veel, on teadmised selle turvalisuse kohta kasulikud. Turvalisus on oluline.

Helmi põhi meeskonda toetab Microsoft Azure, mistõttu on see projekt suhteliselt stabiilne võrreldes paljude teistega. Helm 3 Alpha 2 väljalase juuli keskpaiku tõendab, et projektiga tegeleb piisavalt palju inimesi, kellel on soov ja jõud Helmi arendamiseks.

Helm lahendab mitmeid põhiküsimusi rakenduste haldamises Kuberneteses.

• Rakenduse pakendamine. I isegi selline rakendus nagu 'Tere, maailm' WordPressis koosneb mitmest teenusest, mida soovitakse koos pakendada.
• Halduse keerukus, mis tekib nende rakenduste haldamise käigus.
• Rakenduse elutsükkel, mis ei lõpe pärast rakenduse installimist või juurutamist. See elab edasi, seda tuleb värskendada, ja Helm aitab selleks tagada õigeid meetmeid ja poliitikaid.

Pakendamine on korraldatud arusaadaval viisil: olemas on metaandmed, mis vastavad tavaliste paketihaldurite tööle Linuxis, Windowsis või MacOS-is. See tähendab hoidlat, sõltuvusi erinevatest paketidest, rakenduste metaandmeid, seadeid, konfigureerimise eripärasid, teabe indekseerimist jne. Kõike seda võimaldab Helm rakenduste jaoks hankida ja kasutada.

Keerukuse haldamine. Kui teil on palju sarnaseid rakendusi, siis on vajalik parametriseerimine. Sellest tulenevad mallid, kuid et mitte välja mõelda oma viisi mallide loomiseks, saab kasutada seda, mida Helm pakkuda on.

Rakenduse elutsükli juhtimine — minu arvates on see kõige huvitavam ja lahendamata küsimus. Just sellepärast tulin ma kunagi Helmi juurde. Me pidime jälgima rakenduse elutsüklit, soovisime oma CI/CD ja rakenduste tsüklid viia sellesse paradigma.

Helm võimaldab:

• halda juurutusi, tutvustab konfiguratsiooni ja ülevaate mõistet;
• edukalt teostada uuendusi;
• kasutada konksusid erinevatel üritustel;
• lisada rakenduste täiendavaid kontrolle ja reageerida nende tulemustele.

Lisaks Helmil on "aku" — suur hulk maitsvaid asju, mida saab pluginatena lisada, et oma elu lihtsustada. Pluginaid saab kirjutada iseseisvalt, need on piisavalt isoleeritud ja ei vaja keerukat arhitektuuri. Kui soovite midagi rakendada, soovitan teil teha seda plugina vormis ja seejärel võimalusel lisada upstream'i.

Helm põhineb kolmel peamisel kontseptsioonil:

• Chart Repo — kirjeldus ja parameetrite massiiv, mis on teie manifesti jaoks võimalikud. 
• Konfiguratsioon — see tähendab väärtusi, mis rakendatakse (tekst, numbrilised väärtused jne).
• Release koondab kaks ülemist komponenti ning koos nad muutuvad Release'iks. Versioonid on hallatavad, saavutades seeläbi elutsükli korraldamise: väike installimise hetkel ja suur tõstmisel, alandamisel või tagasi pööramisel.

Helm'i arhitektuur

Diagrammil on kontseptuaalselt kujutatud Helm'i kõrgetasemeline arhitektuur.

Tuletan meelde, et Helm on seotud Kubernetesega. Seetõttu ei saa me ilma Kubernetes'i klastri (ristkülik) olema. Kube-apiserver komponent asub masteris. Ilma Helmi on meil Kubeconfig. Helm toob kaasa ühe väikese binaari, kui seda nii nimetada, Helm CLI utiliidi, mis paigaldatakse arvutisse, sülearvutisse, peamenüüsse — kõikjale.

Aga sellest ei piisa. Helmil on serveri komponent Tiller. See esindab Helmi huve klastri sees, see on sama rakendus Kubernetes'i klastri sees nagu iga teine.

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

Koostöö

Vaadake, kuidas arhitektuuri komponendid omavahel suhtlevad, kui soovime rakendust Helm'i abil installida.

• Öeldes Helm install, pöördume hoidla (Chart Repo) poole ja saame Helm chart'i.

• Helm utiliit (Helm CLI) suhtleb Kubeconfig'iga, et välja selgitada, millise klastri poole pöörduda. 
• Saades selle teabe, pöördub utiliit Tilleri poole, mis asub meie klastris, kui rakendus. 
• Tiller pöördub Kube-apiserver'i poole, et teostada toiminguid Kubernetes'es, luua objekte (teenuseid, pod'e, replikasid, salajaid jne).

Edasi keerame skeemi keerukamaks, et näha ründevektorit, millega kogu Helm'i arhitektuur kokku puutuda võib. Seejärel proovime seda kaitsta.

Ründevektor

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

Madala privileegiga API-kasutaja võib samuti osutuda ohtlikuks, kui ta on kuskil lähedal. Sellisel kasutajal on kontekst teine, näiteks võib ta olla fikseeritud ühe klastrisse kuuluva nimede ruumikonfiguratsioonis Kubeconfig.

Huvitavaim rünnakusuund võib olla protsess, mis asub klastris kuskil lähedal Tiller'ile ja saab sellele juurde pääseda. See võib olla veebiserver või mikroteenus, mis näeb klastris mitmerealisi võrguümbrust.

Eksootiline, kuid üha populaarsust koguv rünnakusuund on seotud Chart Repo'ga. Petlik autor võib luua charti, mis sisaldab ebaturvalist ressurssi, ja sa käivitad selle, uskudes seda. Või ta võib asendada charti, mida sa allalaadid ametlikust repost, ning näiteks luua ressursi poliitikate kujul ja saavutada juurdepääsu suurendamine.

Proovime kaitsta end rünnakute eest kõigist neljast suunast ja mõista, kus on probleemid Helm'i arhitektuuris, ja kus neid võivad mitte olla.

Suurendame skeemi, lisades rohkem elemente, kuid säilitame kõik põhikomponendid.

Helm CLI suhtleb Chart Repo'ga, suhtles Kubeconfig'iga, töö edastatakse klastrisse komponendile Tiller.

Tiller on esitatud kahe objektiga:

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

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

• Mehhanism, mille abil Helm CLI pöördub chart repo poole: milline protokoll, kas on autentimine ja mida sellega teha.
• Protokoll, mille abil Helm CLI, kasutades kubectl'i, suhtleb Tiller'iga. See on RPC-server, mis on paigaldatud klastrisse.
• Ise Tiller on kergesti kättesaadav klastris asuvatele mikroteenustele ja suhtleb Kube-apiserveriga.

Arutame järjestikku kõiki neid suundi.

RBAC

On mõttetu rääkida mingi turvalisuse olemasolust Helm'i või mõne teise teenuse osas klastris, kui RBAC ei ole sisselülitatud.

Tundub, et see ei ole kõige värskem soovitus, kuid olen kindel, et paljud ei ole RBAC-d isegi tootmises sisselülitanud, sest see on suur häda ja vajab palju seadistamist. Sellegipoolest kutsun üles seda tegema.

https://rbac.dev/ — advokaadi veebisait RBAC-ile. Seal on kogutud hulk huvitavaid materjale, mis aitavad RBAC-i seadistamisel, näitavad, miks see on hea ja kuidas sellega üldiselt tootmises elada.

Proovin selgitada, kuidas Tiller ja RBAC toimivad. Tiller töötab klastris teatud teenusekonto all. Reeglina, kui RBAC ei ole seadistatud, on see superkasutaja. Baaskonfiguratsioonis on Tiller administraator. Just seetõttu öeldakse tihti, et Tiller on SSH-tunnel teie klastrisse. Tegelikult on see tõsi, seega saab kasutada eraldi spetsialiseeritud teenusekontot, mitte Default Service Account'i ülaltoodud skeemis.

Kui te esmakordselt Helm'i seadistate ja installite selle serverisse, saate määrata teenusekonto abil --service-account. See võimaldab kasutada kasutajat, kellel on minimaalne vajalike õiguste kogum. Kahjuks peate looma sellise "süsteemi": Role ja RoleBinding.

Kahjuks ei tee Helm seda teie eest. Teie või teie Kubernetes-kliendi administraator peab ette valmistama Role'i ja RoleBinding'i kogumi teenusekonto jaoks, et edastada selle Helm'ile.

Küsimus tekib — mis on erinevus Role'i ja ClusterRole'i vahel? Erinevus seisneb selles, et ClusterRole kehtib kõigi nimespetsiifiliste, erinevalt tavalisest Role'ist ja RoleBinding'ist, mis töötab ainult konkreetses nimespetsiifilises. Poliitika saab seadistada nii kogu klastrile kui ka personaliseeritult iga nimespetsiifilise jaoks eraldi.

Oluline on mainida, et RBAC lahendab veel ühe suure probleemi. Paljud kurdavad, et Helm ei ole kahjuks multitenantsuse tugi (ei toeta mitme üürniku olemasolu). Kui mitu meeskonda kasutavad klastrit ja kasutavad Helmi, on põhimõtteliselt võimatu seadistada poliitikaid ja piirata nende juurdepääsu selles klastris, kuna on olemas teatud teenusekonto, mille alt Tiller töötab ja loovad tema alt kõik ressursid klastris, mis on aeg-ajalt väga ebamugav. See on tõsi — nagu binaarfail, nii ka protsess, Helm Tiller ei mõista multitenantsust..

Siiski on suurepärane viis, kuidas Tillerit klastris mitu korda käivitada. Sellega pole mingeid probleme, Tillerit saab käivitada igas nimespetsiifilises. Seega võite kasutada RBAC-d ja Kubeconfig'i kontekstina, et piirata juurdepääsu spetsiaalsele Helm'ile.

See näeb välja järgmiselt.

Näiteks on kaks Kubeconfig'i konteksti erinevatele meeskondadele (kaks nimiruumi): X meeskond arendajatele ja administraatori klaster. Administraatoriklastril on laiem Tiller, mis asub Kube-system nimiruumi, seega edasijõudnud teenusekonto. Ja eraldi nimiruum arendajameeskonnale, kes saavad oma teenuseid spetsiaalsetesse nimiruumi juurutada.

See on toimiv lähenemine, Tiller ei ole nii ressursimahukas, et see võiks teie eelarvet oluliselt mõjutada. See on üks kiireid lahendusi.

Ärge kartke seadistada Tiller eraldi ja anda Kubeconfig konteksti meeskonna jaoks, konkreetse arendaja jaoks või keskkonna jaoks: Dev, Staging, Production (kahtlane, et kõik oleks ühes klastris, kuid see on võimalik).

Jätkates meie lugu, liigume RBAC'i juurest edasi ja räägime ConfigMap'idest.

ConfigMaps

Helm kasutab ConfigMap'e andmete salvestamiseks. Kui me rääkisime arhitektuurist, siis seal ei olnud ühtegi andmebaasi, kuhu oleks talletatud teavet väljalaskude, konfiguratsioonide, tagasiviikude jne kohta. Selleks kasutatakse ConfigMap'e.

ConfigMap'idega on tuntud probleem – need ei ole põhimõtteliselt turvalised, need ei võimalda salajaste andmete salvestamist. Räägime kõigest, mis ei peaks liikuma kaugemale teenusest, näiteks paroolid. Praegu on kõige loomulikum viis Helm jaoks ConfigMap'ide kasutamise asemel liikuda saladuste suunas.

Seda on väga lihtne teha. Üksite Tilleri seade ja näitate, et salvestuseks on saladused. Siis saate iga juurutuse jaoks mitte ConfigMap'i, vaid saladuse.

Võite väita, et saladused endiselt – kummaline kontseptsioon ja see ei ole väga turvaline. Siiski tuleks mõista, et sellega tegelevad ise Kubernetes'i arendajad. Alates versioonist 1.10, st juba piisavalt pikka aega, on vähemalt avalikes pilvedes võimalik liita õige salvestus saladuste hoidmiseks. Praegu töötab meeskond selle nimel, et veelgi paremini jagada juurdepääsu saladustele, eraldi podidele või teistele üksustele.

Salvestuse Helm on parem üle viia saladustele ja need omakorda keskses kohas turvata.

Kuid kindlasti jääb andmete salvestamise limiit 1 MB. Helm kasutab siin etcd-d jaotatud salvestusruumina ConfigMap-ide jaoks. Seal arvati, et see on sobiv andmeplokk replikatsioonideks jne. Sellel teemal on huvitav arutelu Redditis, soovitan leida see põnev lugemine nädalavahetuseks või lugeda kokkuvõtet. siit.

Chart Repos

Chart'ide osas on sotsiaalne haavatavus kõrge ja need võivad saada 'Man in the middle' rünnakute allikaks, eriti kui kasutatakse vaikimisi lahendust. Eelkõige räägime repositooriumidest, mis on väljas HTTP kaudu.

Kindlasti tuleks Helm Repo avaldada HTTPS-i kaudu — see on parim variant ja ei maksa palju.

Pange tähele chart'ide allkirjastamise mehhanism. Tehnoloogia on hämmastavalt lihtne. See on sama, millega tegelete GitHubis, tavaline PGP-masina süsteem, kus on avalikud ja privaatsed võtmed. Seadistage see ja olge kindel, omades vajalikke võtmeid ja allkirjastades kõike, mis on tõesti teie chart.

Lisaks, Helm klient toetab TLS-i (mitte serveri HTTP mõttes, vaid vastastikune TLS). Saate kasutada serveri ja kliendi võtmeid suhtlemiseks. Ausalt öeldes, ma ei kasuta sellist mehhanismi, kuna ma ei armasta vastastikuseid sertifikaate. Üldiselt. chartmuseum — peamine tööriist Helm Repo avaldamiseks Helm 2 jaoks — toetab ka basic auth'i. Basic auth'i saab kasutada, kui see on mugavam ja kindlam.

Veel on olemas plugin helm-gcs, mis võimaldab Chart Reposid paigutada Google Cloud Storage'i. See on üsna mugav, töötab suurepäraselt ja on piisavalt turvaline, kuna kasutatakse kõiki eeltoodud mehhanisme.

Kui aktiveerida HTTPS või TLS, kasutada mTLS-i, aktiveerida basic auth'i, et veelgi riske vähendada, saab luua turvalise suhtluse Helm CLI ja Chart Repo vahel.

gRPC API

Järgmine samm on väga vastutustundlik — Tilleri turvamine, mis asub klastris ja on ühelt poolt server, teiselt poolt pöördub ta teiste komponentide poole ning üritab esitada end kellegi teise näol.

Kuidas ma juba ütlesin, Tiller on teenus, mis pakub gRPC-d, Helm klient pöördub tema poole gRPC kaudu. Vaikimisi, loomulikult, on TLS välja lülitatud. Miks see on nii — on arutelu küsimus, mulle tundub, et see on algse seadistamise lihtsustamiseks.

Soovitan aktiveerida TLS gRPC jaoks tootmis- ja isegi staging keskkondades.

Minu arvates, erinevalt mTLS-ist chartide jaoks, on siin see asjakohane ja väga lihtne — genereerite PQI infrastruktuuri, loote sertifikaadi, käivitate Tilleri ja edastate sertifikaadi initsialiseerimise ajal. Pärast seda saate sooritada kõiki Helm-komande, esitledes genereeritud sertifikaadi ja privaatvõtmega.

Sel moel kaitsete end kõikide Tilleri välisklastri päringute eest.

Nii oleme kaitsnud ühenduste kanalit Tilleriga, arutanud RBAC-i ja reguleerinud Kubernetes apiserveri õigusi, vähendanud domeeni, millega see saab suhelda.

Kaitstud Helm

Vaadakem lõppscheemi. See on sama arhitektuur samade nooled.

Kõik ühendused võib nüüd julgelt joonistada roheliseks:

• Chart Repo puhul kasutame TLS-i või mTLS-i ja põhivolitusi;
• mTLS Tilleri jaoks, ja see on seatud gRPC-teenusena TLS-iga, kasutame sertifikaate;
• klastris kasutatakse spetsiaalset teenusekontot koos Rooli ja Rooli seondumisega. 

Oleme oluliselt kaitsnud klastrit, kuid keegi nutikas ütles:

"Absoluutselt turvaline lahendus võib olla ainult üks — välja lülitatud arvuti, mis asub betoonkastis ja mille ümber valvavad sõdurid."

On erinevaid viise andmete manipuleerimiseks ja uute rünnakute suundade leidmiseks. Siiski olen kindel, et need soovitused võimaldavad rakendada põhieeskirjade industriaalset turvastandardit.

Boonus

See osa ei ole otseselt seotud turvalisusega, kuid on samuti kasulik. Näitan mõningaid huvitavaid asju, millest vähesed teavad. Näiteks, kuidas otsida chart'e — ametlikke ja mitte ametlikke.

Repositooriumis github.com/helm/charts praegu on umbes 300 charti ja kaks voogu: stable ja incubator. Need, kes panustavad, teavad hästi, kui raske on incubatorist stable'isse pääseda ja kui lihtne on stable'ist välja kukkuda. Siiski, see ei ole parim tööriist Prometheuse ja kõike, mis teile meeldib, chartide otsimiseks ühest lihtsast põhjusest — see ei ole portaal, kus on mugav pakette otsida.

Kuid on teenus hub.helm.sh, millega chartide leidmine on palju mugavam. Kõige tähtsam on, et seal on palju rohkem väliseid reposeid ja saadaval on peaaegu 800 charti. Pluss, saate lisada oma repoe, kui mingil põhjusel ei soovi oma chart'e stable'isse saata.

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

Soovin veel tähelepanu pöörata Open Service Broker API integreerimine. See kõlab köitvalt ja arusaamatult, kuid lahendab probleeme, millega kõik kokku puutuvad. Selgitan seda lihtsa näite kaudu.

On olemas Kubernetesi klaster, kus soovime käivitada klassikalist rakendust - WordPressi. Tüüpiliselt on selleks, et kõik funktsioonid toimiksid, vajalik andmebaas. On palju erinevaid lahendusi, näiteks võime käivitada oma statefull-teenuse. See pole väga mugav, kuid paljud teevad just nii.

Teised, näiteks meie Chainstack'is, kasutavad hallatavaid andmebaase, nagu MySQL või PostgreSQL, serverite jaoks. Seetõttu on meil andmebaas kuskil pilves.

Aga tekib probleem: peame ühendama meie teenuse andmebaasiga, looma andmebaasile flavor'i, edastama credential'id ja neid haldama. Kõik see toimub tavaliselt käsitsi süsteemiadministraatori või arendaja poolt. Ja pole mingeid probleeme, kui rakendusi on vähe. Kui neid on palju, on vajalik kombain. Selline kombain on olemas - see on Service Broker. See võimaldab kasutada spetsiaalset pluginit avaliku pilve klastri jaoks ja tellida teenuseid pakkujalt läbi Brokeri, justkui oleks see API. Selleks saab kasutada Kubernetes'i natiivseid tööriistu.

See on väga lihtne. Saate taotleda näiteks Azure'is hallatud MySQL-i algtasemel (seda saab konfigureerida). Azure'i API kasutades luuakse andmebaas, mis on kasutamiseks ette valmistatud. Te ei pea sellesse sekkuma, selle eest vastutab plugin. Näiteks OSBA (Azure'i plugin) annab credential'id teenusele, edastab need Helmile. Te saate kasutada WordPressi pilve MySQL-iga, ega pea muretsema hallatud andmebaaside või statefull-teenuste pärast.

Võib öelda, et Helm on liim, mis ühelt poolt võimaldab teenuste paigaldamist ja teiselt poolt - pilvepakkujate ressursside tarbimist.

Saate kirjutada oma plugina ja kasutada kogu seda lugu on-premise. Siis on teil lihtsalt oma plugin ettevõtte Cloud-pakkujale. Soovitan sellist lähenemist proovida, eriti kui teil on suur ulatus ja soovite kiiresti alustada dev-, staging- või kogu infrastruktuuri feature'i jaoks. See lihtsustab teie operations või DevOps'i elu.

Veel üks leid, mida juba mainisin - see on helm-gcs plugin, mis võimaldab kasutada Google'i bucket'e (objektide salvestusruum) Helm chartide salvestamiseks.

Selle kasutuselevõtmiseks on vaja vaid nelja käsku:

1. installida plugin;
2. alustada selle kasutamist;
3. määra tee bucket'ile, mis asub gcp-s;
4. avalda chart'id tavalisel viisil.

Ilus on see, et autoriseerimiseks kasutatakse gcp originaalset viisi. Sa võid kasutada teenusekonto, arendaja kontot – kõike, mis tahad. See on väga mugav ja ei maksa midagi kasutamisel. Kui sa, nagu mina, propageerid opsless-filosoofiat, siis on see eriti mugav, eriti väikeste meeskondade jaoks.

Alternatiivid

Helm ei ole ainus lahendus teenuste haldamiseks. Selle kohta on palju küsimusi, ilmselt seetõttu tuli ka kiiresti välja kolmas versioon. Loomulikult on alternatiive.

Need võivad olla nii spetsialiseeritud lahendused, näiteks Ksonnet või Metaparticle. Sa võid kasutada oma klassikalisi infrastruktuuri haldamise tööriistu (Ansible, Terraform, Chef jne) samade eesmärkide jaoks, millest ma rääkisin.

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

Operator Framework on peamine alternatiiv Helm'ile, millele tasub tähelepanu pöörata.

See on rohkem natiivne CNCF ja Kubernetes'i jaoks, aga sissepääsutase on oluliselt kõrgem, tuleb rohkem programmeerida ja vähem manifestide kirjeldada.

On erinevaid lisandeid, nagu Draft, Scaffold. Need muudavad elu palju lihtsamaks, näiteks arendajate jaoks lihtsustavad nad Helm'i saatmise ja käivitamise tsüklit testkeskkonna deploimiseks. Ma nimetaksin neid võimaluste laienditeks.

Siin on selge joonis, mis näitab, kus mis asub.

Rikkus teljel on sinu isiklik kontroll toimuvate üle, ordinaatide teljel – Kubernetes'e natiivsus. Helm versioon 2 asub kuskil keskel. Versioonis 3 ei ole tohutult muutunud, kuid kontroll ja natiivsus on paranenud. Ksonneti taseme lahendused jäävad isegi Helmi 2-st maha. Siiski tasub neile pilk heita, et näha, mis veel selles maailmas olemas on. Loomulikult on sinu konfigureerimise haldur sul kontrolli all, kuid see ei ole absoluutselt natiivne Kubernetes'i jaoks.

Operator Framework on täiesti natiivne Kubernetes'i jaoks ja võimaldab sellega hallata palju elegantsimalt ja hoolikamalt (kuid pidage meeles sissepääsutaset). Pigem sobib see spetsialiseeritud rakendusele ja selle haldamise loomisele, kui tohutule rakenduste paketile Helm'i abil.

Laiendajad lihtsalt parandavad veidi kontrolli, täiustavad töövoogu või kärbivad CI/CD torude nurki.

Helm'i tulevik

Hea uudis on see, et Helm 3 on tulemas. On vabastatud Helm 3.0.0-alpha.2 alpha versioon, mida saate proovida. See on piisavalt stabiilne, kuid funktsionaalsus on hetkel piiratud.

Miks on Helm 3 vajalik? Esiteks on see lugu Tilleri kadumisest, nagu osa. See, nagu te juba mõistate, on tohutu edasiminek, kuna arhitektuuri turvalisuse seisukohalt lihtsustab see kõike.

Kui Helm 2 loodi, mis toimus Kubernetes 1.8 ajal või isegi varem, siis paljud kontseptsioonid polnud veel küpsed. Näiteks on CRD kontseptsioon praegu aktiivselt kasutusele võetud ja Helm kavatseb kasutada CRD-d, et salvestada struktuure. Saate kasutada ainult klienti ja mitte pidada serveri osa. Seega on võimalik kasutada native Kubernetes käske struktuuride ja ressursside haldamiseks. See on tohutu edasiminek.

Tuleb toetamine natiivsetele OCI hoidlatele (Open Container Initiative). See on tohutu algatus ja Helm on sellele huvitav peamiselt oma chartide deploimiseks. Asi on isegi selles, et näiteks Docker Hub toetab paljusid OCI standardeid. Ma ei ennusta, kuid on võimalik, et klassikalised Docker hoidlate pakkujad hakkavad võimaldama teil oma Helm chartide majutamist.

Sellel on kahtlane tähendus — Lua toetamine, nagu templating engine skriptide kirjutamiseks. Ma ei ole suur Lua fänn, kuid see on täiesti valikuline võimalus. Olen seda 3 korda kontrollinud — Lua kasutamine ei ole kohustuslik. Seega, kes tahab, saab kasutada Lua-d, kellele meeldib Go — liituge meie suure laagri ja kasutage go-tmpl selle jaoks.

Lõ finally lõpuks, mida ma kindlasti igatsesin — on skeemi ja andmetüüpide valideerimise kehtestamine. Ei tule rohkem probleeme int või string-iga, ei pea enam nulli topelt jutumärkidesse panema. Ilmub JSONS skeem, mis võimaldab seda väärtuste jaoks selgelt kirjeldada.

Kavandatakse tõsiseid muudatusi event-driven mudelis. See on juba kontseptuaalselt kirja pandud. Vaadake Helm 3 haru ja näete, kui palju sündmusi, hook'e ja muud, mis oluliselt lihtsustavad ja teiselt poolt lisavad kontrolli deploy protsesside ja nende reaktsioonide üle.

Helm 3 on lihtsam, turvalisem ja huvitavam mitte sellepärast, et me ei armasta Helm 2, vaid seetõttu, et Kubernetes muutub arenenumaks. Seega võib Helm kasutada Kubernetes'i arendusi ja luua selle põhjal suurepäraseid Kubernetes'i haldurid.

Veel head uudiseid on selles, et DevOpsConf Aleksandr Khayorov räägib, kas konteinerid võivad olla turvalised? Tuletame meelde, et arenduse, testimise ja tööprotsesside integreerimise konverents toimub Moskvas 30. septembril ja 1. oktoobril. Kuni 20. augustini on veel võimalik esitama ettekannet ja jagada oma kogemust probleemide lahendamisel ühest paljusid DevOps lähenemise ülesannetest.

Konverentsi ja uudiste jälgimiseks vaadake the newsletter ja telegrami kanalist.

Allikas: habr.com