Veiligheidshelms

Die kern van die storie oor die gewildste pakketbestuurder vir Kubernetes kan met behulp van emoji uitgebeeld word:

• boks is Helm (dit is die mees geskikte ding in die nuutste weergawe van Emoji);
• slot - sekuriteit;
• die mens is die oplossing vir die probleem.

Trouens, alles sal 'n bietjie meer ingewikkeld wees, en die storie is vol tegniese besonderhede oor hoe hoe om Helm veilig te maak.

• Kortliks, wat is Helm, as jy nie geweet het of vergeet het nie. Watter probleme los dit op en waar is dit in die ekosisteem geleë.
• Oorweeg die Helm-argitektuur. Geen gesprek oor sekuriteit en hoe om 'n instrument of oplossing veiliger te maak is voltooi sonder om die argitektuur van die komponent te verstaan ​​nie.
• Kom ons bespreek Roerkomponente.
• Die brandendste vraag is die toekoms – die nuwe weergawe van Helm 3. 

Alles in hierdie artikel is van toepassing op Helm 2. Hierdie weergawe is tans in produksie en is heel waarskynlik die een wat jy tans gebruik, en dit is die een met sekuriteitsrisiko's.

Oor spreker: Alexander Khayorov (allexx) ontwikkel al vir 10 jaar en help om inhoud te verbeter Moskou Python Conf++ en by die komitee aangesluit Roerberaad. Nou werk hy in Chainstack as 'n ontwikkelingsleier - dit is 'n baster tussen 'n ontwikkelingsbestuurder en 'n persoon wat verantwoordelik is vir die lewering van finale vrystellings. Dit wil sê, dit is geleë op die terrein van vyandelikhede, waar alles gebeur van die skepping van 'n produk tot die werking daarvan.

Chainstack is 'n klein, aktief groeiende opstartonderneming wie se missie is om kliënte in staat te stel om te vergeet van die infrastruktuur en kompleksiteite van die bedryf van gedesentraliseerde toepassings, die ontwikkelingspan is in Singapoer geleë. Moenie Chainstack vra om cryptocurrency te verkoop of te koop nie, maar bied aan om oor ondernemingsblokkettingraamwerke te praat en hulle sal jou met graagte antwoord.

Helm

Dit is 'n pakket (grafiek) bestuurder vir Kubernetes. Die duidelikste en mees veelsydige manier om toepassings na 'n Kubernetes-kluster te bring.

Dit gaan natuurlik oor 'n meer strukturele en industriële benadering as om jou eie YAML-manifeste te skep en klein hulpprogramme te skryf.

Helm is die beste wat nou beskikbaar en gewild is.

Hoekom Helm? Hoofsaaklik omdat dit deur CNCF ondersteun word. Cloud Native is 'n groot organisasie en is die moedermaatskappy vir Kubernetes, etcd, Fluentd en ander.

Nog 'n belangrike feit is dat Helm 'n baie gewilde projek is. Toe ek in Januarie 2019 die eerste keer daaraan gedink het om te praat oor hoe om Helm veilig te maak, het die projek 'n duisend sterre op GitHub gehad. Teen Mei was daar 12 XNUMX van hulle.

Baie mense stel belang in Helm, so selfs as jy dit nog nie gebruik nie, sal dit nuttig wees om te weet van die sekuriteit daarvan. Veiligheid is belangrik.

Helm se kernspan word gerugsteun deur Microsoft Azure, en as sodanig is dit 'n redelik stabiele projek, anders as baie ander. Die vrystelling van Helm 3 Alpha 2 in die middel van Julie dui daarop dat heelwat mense aan die projek werk, en hulle het die begeerte en krag om Helm te ontwikkel en te verbeter.

Helm spreek verskeie worteltoepassingsbestuurprobleme in Kubernetes aan.

