Istorijos apie populiariausią „Kubernetes“ paketų tvarkyklę esmė gali būti pavaizduota naudojant jaustuką:
- dėžutė yra „Helm“ (tai yra arčiausiai naujausio „Emoji“ leidimo);
- spyna – apsauga;
- mažas žmogus yra problemos sprendimas.
Tiesą sakant, viskas bus šiek tiek sudėtingesnė, o istorija kupina techninių detalių Kaip padaryti, kad Helmas būtų saugus.
- Trumpai, kas yra Helmas, jei nežinojote arba pamiršote. Kokias problemas jis sprendžia ir kur jis yra ekosistemoje.
- Pažvelkime į Helmo architektūrą. Joks pokalbis apie saugumą ir apie tai, kaip padaryti įrankį ar sprendimą saugesnį, nėra baigtas nesuvokus komponento architektūros.
- Aptarkime Helm komponentus.
- Labiausiai degantis klausimas yra ateitis – naujoji „Helm 3“ versija.
Viskas, kas nurodyta šiame straipsnyje, taikoma „Helm 2“. Ši versija šiuo metu yra gaminama ir greičiausiai yra ta, kurią šiuo metu naudojate, ir būtent ta versija apima saugumo riziką.
Apie kalbėtoją: Aleksandras Khayorovas () kuria jau 10 metų, padeda tobulinti turinį ir įstojo į komitetą . Dabar jis dirba „Chainstack“ kūrimo vadovu – tai hibridas tarp kūrimo vadovo ir asmens, atsakingo už galutinių leidimų pristatymą. Tai yra, jis yra mūšio lauke, kur viskas vyksta nuo produkto sukūrimo iki jo veikimo.
„Chainstack“ yra mažas, aktyviai augantis startuolis, kurio misija – leisti klientams pamiršti apie infrastruktūrą ir decentralizuotų programų eksploatavimo sudėtingumą; kūrimo komanda įsikūrusi Singapūre. Neprašykite „Chainstack“ parduoti ar pirkti kriptovaliutą, bet pasiūlykite pasikalbėti apie įmonės „blockchain“ sistemas, ir jie jums mielai atsakys.
Šalmas
Tai Kubernetes paketo (diagramos) tvarkyklė. Pats intuityviausias ir universaliausias būdas perkelti programas į Kubernetes klasterį.
Žinoma, mes kalbame apie labiau struktūrinį ir pramoninį požiūrį nei kurti savo YAML manifestus ir rašyti mažas komunalines paslaugas.
Helm yra geriausias šiuo metu prieinamas ir populiarus.
Kodėl Helmas? Visų pirma todėl, kad jį palaiko CNCF. „Cloud Native“ yra didelė organizacija ir yra pagrindinė projektų „Kubernetes“, etcd, „Fluentd“ ir kitų įmonė.
Kitas svarbus faktas yra tai, kad Helm yra labai populiarus projektas. Kai 2019 m. sausio mėn. pradėjau kalbėti apie tai, kaip padaryti „Helm“ saugų, projektas „GitHub“ sulaukė tūkstančio žvaigždžių. Iki gegužės jų buvo 12 tūkst.
Daugelis žmonių domisi Helm, todėl net jei dar jo nenaudojate, jums bus naudinga žinoti apie jo saugumą. Saugumas yra svarbus.
Pagrindinę „Helm“ komandą palaiko „Microsoft Azure“, todėl tai yra gana stabilus projektas, skirtingai nei daugelis kitų. Helm 3 Alpha 2 išleidimas liepos viduryje rodo, kad prie projekto dirba gana daug žmonių, kurie turi noro ir energijos kurti ir tobulinti Helm.
Helm išsprendžia keletą pagrindinių Kubernetes programų valdymo problemų.
- Aplikacijos pakuotė. Netgi tokia programa, kaip „Sveikas, pasauli“, „WordPress“ jau susideda iš kelių paslaugų, ir jūs norite jas supakuoti kartu.
- Šių programų valdymo sudėtingumo valdymas.
- Gyvenimo ciklas, kuris nesibaigia įdiegus arba įdiegus programą. Ji ir toliau gyvuoja, ją reikia atnaujinti, o Helm padeda tai padaryti ir bando imtis tinkamų priemonių ir politikos.
Pakavimas į maišus jis sutvarkytas aiškiai: yra metaduomenys, visiškai atitinkantys įprasto „Linux“, „Windows“ ar „MacOS“ paketų tvarkyklės darbą. Tai yra saugykla, priklausomybės nuo įvairių paketų, taikomųjų programų metainformacija, nustatymai, konfigūracijos ypatybės, informacijos indeksavimas ir kt. Helm leidžia visa tai gauti ir naudoti programoms.
Sudėtingumo valdymas. Jei turite daug to paties tipo programų, reikia nustatyti parametrus. Šablonai gaunami iš to, bet kad nereikėtų sugalvoti savo būdo kurti šablonus, galite naudoti tai, ką Helm siūlo iš karto.
Programos gyvavimo ciklo valdymas – mano nuomone, tai įdomiausias ir neišspręstas klausimas. Štai kodėl aš atėjau į Helmą tą pačią dieną. Mums reikėjo stebėti programos gyvavimo ciklą ir norėjome perkelti savo CI / CD ir programų ciklus į šią paradigmą.
Helm leidžia:
- valdyti diegimus, supažindinama su konfigūravimo ir peržiūros samprata;
- sėkmingai atlikti atšaukimą;
- naudoti kabliukus įvairiems renginiams;
- pridėti papildomų programų patikrinimų ir atsakyti į jų rezultatus.
Be to Vairas turi „baterijas“ - daugybė skanių dalykų, kuriuos galima įtraukti į papildinių formą, supaprastinant jūsų gyvenimą. Įskiepiai gali būti rašomi savarankiškai, jie yra gana izoliuoti ir nereikalauja harmoningos architektūros. Jei norite ką nors įdiegti, rekomenduoju tai padaryti kaip įskiepį ir galbūt įtraukti jį į ankstesnįjį srautą.
Helm remiasi trimis pagrindinėmis sąvokomis:
- Atpirkimo diagrama — aprašas ir galimų jūsų manifesto parametrų masyvas.
- konfigūracijos – tai yra reikšmės, kurios bus taikomos (tekstas, skaitinės reikšmės ir kt.).
- Atleiskite surenka du viršutinius komponentus ir kartu jie virsta Release. Leidimai gali būti modifikuojami ir taip pasiekiamas organizuotas gyvavimo ciklas: mažas įdiegimo metu ir didelis atnaujinimo, ankstesnės versijos ar grąžinimo metu.
Vairo architektūra
Diagramoje konceptualiai pavaizduota aukšto lygio Helmo architektūra.
Leiskite jums priminti, kad Helmas yra kažkas susiję su Kubernetes. Todėl negalime apsieiti be Kubernetes klasterio (stačiakampio). „Kube-apiserver“ komponentas yra pagrindiniame kompiuteryje. Be vairo mes turime Kubeconfig. Helm atneša vieną nedidelį dvejetainį, jei taip galima pavadinti, Helm CLI įrankį, kuris yra įdiegtas kompiuteryje, nešiojamajame kompiuteryje, pagrindiniame kompiuteryje – ant bet ko.
Tačiau to neužtenka. „Helm“ turi serverio komponentą „Tiller“. Ji atstovauja Helm interesams klasteryje; tai Kubernetes klasteryje esanti programa, kaip ir bet kuri kita.
Kitas „Chart Repo“ komponentas yra saugykla su diagramomis. Yra oficiali saugykla, o gali būti ir privati įmonės ar projekto saugykla.
Sąveika
Pažiūrėkime, kaip sąveikauja architektūros komponentai, kai norime įdiegti programą naudodami „Helm“.
- Mes kalbamės
Helm install, pasiekite saugyklą (Chart Repo) ir gaukite Helm diagramą.
- „Helm“ paslaugų programa (Helm CLI) sąveikauja su „Kubeconfig“, kad išsiaiškintų, į kurią grupę susisiekti.
- Gavusi šią informaciją, programa nurodo Tiller, kuris yra mūsų klasteryje.
- Tiller iškviečia Kube-apiserver, kad atliktų veiksmus Kubernetes, sukurtų kai kuriuos objektus (paslaugas, podelius, kopijas, paslaptis ir kt.).
Toliau diagramą apsunkinsime, kad pamatytume atakos vektorių, su kuriuo gali susidurti visa „Helm“ architektūra. Ir tada mes stengsimės ją apsaugoti.
Atakos vektorius
Pirma galima silpnoji vieta yra privilegijuota API-vartotojas. Kaip schemos dalis, tai įsilaužėlis, gavęs administratoriaus prieigą prie Helm CLI.
Neprivilegijuotas API vartotojas taip pat gali kelti pavojų, jei jis yra kažkur netoliese. Toks vartotojas turės skirtingą kontekstą, pavyzdžiui, jis gali būti užfiksuotas vienoje klasterio vardų erdvėje Kubeconfig nustatymuose.
Įdomiausias atakos vektorius gali būti procesas, kuris yra klasteryje kažkur netoli Tiller ir gali jį pasiekti. Tai gali būti žiniatinklio serveris arba mikropaslauga, kuri mato klasterio tinklo aplinką.
Egzotiškas, bet vis populiaresnis atakos variantas apima „Chart Repo“. Nesąžiningo autoriaus sukurtoje diagramoje gali būti nesaugių išteklių, o jūs užpildysite ją tikėdami. Arba jis gali pakeisti diagramą, kurią atsisiunčiate iš oficialios saugyklos, ir, pavyzdžiui, sukurti išteklių politikos forma ir išplėsti jo prieigą.
Pabandykime atremti atakas iš visų šių keturių pusių ir išsiaiškinti, kur yra problemų Helm architektūroje, o kur, ko gero, jų nėra.
Padidinkime diagramą, pridėkime daugiau elementų, bet palikime visus pagrindinius komponentus.
„Helm CLI“ palaiko ryšį su „Chart Repo“, sąveikauja su „Kubeconfig“, o darbas perkeliamas į klasterį į „Tiller“ komponentą.
Tileris pavaizduotas dviem objektais:
- Tiller-deploy svc, kuris atskleidžia tam tikrą paslaugą;
- „Tiller-deploy“ blokas (schemoje vienoje kopijoje vienoje kopijoje), kurioje veikia visa įkrova, kuri pasiekia klasterį.
Sąveikai naudojami skirtingi protokolai ir schemos. Saugumo požiūriu mus labiausiai domina:
- Mechanizmas, kuriuo Helm CLI pasiekia diagramos atpirkimą: koks protokolas, ar yra autentifikavimas ir ką su juo galima padaryti.
- Protokolas, pagal kurį Helm CLI, naudodamas kubectl, bendrauja su Tiller. Tai yra RPC serveris, įdiegtas klasterio viduje.
- Pats „Tiller“ yra prieinamas mikropaslaugoms, kurios yra klasteryje ir sąveikauja su „Kube-apiserver“.
Aptarkime visas šias sritis iš eilės.
RBAC
Nėra prasmės kalbėti apie „Helm“ ar bet kurios kitos klasterio paslaugos saugumą, nebent įjungta RBAC.
Atrodo, kad tai ne naujausia rekomendacija, bet esu tikras, kad daugelis žmonių vis dar neįjungė RBAC net gamyboje, nes tai yra daug šurmulio ir daug ką reikia sukonfigūruoti. Tačiau aš raginu jus tai padaryti.
— RBAC svetainės teisininkas. Jame yra daug įdomios medžiagos, kuri padės nustatyti RBAC, parodys, kodėl tai yra gera ir kaip iš esmės su tuo gyventi gamyboje.
Pabandysiu paaiškinti, kaip veikia Tiller ir RBAC. Tiller dirba klasterio viduje pagal tam tikrą paslaugų paskyrą. Paprastai, jei RBAC nesukonfigūruotas, tai bus supervartotojas. Pagrindinėje konfigūracijoje Tiller bus administratorius. Štai kodėl dažnai sakoma, kad „Tiller“ yra SSH tunelis jūsų klasteriui. Tiesą sakant, tai tiesa, todėl galite naudoti atskirą dedikuotą paslaugų paskyrą, o ne numatytąją paslaugos paskyrą, pateiktą aukščiau esančioje diagramoje.
Kai inicijuojate Helm ir įdiegiate jį serveryje pirmą kartą, galite nustatyti paslaugos paskyrą naudodami --service-account. Tai leis jums naudoti vartotoją su minimaliomis reikiamomis teisėmis. Tiesa, teks sukurti tokią „girliandą“: Role ir RoleBinding.
Deja, Helmas to nepadarys už jus. Jūs arba jūsų „Kubernetes“ klasterio administratorius turite iš anksto paruošti paslaugų paskyros vaidmenų ir vaidmenų susiejimo rinkinį, kad galėtumėte pereiti prie „Helm“.
Kyla klausimas – kuo skiriasi Role ir ClusterRole? Skirtumas tas, kad „ClusterRole“ veikia visose vardų erdvėse, skirtingai nei įprasti vaidmenys ir vaidmenų surišimai, kurie veikia tik specializuotoje vardų erdvėje. Galite konfigūruoti strategijas visam klasteriui ir visoms vardų erdvėms arba individualizuoti kiekvienai vardų erdvei atskirai.
Verta paminėti, kad RBAC išsprendžia dar vieną didelę problemą. Daugelis žmonių skundžiasi, kad Helm, deja, nėra daugiabučiai (nepalaiko daugiabučio). Jei kelios komandos naudoja klasterį ir naudoja „Helm“, iš esmės neįmanoma nustatyti politikos ir apriboti jų prieigą šiame klasteryje, nes yra tam tikra paslaugos paskyra, pagal kurią veikia „Helm“, ir ji sukuria visus klasteryje esančius išteklius iš po jo. , kuris kartais būna labai nepatogus. Tai tiesa – kaip ir pats dvejetainis failas, kaip ir procesas, Helmas Tiller neturi daugialypės nuosavybės koncepcijos.
Tačiau yra puikus būdas, leidžiantis paleisti „Tiller“ kelis kartus grupėje. Dėl to nėra jokių problemų, „Tiller“ galima paleisti kiekvienoje vardų erdvėje. Taigi kaip kontekstą galite naudoti RBAC, Kubeconfig ir apriboti prieigą prie specialaus Helm.
Tai atrodys taip.
Pavyzdžiui, yra dvi „Kubeconfig“ su kontekstu skirtingoms komandoms (dvi vardų erdvės): „X Team“ kūrimo komandai ir administratoriaus klasteriui. Administratoriaus klasteris turi savo platų Tiller, esantį Kube sistemos vardų erdvėje, atitinkamai pažangią paslaugų paskyrą. Ir atskira vardų sritis kūrėjų komandai, jie galės dislokuoti savo paslaugas specialioje vardų srityje.
Tai veiksmingas metodas, Tiller nėra toks alkanas energijos, kad tai labai paveiktų jūsų biudžetą. Tai vienas iš greitų sprendimų.
Nesivaržykite konfigūruoti Tiller atskirai ir suteikti Kubeconfig kontekstą komandai, konkrečiam kūrėjui ar aplinkai: Dev, Staging, Production (abejotina, kad viskas bus tame pačiame klasteryje, tačiau tai galima padaryti).
Tęsdami savo istoriją, pereikime nuo RBAC ir pakalbėkime apie ConfigMaps.
ConfigMaps
„Helm“ kaip duomenų saugyklą naudoja „ConfigMaps“. Kai kalbėjome apie architektūrą, niekur nebuvo duomenų bazės, kurioje būtų saugoma informacija apie leidimus, konfigūracijas, atšaukimus ir pan. Tam naudojamas ConfigMaps.
Pagrindinė ConfigMaps problema yra žinoma – jie iš principo nesaugūs; neskelbtinų duomenų saugoti neįmanoma. Mes kalbame apie viską, kas neturėtų viršyti paslaugos, pavyzdžiui, slaptažodžiai. Šiuo metu labiausiai naudojamas „Helm“ būdas yra pereiti nuo „ConfigMaps“ prie paslapčių naudojimo.
Tai daroma labai paprastai. Nepaisykite „Tiller“ nustatymo ir nurodykite, kad saugykla bus slapta. Tada už kiekvieną diegimą gausite ne ConfigMap, o paslaptį.
Galite ginčytis, kad pačios paslaptys yra keista sąvoka ir nėra labai saugi. Tačiau verta suprasti, kad tai daro patys „Kubernetes“ kūrėjai. Pradedant nuo 1.10 versijos, t.y. Jau gana seniai bent jau viešuose debesyse galima prijungti tinkamą saugyklą paslapčių saugojimui. Šiuo metu komanda ieško būdų, kaip geriau paskirstyti prieigą prie paslapčių, atskirų rinkinių ar kitų objektų.
Storage Helm geriau perkelti į paslaptis, o jos, savo ruožtu, yra apsaugotos centralizuotai.
Žinoma, kad išliks duomenų saugojimo limitas 1 MB. „Helm“ čia naudoja etcd kaip paskirstytą „ConfigMaps“ saugyklą. Ir ten jie manė, kad tai yra tinkama duomenų dalis replikacijai ir pan. „Reddit“ apie tai vyksta įdomi diskusija, rekomenduoju rasti šį juokingą skaitymą savaitgaliui arba perskaityti ištrauką .
Grafiko atpirkimo sandoriai
Diagramos yra labiausiai socialiai pažeidžiamos ir gali tapti „žmogaus viduryje“ šaltiniu, ypač jei naudojate akcijų sprendimą. Visų pirma, mes kalbame apie saugyklas, kurios veikia per HTTP.
Būtinai turite atskleisti „Helm Repo“ per HTTPS – tai geriausias ir nebrangus pasirinkimas.
Atminkite, kad diagramos parašo mechanizmas. Technologija paprasta kaip pragaras. Tai yra tas pats, ką naudojate „GitHub“ – įprastame PGP įrenginyje su viešaisiais ir privačiais raktais. Nustatykite ir įsitikinkite, turėdami reikiamus raktus ir viską pasirašydami, kad tai tikrai jūsų diagrama.
be to, Helm klientas palaiko TLS (ne serverio pusės HTTP prasme, o abipuse TLS). Norėdami susisiekti, galite naudoti serverio ir kliento raktus. Jei atvirai, aš tokio mechanizmo nenaudoju, nes nemėgstu abipusių pažymėjimų. Iš esmės, – pagrindinis „Helm Repo“, skirtas Helm 2, nustatymo įrankis – taip pat palaiko pagrindinį autentifikavimą. Galite naudoti pagrindinį autentifikavimą, jei tai patogiau ir tyliau.
Taip pat yra įskiepis , kuri leidžia „Google Cloud Storage“ priglobti „Chart Repos“. Tai gana patogu, veikia puikiai ir yra gana saugu, nes visi aprašyti mechanizmai yra perdirbami.
Jei įjungsite HTTPS arba TLS, naudosite mTLS ir įgalinsite pagrindinį autentifikavimą, kad dar labiau sumažintumėte riziką, gausite saugų ryšio kanalą su Helm CLI ir Chart Repo.
gRPC API
Kitas žingsnis yra labai svarbus - apsaugoti Tiller, kuris yra klasteryje ir yra, viena vertus, serveris, kita vertus, jis pats pasiekia kitus komponentus ir bando apsimesti kažkuo.
Kaip jau sakiau, „Tiller“ yra paslauga, kuri atskleidžia gRPC, „Helm“ klientas į ją ateina per gRPC. Žinoma, pagal numatytuosius nustatymus TLS yra išjungtas. Kodėl tai buvo padaryta, yra diskutuotinas klausimas, man atrodo, kad pradžioje reikia supaprastinti sąranką.
Gamybai ir netgi pastatymui rekomenduoju įjungti TLS gRPC.
Mano nuomone, skirtingai nei mTLS diagramoms, čia tai tinka ir daroma labai paprastai – sugeneruokite PQI infrastruktūrą, sukurkite sertifikatą, paleiskite „Tiller“, perkelkite sertifikatą inicijavimo metu. Po to galite vykdyti visas Helm komandas, pateikdami sugeneruotą sertifikatą ir privatųjį raktą.
Taip apsisaugosite nuo visų užklausų Tiller iš už klasterio ribų.
Taigi, mes užsitikrinome ryšio kanalą su Tiller, jau aptarėme RBAC ir pakoregavome Kubernetes apiserverio teises, sumažindami domeną, su kuriuo jis gali bendrauti.
Apsaugotas vairas
Pažiūrėkime į galutinę diagramą. Tai ta pati architektūra su tomis pačiomis rodyklėmis.
Dabar visas jungtis galima saugiai nubrėžti žalia spalva:
- Chart Repo naudojame TLS arba mTLS ir pagrindinį autentifikavimą;
- mTLS skirta Tiller, ir ji yra atskleista kaip gRPC paslauga su TLS, mes naudojame sertifikatus;
- klasteris naudoja specialią paslaugų paskyrą su Role ir RoleBinding.
Mes žymiai apsaugojome klasterį, bet kažkas protingas pasakė:
„Visiškai saugus sprendimas gali būti tik vienas – išjungtas kompiuteris, kuris yra betoninėje dėžėje ir yra saugomas karių.
Yra įvairių būdų manipuliuoti duomenimis ir rasti naujų atakų vektorių. Tačiau esu įsitikinęs, kad šios rekomendacijos padės pasiekti pagrindinį pramonės saugos standartą.
Premija
Ši dalis nėra tiesiogiai susijusi su saugumu, bet taip pat bus naudinga. Parodysiu keletą įdomių dalykų, apie kuriuos žino nedaugelis. Pavyzdžiui, kaip ieškoti diagramų – oficialių ir neoficialių.
Saugykloje Dabar yra apie 300 diagramų ir du srautai: stabilus ir inkubatorius. Kiekvienas, kuris prisideda, puikiai žino, kaip sunku iš inkubatoriaus patekti į arklidę ir kaip lengva išskristi iš arklidės. Tačiau tai nėra pats geriausias įrankis ieškoti Prometheus ir bet ko kito, kas jums patinka, diagramų dėl vienos paprastos priežasties – tai nėra portalas, kuriame būtų galima patogiai ieškoti paketų.
Bet yra paslauga , todėl diagramas rasti daug patogiau. Svarbiausia, kad yra daug daugiau išorinių saugyklų ir beveik 800 pakabukų. Be to, galite prijungti saugyklą, jei dėl kokių nors priežasčių nenorite siųsti diagramų į stabilųjį.
Išbandykite hub.helm.sh ir kurkime jį kartu. Ši paslauga teikiama pagal Helm projektą, ir jūs netgi galite prisidėti prie jos vartotojo sąsajos, jei esate priekinės dalies kūrėjas ir tiesiog norite patobulinti išvaizdą.
Taip pat norėčiau atkreipti jūsų dėmesį į Atidarykite „Service Broker“ API integraciją. Tai skamba sudėtingai ir neaiškiai, bet išsprendžia problemas, su kuriomis susiduria visi. Leiskite paaiškinti paprastu pavyzdžiu.
Yra „Kubernetes“ klasteris, kuriame norime paleisti klasikinę programą – „WordPress“. Paprastai duomenų bazė reikalinga visam funkcionalumui. Yra daug skirtingų sprendimų, pavyzdžiui, galite paleisti savo būsenos paslaugą. Tai nėra labai patogu, tačiau daugelis žmonių tai daro.
Kiti, kaip ir mes, Chainstack, savo serveriams naudoja valdomas duomenų bazes, tokias kaip MySQL arba PostgreSQL. Štai kodėl mūsų duomenų bazės yra kažkur debesyje.
Tačiau iškyla problema: turime susieti savo paslaugą su duomenų baze, sukurti duomenų bazės skonį, perkelti kredencialus ir kažkaip juos valdyti. Visa tai dažniausiai rankiniu būdu atlieka sistemos administratorius arba kūrėjas. Ir nėra problemų, kai yra mažai programų. Kai jų daug, reikia kombaino. Yra toks kombainas – tai Service Broker. Tai leidžia naudoti specialų papildinį viešajam debesų klasteriui ir užsisakyti išteklius iš tiekėjo per Brokerį, tarsi tai būtų API. Tam galite naudoti vietinius „Kubernetes“ įrankius.
Tai labai paprasta. Galite pateikti užklausą, pavyzdžiui, „Managed MySQL“ sistemoje „Azure“ naudodami bazinę pakopą (ją galima sukonfigūruoti). Naudojant Azure API, duomenų bazė bus sukurta ir paruošta naudoti. Jums nereikia kištis į tai, už tai atsakingas papildinys. Pavyzdžiui, OSBA („Azure“ papildinys) grąžins tarnybos kredencialus ir perduos juos „Helm“. Galėsite naudoti WordPress su debesies MySQL, visiškai nedirbti su valdomomis duomenų bazėmis ir nesijaudinti dėl būsenos pilnų paslaugų viduje.
Galima sakyti, kad „Helm“ veikia kaip klijai, kurie, viena vertus, leidžia diegti paslaugas, kita vertus, sunaudoja debesų tiekėjų išteklius.
Galite parašyti savo papildinį ir naudoti visą šią istoriją vietoje. Tada tiesiog turėsite savo įskiepį, skirtą įmonės debesų paslaugų teikėjui. Rekomenduoju išbandyti šį metodą, ypač jei turite didelį mastą ir norite greitai įdiegti kūrimo, sustojimo ar visos funkcijos infrastruktūrą. Tai palengvins jūsų operacijų ar „DevOps“ gyvenimą.
Kitas atradimas, kurį jau minėjau, yra helm-gcs papildinys, kuri leidžia naudoti Google-buckets (objektų saugyklą) Helm diagramoms saugoti.
Norėdami pradėti naudoti, jums reikia tik keturių komandų:
- įdiegti papildinį;
- inicijuoti jį;
- nustatykite kelią į kibirą, esantį gcp;
- skelbti diagramas standartiniu būdu.
Puiku, kad autorizacijai bus naudojamas vietinis gcp metodas. Galite naudoti paslaugų paskyrą, kūrėjo paskyrą, ką tik norite. Tai labai patogu ir nieko nekainuoja eksploatuoti. Jei jūs, kaip ir aš, propaguojate opsless filosofiją, tai bus labai patogu, ypač mažoms komandoms.
Alternatyvos
Helm nėra vienintelis paslaugų valdymo sprendimas. Dėl to kyla daug klausimų, tikriausiai todėl taip greitai pasirodė trečioji versija. Žinoma, yra alternatyvų.
Tai gali būti specializuoti sprendimai, pavyzdžiui, „Ksonnet“ arba „Metaparticle“. Galite naudoti savo klasikinius infrastruktūros valdymo įrankius (Ansible, Terraform, Chef ir kt.) tiems patiems tikslams, apie kuriuos kalbėjau.
Pagaliau yra sprendimas , kurio populiarumas auga.
Operator Framework yra geriausia „Helm“ alternatyva, kurią reikia apsvarstyti.
Jis labiau kilęs iš CNCF ir Kubernetes, bet barjeras patekti yra daug didesnis, reikia daugiau programuoti ir mažiau aprašinėti.
Yra įvairių priedų, tokių kaip Draft, Scaffold. Jie labai palengvina gyvenimą, pavyzdžiui, supaprastina „Helm“ siuntimo ir paleidimo ciklą, kad kūrėjai galėtų įdiegti bandomąją aplinką. Aš juos pavadinčiau įgalintojais.
Čia yra vaizdinė diagrama, kur viskas yra.
X ašyje yra jūsų asmeninio valdymo, kas vyksta, lygis, y ašyje – Kubernetes gimtumo lygis. 2 vairo versija patenka kažkur per vidurį. 3 versijoje ne itin, bet patobulinta ir valdymas, ir gimtosios kalbos lygis. Ksonnet lygio sprendimai vis dar nusileidžia net Helm 2. Tačiau verta pasidomėti, kas dar yra šiame pasaulyje. Žinoma, jūsų konfigūracijos tvarkyklė bus jūsų valdoma, tačiau ji visiškai nėra gimtoji Kubernetes.
„Operator Framework“ yra visiškai gimtoji „Kubernetes“ ir leidžia ją valdyti daug elegantiškiau ir skrupulingiau (tačiau nepamirškite apie pradinį lygį). Greičiau tai tinka specializuotai programai ir jos valdymo sukūrimui, o ne masiniam kombainui, skirtam supakuoti daugybę programų naudojant „Helm“.
Plėtiniai tiesiog šiek tiek pagerina valdymą, papildo darbo eigą arba sumažina CI / CD vamzdynų kampus.
Helmo ateitis
Geros naujienos yra tai, kad ateina Helm 3. Alfa versija Helm 3.0.0-alpha.2 jau buvo išleista, galite ją išbandyti. Jis yra gana stabilus, tačiau funkcionalumas vis dar ribotas.
Kodėl jums reikia „Helm 3“? Visų pirma, tai istorija apie Tilerio dingimas, kaip komponentas. Tai, kaip jau supratote, yra didžiulis žingsnis į priekį, nes architektūros saugumo požiūriu viskas yra supaprastinta.
Kai buvo sukurtas Helm 2, kuris buvo maždaug Kubernetes 1.8 ar net anksčiau, daugelis koncepcijų buvo nesubrendusios. Pavyzdžiui, CRD koncepcija dabar aktyviai įgyvendinama, o Helmas tai padarys naudoti CRDkonstrukcijoms saugoti. Bus galima naudoti tik klientą, o ne prižiūrėti serverio dalį. Atitinkamai, dirbdami su struktūromis ir ištekliais naudokite vietines Kubernetes komandas. Tai didžiulis žingsnis į priekį.
Atsiras vietinių OCI saugyklų palaikymas (Atviro konteinerio iniciatyva). Tai didžiulė iniciatyva, ir Helmas pirmiausia domisi siekdamas paskelbti savo diagramas. Pavyzdžiui, „Docker Hub“ palaiko daugybę OCI standartų. Neatspėju, bet galbūt klasikiniai „Docker“ saugyklų teikėjai suteiks jums galimybę talpinti „Helm“ diagramas.
Man prieštaringa istorija yra Lua palaikymas, kaip šablonų variklis scenarijų rašymui. Nesu didelis Lua gerbėjas, bet tai būtų visiškai neprivaloma funkcija. Patikrinau tai 3 kartus – Lua naudoti nereikės. Todėl tie, kurie nori turėti galimybę naudotis Lua, tie, kuriems patinka Go, prisijunkite prie mūsų didžiulės stovyklos ir tam naudokite go-tmpl.
Galiausiai, ko man tikrai trūko schemos atsiradimas ir duomenų tipo patvirtinimas. Nebebus problemų su int ar eilute, nereikės vynioti nulio į dvigubas kabutes. Bus parodyta JSONS schema, kuri leis jums aiškiai tai aprašyti vertes.
Bus smarkiai perdirbtas įvykiais pagrįstas modelis. Tai jau buvo konceptualiai aprašyta. Pažvelkite į „Helm 3“ filialą ir pamatysite, kiek įvykių, kabliukų ir kitų dalykų buvo pridėta, o tai labai supaprastins ir, kita vertus, padidins diegimo procesų ir reakcijų į juos valdymą.
„Helm 3“ bus paprastesnis, saugesnis ir smagesnis ne todėl, kad mums nepatinka „Helm 2“, o todėl, kad „Kubernetes“ darosi vis tobulesnė. Atitinkamai, „Helm“ gali naudoti „Kubernetes“ plėtrą ir sukurti puikius „Kubernetes“ vadovus.
Dar viena gera žinia yra ta Aleksandras Khayorovas jums pasakys, Priminsime, kad kūrimo, testavimo ir eksploatavimo procesų integravimo konferencija vyks Maskvoje rugsėjo 30 ir spalio 1 d. Dar galite tai padaryti iki rugpjūčio 20 d ir papasakokite apie savo patirtį su sprendimu DevOps metodo uždaviniai.
Sekite konferencijos kontrolinius punktus ir naujienas adresu и .
Šaltinis: www.habr.com