Kubernetese populaarseima paketihalduri loo olemust saab kujutada emotikonide abil:
- kast on Helm (mis on uusimale Emoji väljalasele kõige lähemal);
- lukk - turvalisus;
- väike mees on probleemi lahendus.
Tegelikult on kõik veidi keerulisem ja lugu on täis tehnilisi üksikasju Kuidas muuta Helm ohutuks.
- Lühidalt, mis Helm on juhuks, kui te ei teadnud või unustasite. Milliseid probleeme see lahendab ja kus see ökosüsteemis asub.
- Vaatame Helmi arhitektuuri. Ükski vestlus turvalisusest ja tööriista või lahenduse turvalisemaks muutmisest ei ole täielik ilma komponendi arhitektuuri mõistmata.
- Arutleme Helmi komponentide üle.
- Kõige põletavam küsimus on tulevik – Helm 3 uus versioon.
Kõik selles artiklis käsitletav kehtib Helm 2 kohta. See versioon on praegu tootmises ja tõenäoliselt see, mida praegu kasutate, ning see versioon sisaldab turvariske.
Kõlari kohta: Aleksander Khajorov () on arenenud 10 aastat, aidates sisu täiustada ja astus komiteesse . Nüüd töötab ta Chainstackis arendusjuhina – see on hübriid arendusjuhi ja lõplike väljaannete tarnimise eest vastutava inimese vahel. See tähendab, et see asub lahinguväljal, kus toimub kõik alates toote loomisest kuni selle toimimiseni.
Chainstack on väike, aktiivselt kasvav startup, mille missiooniks on võimaldada klientidel unustada detsentraliseeritud rakenduste käitamise infrastruktuur ja keerukus; arendusmeeskond asub Singapuris. Ärge paluge Chainstackil krüptovaluutat müüa ega osta, vaid pakuge, et räägite ettevõtte plokiahela raamistikest ja nad vastavad teile hea meelega.
Rooliratas
See on Kubernetese paketi (diagrammi) haldur. Kõige intuitiivsem ja universaalsem viis rakenduste Kubernetese klastris viimiseks.
Me räägime loomulikult struktuursemast ja tööstuslikumast lähenemisest kui oma YAML-i manifestide loomine ja väikeste utiliitide kirjutamine.
Helm on parim, mis praegu saadaval on ja populaarne.
Miks Helm? Peamiselt seetõttu, et seda toetab CNCF. Cloud Native on suur organisatsioon ja on projektide Kubernetes, etcd, Fluentd ja teiste emaettevõte.
Teine oluline fakt on see, et Helm on väga populaarne projekt. Kui hakkasin 2019. aasta jaanuaris rääkima Helmi turvaliseks muutmisest, oli projektil GitHubis tuhat tärni. Maikuuks oli neid 12 tuhat.
Paljud inimesed on Helmist huvitatud, nii et isegi kui te seda veel ei kasuta, saate selle turvalisusest teada. Ohutus on oluline.
Helmi põhimeeskonda toetab Microsoft Azure ja seetõttu on see erinevalt paljudest teistest üsna stabiilne projekt. Helm 3 Alpha 2 ilmumine juuli keskel viitab sellele, et projekti kallal töötab päris palju inimesi ning neil on tahtmist ja energiat Helmi arendada ja täiustada.
Helm lahendab Kubernetesis mitmeid rakenduste haldamise põhiprobleeme.
- Rakenduse pakend. Isegi WordPressi rakendus nagu “Tere, maailm” koosneb juba mitmest teenusest ja soovite need kokku pakkida.
- Nende rakenduste haldamisega kaasneva keerukuse haldamine.
- Elutsükkel, mis ei lõpe pärast rakenduse installimist või juurutamist. See elab edasi, seda tuleb värskendada ja Helm aitab selles ning püüab tuua selle jaoks õigeid meetmeid ja poliitikat.
Kotti pakkimine see on korraldatud selgelt: metaandmed on täielikult kooskõlas Linuxi, Windowsi või MacOS-i tavalise paketihalduri tööga. See tähendab hoidla, sõltuvused erinevatest pakettidest, rakenduste metateave, sätted, konfiguratsioonifunktsioonid, teabe indekseerimine jne. Helm võimaldab teil seda kõike rakenduste jaoks hankida ja kasutada.
Keerukuse juhtimine. Kui teil on palju sama tüüpi rakendusi, on vaja parameetrite määramist. Mallid pärinevad sellest, kuid selleks, et vältida mallide loomiseks oma viisi, saate kasutada seda, mida Helm juba karbist välja pakub.
Rakenduse elutsükli haldamine - minu arvates on see kõige huvitavam ja lahendamata küsimus. See on põhjus, miks ma tol päeval Helmi juurde tulin. Me pidime rakenduse elutsüklil silma peal hoidma ja tahtsime oma CI/CD ja rakendustsüklid sellesse paradigmasse üle viia.
Helm võimaldab teil:
- juurutuste haldamine, tutvustab konfiguratsiooni ja läbivaatamise mõistet;
- tagasipööramine edukalt läbi viia;
- kasutada konkse erinevatel üritustel;
- lisage täiendavaid rakenduste kontrolle ja reageerige nende tulemustele.
Pealegi Helmil on "patareid" - tohutul hulgal maitsvaid asju, mida saab lisada pistikprogrammide kujul, mis lihtsustab teie elu. Pluginaid saab kirjutada iseseisvalt, need on üsna isoleeritud ega vaja harmoonilist arhitektuuri. Kui soovite midagi juurutada, soovitan seda teha pistikprogrammina ja seejärel lisada see ülesvoolu.
Helm põhineb kolmel põhikontseptsioonil:
- Graafik Repo — manifesti jaoks võimalike parameetrite kirjeldus ja hulk.
- config — ehk rakendatavad väärtused (tekst, arvväärtused jne).
- Vabastage kogub kaks ülemist komponenti ja koos muutuvad need vabastamiseks. Väljalaseid saab versioonida, saavutades seeläbi organiseeritud elutsükli: väikesed installimise ajal ja suured uuendamise, alandamise või tagasipööramise ajal.
Helmi arhitektuur
Diagramm kujutab kontseptuaalselt Helmi kõrgetasemelist arhitektuuri.
Tuletan meelde, et Helm on midagi Kubernetesega seotud. Seetõttu ei saa me ilma Kubernetese klastrita (ristkülikuta). Kube-apiserveri komponent asub ülemseadmel. Ilma Helmita on meil Kubeconfig. Helm toob ühe väikese kahendfaili, kui seda nii võib nimetada, Helm CLI utiliidi, mis installitakse arvutisse, sülearvutisse, suurarvutisse – ükskõik mille peale.
Kuid sellest ei piisa. Helmil on serverikomponent nimega Tiller. See esindab Helmi huve klastris; see on Kubernetese klastri rakendus, nagu iga teinegi.
Chart Repo järgmine komponent on diagrammidega hoidla. On olemas ametlik hoidla ja võib olla ka ettevõtte või projekti privaatne hoidla.
Koostoime
Vaatame, kuidas arhitektuurikomponendid suhtlevad, kui tahame Helmi abil rakendust installida.
- Me räägime
Helm install, avage hoidla (Chart Repo) ja hankige Helmi diagramm.
- Helmi utiliit (Helm CLI) suhtleb Kubeconfigiga, et välja selgitada, millise klastriga ühendust võtta.
- Pärast selle teabe saamist viitab utiliit rakendusena meie klastris asuvale Tillerile.
- Tiller kutsub Kube-apiserverit Kubernetesis toimingute tegemiseks, mõne objekti (teenused, kaunad, koopiad, saladused jne) loomiseks.
Järgmisena muudame diagrammi keerulisemaks, et näha ründevektorit, millega kogu Helmi arhitektuur tervikuna kokku puutuda saab. Ja siis püüame teda kaitsta.
Rünnaku vektor
Esimene potentsiaalne nõrk koht on privilegeeritud API-kasutaja. Skeemi osana on see häkker, kes on saanud administraatori juurdepääsu Helmi CLI-le.
Privilegeeritud API kasutaja võib ka ohtu kujutada, kui see on kuskil läheduses. Sellisel kasutajal on erinev kontekst, näiteks saab ta Kubeconfigi seadetes fikseerida ühes klastri nimeruumis.
Kõige huvitavam ründevektor võib olla protsess, mis asub kuskil Tilleri lähedal asuvas klastris ja pääseb sellele juurde. See võib olla veebiserver või mikroteenus, mis näeb klastri võrgukeskkonda.
Eksootiline, kuid üha populaarsemaks muutuv ründevariant hõlmab Chart Repo. Korramatu autori koostatud diagramm võib sisaldada ohtlikke ressursse ja te täidate selle, kui kasutate seda uskudes. Või võib see asendada diagrammi, mille laadite alla ametlikust hoidlast, ja näiteks luua ressursi poliitikate kujul ja suurendada selle juurdepääsu.
Proovime tõrjuda rünnakuid kõigilt neilt neljalt poolt ja aru saada, kus on Helmi arhitektuuris probleeme ja kus võib-olla mitte.
Suurendame diagrammi, lisame rohkem elemente, kuid säilitame kõik põhikomponendid.
Helmi CLI suhtleb Chart Repoga, suhtleb Kubeconfigiga ja töö kantakse klastrisse Tilleri komponenti.
Tillerit esindab kaks objekti:
- Tiller-deploy svc, mis paljastab teatud teenuse;
- Tiller-deploy pod (diagrammil ühes eksemplaris ühes koopias), millel töötab kogu koormus, mis pääseb juurde klastrile.
Interaktsiooniks kasutatakse erinevaid protokolle ja skeeme. Turvalisuse seisukohast huvitab meid enim:
- Mehhanism, mille abil Helmi CLI pääseb ligi diagrammi repole: milline protokoll, kas autentimine on olemas ja mida sellega teha saab.
- Protokoll, mille abil Helm CLI kubectli kasutades suhtleb Tilleriga. See on klastri sisse installitud RPC-server.
- Tiller ise on juurdepääsetav mikroteenustele, mis asuvad klastris ja suhtlevad Kube-apiserveriga.
Arutame kõiki neid valdkondi järjekorras.
RBAC
Helmi või mõne muu klastri teenuse turvalisusest pole mõtet rääkida, kui RBAC pole lubatud.
Tundub, et see ei ole viimane soovitus, kuid olen kindel, et paljud inimesed pole ikka veel isegi tootmises RBAC-i lubanud, sest see on palju askeldamist ja palju asju on vaja seadistada. Siiski julgustan teid seda tegema.
— RBACi veebisaidi jurist. See sisaldab tohutul hulgal huvitavaid materjale, mis aitavad RBAC-i seadistada, näitavad, miks see hea on ja kuidas sellega tootmises põhimõtteliselt kaasa elada.
Püüan selgitada, kuidas Tiller ja RBAC töötavad. Tiller töötab klastris teatud teenusekonto all. Tavaliselt, kui RBAC pole konfigureeritud, on see superkasutaja. Põhikonfiguratsioonis on Tiller administraator. Seetõttu öeldakse sageli, et Tiller on teie klastri SSH-tunnel. Tegelikult on see tõsi, nii et saate ülaltoodud diagrammil oleva teenuse vaikekonto asemel kasutada eraldi spetsiaalset teenusekontot.
Helmi lähtestamisel ja esmakordsel serverisse installimisel saate teenusekonto seadistada kasutades --service-account. See võimaldab teil kasutada minimaalsete nõutavate õigustega kasutajat. Tõsi, peate looma sellise "päriku": Roll ja RoleBinding.
Kahjuks ei tee Helm seda teie eest. Teie või teie Kubernetese klastri administraator peate Helmist läbimiseks ette valmistama teenusekonto jaoks rollide ja rollisidemete komplekti.
Tekib küsimus – mis vahe on Role ja ClusterRole vahel? Erinevus seisneb selles, et ClusterRole töötab kõigi nimeruumide jaoks, erinevalt tavalistest rollidest ja rollisidemetest, mis töötavad ainult spetsiaalses nimeruumis. Saate konfigureerida poliitikaid kogu klastri ja kõigi nimeruumide jaoks või isikupärastada iga nimeruumi jaoks eraldi.
Tasub mainida, et RBAC lahendab veel ühe suure probleemi. Paljud kurdavad, et Helm kahjuks ei ole mitmiküüriline (ei toeta mitmiküüri). Kui mitu meeskonda tarbivad klastrit ja kasutavad Helmi, on põhimõtteliselt võimatu selles klastris poliitikaid seadistada ja nende juurdepääsu piirata, kuna Helmi töötab teatud teenusekonto ja see loob selle alt kõik klastri ressursid. , mis on mõnikord väga ebamugav. See on tõsi – nagu binaarfail ise, nagu protsess, Helm Tilleril pole multiüüri kontseptsiooni.
Siiski on suurepärane viis, mis võimaldab teil Tillerit klastris mitu korda käivitada. Sellega pole probleemi, Tilleri saab käivitada igas nimeruumis. Seega saate kontekstina kasutada RBAC-i, Kubeconfigi ja piirata juurdepääsu spetsiaalsele Helmile.
See näeb välja selline.
Näiteks on olemas kaks Kubeconfigi kontekstiga erinevate meeskondade jaoks (kaks nimeruumi): X Team arendusmeeskonna ja administraatoriklastri jaoks. Administraatoriklastril on oma lai Tiller, mis asub Kube-süsteemi nimeruumis, vastavalt täiustatud teeninduskonto. Ja arendusmeeskonna jaoks on eraldi nimeruum, nad saavad oma teenused juurutada spetsiaalsesse nimeruumi.
See on toimiv lähenemisviis, Tiller ei ole nii energianäljas, et see teie eelarvet oluliselt mõjutaks. See on üks kiireid lahendusi.
Konfigureerige Tilleri julgelt eraldi ja andke Kubeconfigi kontekstiks meeskonna, konkreetse arendaja või keskkonna jaoks: Dev, Staging, Production (kahtlane on, et kõik on samas klastris, kuid seda saab teha).
Oma lugu jätkates läheme RBAC-lt üle ja räägime ConfigMapsist.
ConfigMaps
Helm kasutab andmehoidlana ConfigMapsi. Kui me rääkisime arhitektuurist, siis polnud kuskil andmebaasi, mis salvestaks infot väljaannete, konfiguratsioonide, tagasipööramiste jms kohta. Selleks kasutatakse ConfigMapsi.
ConfigMapsi põhiprobleem on teada – need on põhimõtteliselt ebaturvalised; tundlikke andmeid pole võimalik salvestada. Me räägime kõigest, mis ei tohiks teenusest kaugemale minna, näiteks paroolid. Helmi jaoks on praegu kõige loomulikum viis ConfigMapsi kasutamiselt üle minna saladustele.
Seda tehakse väga lihtsalt. Alistage säte Tiller ja määrake, et salvestusruum oleks salajane. Seejärel saate iga juurutuse kohta mitte ConfigMapi, vaid saladuse.
Võite väita, et saladused ise on kummaline mõiste ja mitte eriti turvaline. Siiski tasub mõista, et seda teevad Kubernetese arendajad ise. Alates versioonist 1.10, st. Juba mõnda aega on vähemalt avalikes pilvedes olnud võimalik õiget salvestusruumi ühendada saladuste salvestamisega. Meeskond töötab nüüd selle kallal, kuidas paremini levitada juurdepääsu saladustele, üksikutele kaustadele või muudele üksustele.
Parem on Storage Helm üle kanda saladustesse ja need on omakorda tsentraalselt turvatud.
Muidugi jääb andmete salvestamise limiit 1 MB. Helm kasutab siin ConfigMapsi hajutatud salvestusruumina jne. Ja seal nad arvasid, et see on sobiv andmepapp replikatsiooniks jne. Redditis käib selle üle huvitav arutelu, soovitan nädalavahetuseks seda naljakat lugemist leida või väljavõtet lugeda .
Tabelite reposid
Diagrammid on sotsiaalselt kõige haavatavamad ja võivad muutuda "mees keskel" allikaks, eriti kui kasutate aktsialahendust. Esiteks räägime hoidlatest, mis on avatud HTTP kaudu.
Helm Repo peate kindlasti paljastama HTTPS-i kaudu - see on parim valik ja on odav.
Märkus diagrammi allkirjastamise mehhanism. Tehnoloogia on pagana lihtne. See on sama, mida kasutate GitHubis, tavalises avaliku ja privaatvõtmega PGP-masinas. Seadistage ja veenduge, et teil on vajalikud võtmed ja kõik allkirjastatud, et see on tõesti teie diagramm.
Lisaks Helmi klient toetab TLS-i (mitte serveripoolses HTTP mõttes, vaid vastastikune TLS). Suhtlemiseks saate kasutada serveri- ja kliendivõtmeid. Ausalt öeldes ma sellist mehhanismi ei kasuta, sest mulle ei meeldi vastastikused sertifikaadid. Põhimõtteliselt - peamine tööriist Helm Repo seadistamiseks Helm 2 jaoks - toetab ka põhiautentimist. Võite kasutada põhiautentimist, kui see on mugavam ja vaiksem.
Samuti on olemas pistikprogramm , mis võimaldab hostida diagrammide reposid teenuses Google Cloud Storage. See on üsna mugav, töötab suurepäraselt ja on üsna ohutu, kuna kõik kirjeldatud mehhanismid on taaskasutatud.
Kui lubate HTTPS-i või TLS-i, kasutate mTLS-i ja lubate riskide edasiseks vähendamiseks põhiautentimise, saate Helmi CLI ja Chart Repo abil turvalise suhtluskanali.
gRPC API
Järgmine samm on väga oluline – kindlustada Tiller, mis asub klastris ja on ühest küljest server, teisest küljest pääseb ta ise ligi teistele komponentidele ja üritab kedagi teeselda.
Nagu ma juba ütlesin, on Tiller teenus, mis paljastab gRPC, Helmi klient tuleb selle juurde gRPC kaudu. Vaikimisi on TLS muidugi keelatud. Miks seda tehti, on vaieldav küsimus, mulle tundub, et see lihtsustab alguses seadistust.
Tootmiseks ja isegi lavastamiseks soovitan TLS-i lubada gRPC-l.
Minu arvates sobib see erinevalt diagrammide mTLS-ist siin ja seda tehakse väga lihtsalt - genereerige PQI infrastruktuur, looge sertifikaat, käivitage Tiller, edastage sertifikaat lähtestamise ajal. Pärast seda saate täita kõiki Helmi käske, esitades endale loodud sertifikaadi ja privaatvõtme.
Nii kaitsete end kõikide taotluste eest Tillerile väljastpoolt klastrit.
Seega oleme kindlustanud ühenduskanali Tilleriga, oleme juba arutanud RBAC-i ja kohandanud Kubernetese apiserveri õigusi, vähendades domeeni, millega see saab suhelda.
Kaitstud Helm
Vaatame lõplikku diagrammi. See on sama arhitektuur samade nooltega.
Kõik ühendused saab nüüd ohutult rohelisega joonistada:
- Chart Repo jaoks kasutame TLS-i või mTLS-i ja põhiautentimist;
- mTLS Tilleri jaoks ja see on avatud gRPC-teenusena koos TLS-iga, kasutame sertifikaate;
- klaster kasutab Role ja RoleBindinguga spetsiaalset teenusekontot.
Oleme klastri märkimisväärselt kindlustanud, kuid keegi tark ütles:
"Täiesti ohutu lahendus saab olla ainult üks - väljalülitatud arvuti, mis asub betoonkastis ja mida valvavad sõdurid."
Andmetega manipuleerimiseks ja uute ründevektorite leidmiseks on erinevaid viise. Olen siiski kindel, et need soovitused saavutavad tööstusharu põhilise ohutusstandardi.
Boonus
See osa ei ole otseselt turvalisusega seotud, kuid on samuti kasulik. Näitan teile mõnda huvitavat, millest vähesed teavad. Näiteks kuidas otsida graafikuid – ametlikke ja mitteametlikke.
Hoidlas Nüüd on umbes 300 diagrammi ja kaks voogu: stabiilne ja inkubaator. Igaüks, kes annab oma panuse, teab suurepäraselt, kui raske on inkubaatorist talli jõuda ja kui lihtne on tallist välja lennata. See pole aga parim tööriist Prometheuse ja muu meelepärase graafikute otsimiseks ühel lihtsal põhjusel – see pole portaal, kust saaks mugavalt pakette otsida.
Kuid teenus on olemas , mis muudab diagrammide leidmise palju mugavamaks. Kõige tähtsam on see, et saadaval on palju rohkem väliseid hoidlaid ja peaaegu 800 võlusid. Lisaks saate oma hoidla ühendada, kui te mingil põhjusel ei soovi oma diagramme talli saata.
Proovige hub.helm.sh ja arendame seda koos. See teenus on Helmi projekti raames ja saate isegi selle kasutajaliidese loomisele kaasa aidata, kui olete esiotsa arendaja ja soovite lihtsalt välimust parandada.
Tahaksin ka teie tähelepanu juhtida Ava Service Broker API integratsioon. See kõlab tülikas ja ebaselgelt, kuid lahendab probleemid, millega kõik silmitsi seisavad. Lubage mul selgitada lihtsa näitega.
Seal on Kubernetese klaster, milles tahame käivitada klassikalist rakendust - WordPress. Üldjuhul on täielikuks funktsionaalsuseks vaja andmebaasi. Lahendusi on palju, näiteks saate käivitada oma olekutäieliku teenuse. See pole eriti mugav, kuid paljud teevad seda.
Teised, nagu meie, Chainstack, kasutavad oma serverite jaoks hallatud andmebaase, nagu MySQL või PostgreSQL. Seetõttu asuvad meie andmebaasid kuskil pilves.
Kuid tekib probleem: peame ühendama oma teenuse andmebaasiga, looma andmebaasi maitse, edastama mandaadi ja seda kuidagi haldama. Tavaliselt teeb seda kõike käsitsi süsteemiadministraator või arendaja. Ja pole probleemi, kui rakendusi on vähe. Kui neid on palju, on vaja kombaini. Selline harvester on olemas – see on Service Broker. See võimaldab kasutada spetsiaalset pistikprogrammi avaliku pilveklastri jaoks ja tellida teenusepakkujalt Brokeri kaudu ressursse, nagu oleks tegemist API-ga. Selleks saate kasutada Kubernetese natiivseid tööriistu.
See on väga lihtne. Saate näiteks Azure'is päringuid hallata MySQL-i baastasemega (seda saab konfigureerida). Azure API abil luuakse andmebaas ja valmistatakse see kasutamiseks ette. Te ei pea sellesse sekkuma, selle eest vastutab pistikprogramm. Näiteks OSBA (Azure'i pistikprogramm) tagastab teenusele mandaadi ja edastab need Helmile. Saate kasutada WordPressi MySQL-i pilvega, mitte tegeleda hallatavate andmebaasidega ja mitte muretseda sisemiste olekuteabe teenuste pärast.
Võime öelda, et Helm toimib liimina, mis ühelt poolt võimaldab teil teenuseid juurutada ja teisest küljest kulutab pilveteenuse pakkujate ressursse.
Saate kirjutada oma pistikprogrammi ja kasutada kogu seda lugu kohapeal. Siis on teil ettevõtte pilveteenuse pakkuja jaoks lihtsalt oma pistikprogramm. Soovitan seda lähenemisviisi proovida, eriti kui teil on suur maht ja soovite kiiresti juurutada funktsiooni arendaja, lavastuse või kogu infrastruktuuri. See muudab teie toimingute või DevOpsi elu lihtsamaks.
Teine leid, mida ma juba mainisin, on helm-gcs plugin, mis võimaldab teil Helmi diagrammide salvestamiseks kasutada Google'i ämbriid (objektide salvestusruum).
Selle kasutamise alustamiseks vajate ainult nelja käsku:
- installige pistikprogramm;
- algatada see;
- määrake tee ämbrile, mis asub gcp-s;
- avaldada graafikuid standardsel viisil.
Ilus on see, et autoriseerimiseks kasutatakse natiivset gcp-meetodit. Saate kasutada teenusekontot, arendajakontot ja mida iganes soovite. See on väga mugav ja ei maksa midagi kasutada. Kui teie, nagu mina, propageerite opsless filosoofiat, on see väga mugav, eriti väikeste meeskondade jaoks.
Alternatiivid
Helm ei ole ainus teenusehalduslahendus. Sellega seoses on palju küsimusi, ilmselt seetõttu ilmus kolmas versioon nii kiiresti. Muidugi on alternatiive.
Need võivad olla spetsiaalsed lahendused, näiteks Ksonnet või Metaparticle. Saate kasutada oma klassikalisi infrastruktuuri haldustööriistu (Ansible, Terraform, Chef jne) samadel eesmärkidel, millest ma rääkisin.
Lõpuks on lahendus olemas , mille populaarsus kasvab.
Operator Framework on parim Helmi alternatiiv, mida kaaluda.
See on rohkem levinud CNCF-ile ja Kubernetesile, kuid sisenemise barjäär on palju kõrgem, peate rohkem programmeerima ja vähem manifeste kirjeldama.
Lisandmooduleid on erinevaid, näiteks Draft, Scaffold. Need muudavad elu palju lihtsamaks, näiteks lihtsustavad Helmi saatmise ja käivitamise tsüklit arendajatele testkeskkonna juurutamiseks. Ma nimetaksin neid võimendajateks.
Siin on visuaalne skeem, kus kõik on.
X-teljel on teie isikliku kontrolli tase toimuva üle, y-teljel on Kubernetese päritolu. Helmi versioon 2 jääb kuskile keskele. 3. versioonis küll mitte tohutult, kuid paranenud on nii juhtimine kui ka omapära tase. Ksonneti tasemel lahendused jäävad endiselt alla isegi Helm 2-le. Küll aga tasub neid vaadata, et teada, mis siin maailmas veel on. Loomulikult on teie konfiguratsioonihaldur teie kontrolli all, kuid see pole absoluutselt Kubernetese oma.
Operator Framework on Kubernetesele täiesti omane ja võimaldab teil seda palju elegantsemalt ja täpsemini hallata (kuid pidage meeles algtaseme kohta). Pigem sobib see spetsialiseeritud rakenduseks ja selle haldamise loomiseks, mitte masskombainiks suure hulga rakenduste pakendamiseks Helmi abil.
Laiendajad lihtsalt parandavad veidi juhtimist, täiendavad töövoogu või kärbivad CI/CD torujuhtmete nurki.
Helmi tulevik
Hea uudis on see, et tulemas on Helm 3. Helmi 3.0.0-alpha.2 alfaversioon on juba välja antud, saate seda proovida. See on üsna stabiilne, kuid funktsionaalsus on endiselt piiratud.
Miks teil Helm 3 vaja on? Esiteks on see lugu sellest Tilleri kadumine, komponendina. Nagu te juba aru saate, on see tohutu samm edasi, sest arhitektuuri turvalisuse seisukohalt on kõik lihtsustatud.
Kui Helm 2 loodi, mis oli umbes Kubernetes 1.8 või isegi varem, olid paljud kontseptsioonid ebaküpsed. Näiteks CRD kontseptsiooni praegu aktiivselt rakendatakse ja Helm teeb seda kasutada CRD-dkonstruktsioonide hoidmiseks. Võimalik on kasutada ainult klienti ja mitte hooldada serveriosa. Seetõttu kasutage struktuuride ja ressurssidega töötamiseks Kubernetese natiivseid käske. See on suur samm edasi.
Ilmub toetus kohalikele OCI hoidlatele (Open Container Initiative). See on tohutu algatus ja Helm on huvitatud eelkõige oma edetabelite postitamisest. See jõuab sinnani, et näiteks Docker Hub toetab paljusid OCI standardeid. Ma ei arva, kuid võib-olla hakkavad klassikalised Dockeri hoidla pakkujad andma teile võimaluse oma Helmi diagramme majutada.
Minu jaoks vastuoluline lugu on Lua tugi, skriptide kirjutamise mallimootorina. Ma ei ole suur Lua fänn, kuid see oleks täiesti vabatahtlik funktsioon. Kontrollisin seda 3 korda – Lua kasutamine pole vajalik. Seetõttu liituge meie tohutu leeriga need, kes soovivad Luat kasutada, need, kellele Go meeldib, ja kasutage selleks go-tmpli.
Lõpuks, millest ma kindlasti puudust tundsin skeemi tekkimine ja andmetüübi valideerimine. Int ega stringiga pole enam probleeme, nulli pole vaja jutumärkidesse mähkida. Ilmub JSONS-skeem, mis võimaldab teil seda väärtuste jaoks selgesõnaliselt kirjeldada.
Töötatakse kõvasti ümber sündmustest juhitud mudel. Seda on kontseptuaalselt juba kirjeldatud. Vaadake Helm 3 haru ja näete, kui palju sündmusi ja konkse ja muud on lisatud, mis oluliselt lihtsustab ja teisalt lisab kontrolli juurutusprotsesside ja neile reageerimise üle.
Helm 3 on lihtsam, turvalisem ja lõbusam, mitte sellepärast, et meile Helm 2 ei meeldiks, vaid seetõttu, et Kubernetes on muutumas arenenumaks. Sellest lähtuvalt saab Helm kasutada Kubernetese arendusi ja luua sellel Kubernetesele suurepäraseid juhte.
Teine hea uudis on see Aleksander Khajorov ütleb teile, Tuletame meelde, et arendus-, testimis- ja käitamisprotsesside integreerimise konverents toimub Moskvas 30. septembril ja 1. oktoobril. Seda saab teha veel 20. augustini ja rääkige meile oma kogemustest lahendusega DevOpsi lähenemisviisi ülesanded.
Jälgige konverentsi kontrollpunkte ja uudiseid aadressil и .
Allikas: www.habr.com