• Aansoek verpakking. Selfs 'n toepassing soos "Hello, World" op WordPress bestaan ​​reeds uit verskeie dienste, en hulle wil saam verpak word.
• Die bestuur van die kompleksiteit wat gepaard gaan met die bestuur van hierdie toepassings.
• 'n Lewensiklus wat nie eindig nadat die toepassing geïnstalleer of ontplooi is nie. Dit bly leef, dit moet opgedateer word, en Helm help hiermee en probeer om die regte maatreëls en beleide hiervoor te bring.

Verpakking op 'n verstaanbare manier gerangskik: daar is metadata in volle ooreenstemming met die werk van 'n konvensionele pakketbestuurder vir Linux, Windows of MacOS. Dit wil sê die bewaarplek, afhanklikhede van verskeie pakkette, meta-inligting vir toepassings, instellings, konfigurasiekenmerke, indekseringsinligting, ens. Al hierdie Helm laat jou toe om vir toepassings te kry en te gebruik.

Kompleksiteitsbestuur. As jy baie toepassings van dieselfde tipe het, is parameterisering nodig. Sjablone volg hieruit, maar om nie met jou eie manier vorendag te kom om sjablone te skep nie, kan jy wat Helm bied uit die boks gebruik.

Toepassingslewensiklusbestuur - na my mening is dit die interessantste en onopgeloste kwessie. Dit is hoekom ek op 'n tyd na Helm gekom het. Ons moes tred hou met die toepassing lewensiklus, ons wou ons CI / CD en toepassing siklusse in hierdie paradigma skuif.

Roer stel jou in staat om:

• bestuur ontplooiings, stel die konsep van konfigurasie en hersiening bekend;
• terugrol suksesvol uit te voer;
• gebruik hake vir verskillende geleenthede;
• voeg bykomende aansoekkontroles by en reageer op hul resultate.

Verder Roer het "batterye" - 'n groot aantal heerlike dinge wat in die vorm van plugins ingesluit kan word, wat u lewe vereenvoudig. Inproppe kan onafhanklik geskryf word, hulle is redelik geïsoleer en vereis nie 'n samehangende argitektuur nie. As jy iets wil implementeer, beveel ek aan om dit as 'n inprop te doen, en dit dan moontlik in die stroomop in te sluit.

Roer is gebaseer op drie hoofkonsepte:

• Grafiek Repos - beskrywing en verskeidenheid van parameterisering moontlik vir jou manifes. 
• Config - dit wil sê die waardes wat toegepas moet word (teks, numeriese waardes, ens.).
• Release versamel die twee boonste komponente, en saam verander dit in Release. Vrystellings kan weergegee word, waardeur die organisasie van die lewensiklus bereik word: klein ten tye van installasie en groot ten tyde van opgradering, afgradering of terugrol.

Roer argitektuur

Die diagram beeld die hoëvlakargitektuur van Helm konseptueel uit.

Laat ek jou daaraan herinner dat Helm iets is wat met Kubernetes verband hou. Daarom kan ons nie sonder 'n Kubernetes-kluster (reghoek) klaarkom nie. Die kube-apiserver-komponent is op die meester. Sonder Helm het ons Kubeconfig. Helm bring een klein binêre, as jy dit so kan noem, Helm CLI nut, wat op 'n rekenaar, skootrekenaar, hoofraam geïnstalleer is - enigiets.

Maar dit is nie genoeg nie. Helm het 'n bedienerkomponent genaamd Tiller. Hy verteenwoordig Helm binne die cluster, en is 'n toepassing binne 'n Kubernetes-kluster soos enige ander.

Die volgende Chart Repo-komponent is 'n bewaarplek met kaarte. Daar is 'n amptelike bewaarplek, en daar kan 'n private bewaarplek van 'n maatskappy of projek wees.

Interaksie

Kom ons kyk hoe die argitektuurkomponente interaksie het wanneer ons 'n toepassing met Helm wil installeer.

• Ons praat Helm install, kry toegang tot die bewaarplek (Chart Repo) en kry die Helm-grafiek.

• Die Helm-hulpprogram (Helm CLI) is in wisselwerking met Kubeconfig om uit te vind na watter groep om te verwys. 
• Nadat hierdie inligting ontvang is, spreek die hulpprogram Tiller, wat in ons groepie geleë is, reeds as 'n toepassing aan. 
• Tiller roep Kube-apiserver om aksies in Kubernetes uit te voer, 'n paar voorwerpe te skep (dienste, peule, replikas, geheime, ens.).

Vervolgens sal ons die skema kompliseer om die aanvalvektor te sien waaraan die Helm-argitektuur as geheel blootgestel kan word. En dan sal ons haar probeer beskerm.

Aanval vektor

Die eerste potensiële swakheid is bevoorregte API-gebruiker. As deel van die skema is dit 'n hacker wat admin-toegang tot die Helm CLI verkry het.

Onbevoorregte API-gebruiker kan ook 'n gevaar wees as dit iewers naby is. So 'n gebruiker sal 'n ander konteks hê, byvoorbeeld, dit kan in een groep naamruimte in die Kubeconfig-instellings reggemaak word.

Die interessantste aanvalvektor kan 'n proses wees wat binne-in die groep iewers naby Tiller is en toegang daartoe het. Dit kan 'n webbediener of 'n mikrodiens wees wat die netwerkomgewing van die groepie sien.

'n Eksotiese, maar toenemend gewilde variant van die aanval hou verband met Chart Repo. 'n Grafiek wat deur 'n gewetenlose skrywer geskep is, kan 'n onveilige hulpbron bevat, en jy sal dit op geloof volg. Of hy kan die grafiek vervang wat jy van die amptelike bewaarplek aflaai, en byvoorbeeld 'n hulpbron in die vorm van beleide skep en toegang tot homself eskaleer.

Kom ons probeer om aanvalle van al hierdie vier kante te beveg en uit te vind waar daar probleme in die Helm-argitektuur is, en waar dit miskien nie is nie.

Kom ons vergroot die skema, voeg meer elemente by, maar hou al die basiese komponente.

Helm CLI kommunikeer met Chart Repo, interaksie met Kubeconfig, werk word oorgedra na die cluster na die Tiller-komponent.

Tiller word deur twee voorwerpe voorgestel:

• Tiller-ontplooi svc, wat 'n sekere diens blootlê;
• Tiller-ontplooi peul (in die diagram in 'n enkele geval in een replika), waarop die hele vrag loop, wat toegang tot die groep kry.

Vir interaksie word verskillende protokolle en skemas gebruik. Uit 'n sekuriteitsoogpunt stel ons die meeste belang in:

• Die meganisme waardeur Helm CLI toegang tot die grafiek repo verkry: wat is die protokol, is daar verifikasie, en wat kan daaromtrent gedoen word.
• Die protokol waarvolgens die Helm CLI, met behulp van kubectl, met Tiller kommunikeer. Dit is 'n RPC-bediener wat binne die groep geïnstalleer is.
• Tiller self is beskikbaar vir mikrodienste wat in die groepering is en in wisselwerking met Kube-apiserver is.

Kom ons bespreek elkeen van hierdie areas om die beurt.

RBAC

Dit is nutteloos om oor enige sekuriteit vir Helm of enige ander diens binne die groep te praat, tensy RBAC geaktiveer is.

Dit blyk dat dit nie die mees onlangse aanbeveling is nie, maar ek is seker dat baie nog nie RBAC in produksie geaktiveer het nie, want dit is baie ophef en daar is baie om te konfigureer. Ek versoek u egter om dit te doen.

https://rbac.dev/ - terreinprokureur vir RBAC. Daar is 'n groot hoeveelheid interessante materiaal daar versamel wat jou sal help om RBAC op te stel, te wys hoekom dit goed is en hoe om in beginsel daarmee saam te leef in produksie.

Ek sal probeer verduidelik hoe Tiller en RBAC werk. Tiller loop binne die cluster onder 'n sekere diensrekening. Tipies, as RBAC nie gekonfigureer is nie, sal dit die supergebruiker wees. In die basiese konfigurasie sal Tiller die admin wees. Daarom word daar dikwels gesê dat Tiller 'n SSH-tonnel na jou cluster is. Trouens, dit is die geval, so jy kan 'n aparte gespesialiseerde diensrekening gebruik in plaas van die verstekdiensrekening in die diagram hierbo.

Wanneer jy Helm inisialiseer die eerste keer dat jy dit op 'n bediener installeer, kan jy 'n diensrekening opstel met --service-account. Dit sal jou toelaat om 'n gebruiker met die minimum vereiste stel regte te gebruik. Dit is waar, jy sal so 'n "krans" moet skep: Rol en Rolbinding.

Ongelukkig sal Helm dit nie vir jou doen nie. Jy of jou Kubernetes-klusteradministrateur moet vooraf 'n stel Rol, Rolbinding voorberei vir die diensrekening om die stuur te slaag.

Die vraag ontstaan ​​- wat is die verskil tussen Rol en ClusterRole? Die verskil is dat ClusterRole vir alle naamruimtes werk, in teenstelling met gewone Rol- en Rolbinding, wat net vir gespesialiseerde naamruimtes werk. Jy kan beleide vir die hele groepering en alle naamruimtes opstel, sowel as gepersonaliseer vir elke naamruimte individueel.

Dit is die moeite werd om te noem dat RBAC nog 'n groot probleem oplos. Baie kla dat Helm ongelukkig nie multitenancy is nie (ondersteun nie multitenancy nie). As verskeie spanne 'n kluster verbruik en Helm gebruik, is dit in beginsel onmoontlik om beleide op te stel en hul toegang binne hierdie cluster te onderskei, want daar is 'n sekere diensrekening waaruit Helm loop, en dit skep al die hulpbronne in die cluster van onder dit, wat soms baie ongemaklik. Dit is waar - as 'n binêre lêer self, as 'n proses, Helm Tiller het geen idee van multitenancy nie.

Daar is egter 'n wonderlike manier waarmee jy Tiller verskeie kere in 'n groep kan hardloop. Daar is geen probleem hiermee nie, Tiller kan in elke naamruimte bestuur word. U kan dus RBAC, Kubeconfig as 'n konteks gebruik en toegang tot 'n spesiale stuur beperk.

Dit sal so lyk.

Daar is byvoorbeeld twee Kubeconfigs met konteks vir verskillende spanne (twee naamruimtes): X-span vir die ontwikkelingspan en 'n administrasiekluster. Die administrasiegroepering het sy eie wye Tiller, wat onderskeidelik in die Kube-stelsel naamruimte, gevorderde diensrekening geleë is. En 'n aparte naamruimte vir die ontwikkelingspan, hulle sal hul dienste na 'n spesiale naamruimte kan ontplooi.

Dit is 'n werkbenadering, Tiller is nie so vraatsug dat dit jou begroting grootliks kan beïnvloed nie. Dit is een van die vinnige oplossings.

Konfigureer gerus Tiller afsonderlik en voorsien Kubeconfig van konteks vir 'n span, vir 'n spesifieke ontwikkelaar, of vir die omgewing: Dev, Staging, Production (dit is te betwyfel dat alles op dieselfde cluster sal wees, dit kan egter gedoen word) .

Ons gaan voort met ons storie, kom ons skakel van RBAC af en praat oor ConfigMaps.

ConfigMaps

Helm gebruik ConfigMaps as sy datastoor. Toe ons oor argitektuur gepraat het, was daar nêrens 'n databasis wat inligting oor vrystellings, konfigurasies, terugskrywings, ens sou stoor nie. ConfigMaps word hiervoor gebruik.

Die grootste probleem met ConfigMaps is bekend - hulle is in beginsel nie veilig nie, hulle nie in staat is om sensitiewe data te stoor nie. Ons praat oor alles wat nie verder as die diens moet kom nie, byvoorbeeld wagwoorde. Die mees inheemse manier vir Helm op die oomblik is om van die gebruik van ConfigMaps na geheime te beweeg.

Dit word baie eenvoudig gedoen. Ignoreer die Tiller-instelling en spesifiseer dat die berging geheime sal wees. Dan sal jy vir elke ontplooiing nie 'n ConfigMap ontvang nie, maar 'n geheim.

Jy mag dalk redeneer dat geheime self 'n vreemde konsep is en nie baie veilig nie. Dit moet egter verstaan ​​word dat die Kubernetes-ontwikkelaars dit self doen. Vanaf weergawe 1.10, d.w.s. vir 'n lang tyd, is dit moontlik, ten minste in openbare wolke, om die korrekte berging te koppel om geheime te stoor. Nou werk die span aan hoe om toegang tot geheime, individuele peule of ander entiteite selfs beter te versprei.

Dit is beter om Storage Helm in geheime te vertaal, en dit op sy beurt sentraal te beveilig.

Natuurlik sal dit bly 1 MB databerginglimiet. Helm gebruik hier etcd as 'n verspreide bewaarplek vir ConfigMaps. En daar het hulle gedink dit is 'n geskikte data-stuk vir replikasies, ens. Daar is 'n interessante bespreking op Reddit hieroor, ek beveel aan om hierdie snaakse leesstuk vir die naweek te vind of die druk te lees hier.

Grafiek Repos

Grafieke is die sosiaal kwesbaarste en kan 'n bron van "Man in die middel" word, veral as jy 'n voorraadoplossing gebruik. Eerstens praat ons van bewaarplekke wat via HTTP blootgestel word.

Beslis, jy moet Helm Repo blootstel oor HTTPS - dit is die beste opsie en is goedkoop.

gee aandag aan grafiek handtekening meganisme. Die tegnologie is maklik om te skande. Dit is dieselfde as wat jy op GitHub gebruik, 'n normale PGP-masjien met publieke en private sleutels. Stel op en maak seker, met die regte sleutels en teken alles, dat dit regtig jou grafiek is.

Daarbenewens, Helm-kliënt ondersteun TLS (nie in die sin van HTTP vanaf die bedienerkant nie, maar wedersydse TLS). Jy kan bediener- en kliëntsleutels gebruik om te kommunikeer. Om eerlik te wees, ek gebruik nie so 'n meganisme nie weens my afkeer vir wedersydse sertifikate. Basies, kaartmuseum - die hoofinstrument om Helm Repo vir Helm 2 in te stel - ondersteun ook basiese auth. Jy kan basiese verifikasie gebruik as dit geriefliker en stiller is.

Daar is ook 'n inprop helm-gcs, wat jou toelaat om Chart Repos op Google Cloud Storage aan te bied. Dit is redelik gerieflik, werk uitstekend en is veilig genoeg, want al die beskryfde meganismes word benut.

As jy HTTPS of TLS aktiveer, mTLS gebruik, basiese autifikasie aktiveer om die risiko's verder te verminder, sal jy 'n veilige kommunikasiekanaal vir Helm CLI en Chart Repo kry.

gRPC API

Die volgende stap is baie verantwoordelik - om Tiller, wat in die cluster geleë is en aan die een kant 'n bediener is, te beveilig, aan die ander kant kry dit toegang tot ander komponente en probeer om voor te gee dat hy iemand is.

Soos ek gesê het, Tiller is 'n diens wat gRPC blootstel, die Helm-kliënt kom daarheen via gRPC. By verstek is TLS natuurlik gedeaktiveer. Hoekom dit gedoen word, is 'n debatteerbare vraag, lyk dit vir my, om die opstelling aan die begin te vereenvoudig.

Vir produksie en selfs vir opvoering, beveel ek aan om TLS op gRPC te aktiveer.

Na my mening, anders as mTLS vir kaarte, is dit hier gepas en word dit baie eenvoudig gedoen - genereer 'n PQI-infrastruktuur, skep 'n sertifikaat, hardloop Tiller, dra die sertifikaat oor tydens inisialisering. Daarna kan jy alle Helm-opdragte uitvoer, voorgee dat dit die gegenereerde sertifikaat en private sleutel is.

U sal u dus beskerm teen alle versoeke aan Tiller van buite die groep.

So, ons het die verbindingskanaal aan Tiller beveilig, het reeds RBAC bespreek en die regte van die Kubernetes apiserver aangepas, die domein waarmee dit kan interaksie verminder, verminder.

Beskermde Roer

Kom ons kyk na die finale diagram. Dit is dieselfde argitektuur met dieselfde pyle.

Alle verbindings kan nou veilig in groen geteken word:

• vir Chart Repo gebruik ons ​​TLS of mTLS en basiese auth;
• mTLS vir Tiller, en dit word as 'n gRPC-diens met TLS blootgestel, ons gebruik sertifikate;
• die groepering gebruik 'n spesiale diensrekening met Rol- en Rolbinding. 

Ons het die groep merkbaar beveilig, maar iemand slim het gesê:

"Daar kan net een absoluut veilige oplossing wees - 'n afgeskakelde rekenaar, wat in 'n betonkas geleë is en deur soldate bewaak word."

Daar is verskillende maniere om data te manipuleer en nuwe aanvalsvektore te vind. Ek is egter vol vertroue dat hierdie aanbevelings jou sal toelaat om die basiese industriestandaard vir sekuriteit te implementeer.

Bonus

Hierdie deel hou nie direk verband met sekuriteit nie, maar dit sal ook nuttig wees. Ek sal jou 'n paar interessante dinge wys waarvan min mense weet. Byvoorbeeld, hoe om na kaarte te soek - amptelik en nie-amptelik.

In die bewaarplek github.com/helm/charts nou is daar ongeveer 300 kaarte en twee strome: stal en broeikas. Enigiemand wat bydra, weet baie goed hoe moeilik dit is om van broeikas na stal te kom, en hoe maklik dit is om uit die stal te vlieg. Dit is egter nie die beste hulpmiddel om kaarte vir Prometheus en wat ook al jy wil te vind nie, om een ​​eenvoudige rede - dit is nie 'n gerieflike portaal om na pakkette te soek nie.

Maar daar is 'n diens hub.helm.sh, waarmee dit baie geriefliker is om kaarte te vind. Die belangrikste is dat daar baie meer eksterne bewaarplekke en byna 800 sjarme beskikbaar is. Boonop kan u u bewaarplek koppel as u om een ​​of ander rede nie u kaarte na stabiel wil indien nie.

Probeer hub.helm.sh en kom ons ontwikkel dit saam. Hierdie diens is onder 'n Helm-projek en jy kan selfs bydra tot sy UI as jy 'n frontend is en net die voorkoms wil verbeter.

Ek wil ook u aandag vestig op Maak Service Broker API-integrasie oop. Dit klink omslagtig en onverstaanbaar, maar dit los die probleme op waarmee almal te kampe het. Kom ek verduidelik met 'n eenvoudige voorbeeld.

Ons het 'n Kubernetes-kluster waar ons 'n klassieke WordPress-toepassing wil laat loop. As 'n reël is 'n databasis nodig vir volle funksionaliteit. Daar is baie verskillende oplossings, byvoorbeeld, jy kan jou eie staatvolle diens bestuur. Dit is nie baie gerieflik nie, maar baie mense doen dit.

Ander, soos ons by Chainstack, gebruik bestuurde databasisse soos MySQL of PostgreSQL vir bedieners. Daarom is ons databasisse iewers in die wolk geleë.

Maar 'n probleem ontstaan: ons moet ons diens met die databasis koppel, 'n smaak van die databasis skep, die geloofsbriewe deurgee en dit op een of ander manier bestuur. Dit alles word gewoonlik met die hand deur 'n stelseladministrateur of ontwikkelaar gedoen. En daar is geen probleem as daar min toepassings is nie. As daar baie van hulle is, het jy 'n stroper nodig. Daar is so 'n kombinasie - dit is Service Broker. Dit laat jou toe om 'n spesiale inprop vir 'n publieke wolkkluster te gebruik en hulpbronne van 'n verskaffer deur 'n makelaar te bestel, asof dit 'n API is. Om dit te doen, kan u inheemse Kubernetes-nutsgoed gebruik.

Dit is baie eenvoudig. U kan byvoorbeeld Managed MySQL op Azure versoek met 'n basisvlak (dit kan gekonfigureer word). Deur die Azure API te gebruik, sal die databasis geskep en gereed wees vir gebruik. Jy hoef nie hiermee in te meng nie, die inprop is hiervoor verantwoordelik. Byvoorbeeld, OSBA (Azure-inprop) sal geloofsbriewe aan diens terugstuur, dit aan Helm gee. Jy sal WordPress met wolk MySQL kan gebruik, glad nie met bestuurde databasisse omgaan nie, en nie bekommerd wees oor staatsvolle dienste binne nie.

Ons kan sê dat Helm optree as 'n gom wat u aan die een kant toelaat om dienste te ontplooi, en aan die ander kant die hulpbronne van wolkverskaffers verbruik.

Jy kan jou eie inprop skryf en al hierdie geskiedenis op die perseel gebruik. Dan sal jy eenvoudig jou eie inprop vir die korporatiewe Wolk-verskaffer hê. Ek raai jou aan om hierdie benadering te probeer, veral as jy 'n groot skaal het en vinnig ontwikkelaar, staging of die hele infrastruktuur vir 'n kenmerk wil ontplooi. Dit sal die lewe makliker maak vir jou bedrywighede of DevOps.

Nog 'n vonds wat ek reeds genoem het, is helm-gcs-inprop, wat jou toelaat om Google-emmers (voorwerpberging) te gebruik om Helm-kaarte te stoor.

Jy benodig net vier opdragte om dit te begin gebruik:

1. installeer die inprop;
2. inisieer dit;
3. stel die pad na die emmer, wat in gcp is;
4. publiseer kaarte op die standaard manier.

Die skoonheid is dat die inheemse gcp-metode vir magtiging gebruik sal word. Jy kan 'n diensrekening, 'n ontwikkelaarrekening, wat ook al gebruik. Dit is baie gerieflik en kos niks om te bedryf nie. As jy, soos ek, die opsless-filosofie bevorder, sal dit baie gerieflik wees, veral vir klein spanne.

alternatiewe

Helm is nie die enigste diensbestuuroplossing nie. Daar is baie vrae aan hom, en dit is waarskynlik hoekom die derde weergawe so vinnig verskyn het. Natuurlik is daar alternatiewe.

Dit kan óf gespesialiseerde oplossings soos Ksonnet of Metaparticle wees. Jy kan jou klassieke infrastruktuurbestuurnutsmiddels (Ansible, Terraform, Chef, ens.) gebruik vir dieselfde doeleindes wat ek genoem het.

Uiteindelik is daar 'n oplossing operateur raamwerkwat in gewildheid toeneem.

Die operateursraamwerk is die belangrikste alternatief om na uit te kyk.

Dit is meer inheems aan CNCF en Kubernetes, maar die versperring vir toegang is baie hoër, moet jy meer kodeer en manifeste minder beskryf.

Daar is verskeie byvoegings, soos Draft, Scaffold. Hulle maak die lewe baie makliker, byvoorbeeld, hulle vereenvoudig die siklus vir ontwikkelaars om Helm te stuur en uit te voer om 'n toetsomgewing te ontplooi. Ek sou hulle bemagtigers noem.

Hier is 'n visuele grafiek van waar alles is.

Die abskis is die vlak van jou persoonlike beheer oor wat gebeur, die ordinaat is die vlak van Kubernetes inheemsheid. Helm weergawe 2 is iewers tussenin. In weergawe 3, nie groot nie, maar beide die beheer en die vlak van inheemsheid is verbeter. Ksonnet-vlak oplossings is steeds minderwaardig selfs aan Helm 2. Dit is egter die moeite werd om te kyk om te weet wat daar nog in hierdie wêreld is. Natuurlik sal u konfigurasiebestuurder onder u beheer wees, maar dit is absoluut nie inheems aan Kubernetes nie.

Die operateursraamwerk is absoluut inheems aan Kubernetes en laat jou toe om dit baie meer elegant en noukeuriger te bestuur (maar hou die toegangsvlak in gedagte). Dit is eerder geskik vir 'n gespesialiseerde toepassing en die skep van 'n bestuur daarvoor, eerder as 'n massakombinasie om 'n groot aantal toepassings met Helm te verpak.

Uitbreiders verbeter net effens beheer, vul werkvloei aan, of sny hoeke op CI/CD-pyplyne.

Toekomstige Helms

Die goeie nuus is dat Helm 3 kom. Die alfa-weergawe van Helm 3.0.0-alpha.2 is reeds vrygestel, jy kan dit probeer. Dit is redelik stabiel, maar die funksionaliteit is steeds beperk.

Hoekom het jy Helm 3 nodig? Eerstens is dit 'n storie oor Tiller se verdwyning, as 'n komponent. Dit, soos u reeds verstaan, is 'n groot stap vorentoe, want vanuit die oogpunt van die veiligheid van die argitektuur is alles vereenvoudig.

Toe Helm 2 geskep is, wat gedurende die Kubernetes 1.8 dae of selfs vroeër was, was baie van die konsepte onvolwasse. Byvoorbeeld, die CRD-konsep word nou aktief geïmplementeer, en Helm sal gebruik CRDstrukture te stoor. Dit sal moontlik wees om slegs die kliënt te gebruik en nie die bedienerdeel te behou nie. Gebruik dus inheemse Kubernetes-opdragte om met strukture en hulpbronne te werk. Dit is 'n groot stap vorentoe.

Sal verskyn ondersteuning vir inheemse OCI-bewaarplekke (Open Container Initiative). Dit is 'n groot inisiatief, en Helm stel hoofsaaklik belang om hul kaarte te plaas. Dit kom by die punt dat Docker Hub byvoorbeeld baie OCI-standaarde ondersteun. Ek raai nie, maar miskien sal die klassieke Docker-bewaarplekverskaffers jou toelaat om hul Helm-kaarte te huisves.

’n Omstrede storie vir my is Lua ondersteuning, as 'n sjabloonenjin vir die skryf van skrifte. Ek is nie 'n groot aanhanger van Lua nie, maar dit sal heeltemal opsioneel wees. Ek het dit 3 keer nagegaan - dit sal nie nodig wees om Lua te gebruik nie. So wie ook al Lua wil kan gebruik, wie van Go hou, sluit aan by ons groot kamp en gebruik go-tmpl daarvoor.

Ten slotte, wat ek beslis gemis het, was voorkoms van die skema en validering van datatipes. Daar sal nie meer probleme met int of string wees nie, dit is nie nodig om nul in dubbele aanhalingstekens te draai nie. 'n JSONS-skema sal verskyn wat jou sal toelaat om dit eksplisiet vir waardes te beskryf.

Sal sterk herwerk word gebeurtenis-gedrewe model. Dit is reeds gekonseptualiseer. Kyk na die Helm 3-tak en jy sal sien hoeveel gebeurtenisse en haakplekke en ander dinge bygevoeg is, wat aansienlik vereenvoudig en, aan die ander kant, beheer oor die ontplooiingsprosesse en reaksies daarop toevoeg.

Helm 3 sal makliker, veiliger en interessanter wees, nie omdat ons nie van Helm 2 hou nie, maar omdat Kubernetes meer gevorderd word. Gevolglik kan Helm Kubernetes-ontwikkelings gebruik en uitstekende bestuurders vir Kubernetes daarop skep.

Nog goeie nuus is dat die DevOpsConf Alexander Khayorov sal vertel kan houers veilig wees? Onthou dat die konferensie oor die integrasie van ontwikkelings-, toets- en bedryfsprosesse in Moskou gehou sal word 30 September en 1 Oktober. Jy kan nog tot 20 Augustus gee n verslag in en vertel van jou ervaring een van vele take van die DevOps-benadering.

Volg die konferensie kontrolepunte en nuus in poslys и telegram kanaal.

Bron: will.com