De essinsje fan it ferhaal oer de populêrste pakketbehearder foar Kubernetes koe wurde ôfbylde mei in emoji:
- de doaze is Helm (dat is it tichtst by de lêste Emoji release);
- slot - feiligens;
- de lytse man is de oplossing foar it probleem.
Yn feite, alles sil wêze in bytsje mear yngewikkelder, en it ferhaal is fol mei technyske details oer Hoe meitsje Helm feilich.
- Koartsein wat Helm is foar it gefal dat jo net wisten of fergeaten. Hokker problemen lost it op en wêr sit it yn it ekosysteem.
- Litte wy nei de Helm-arsjitektuer sjen. Gjin petear oer feiligens en hoe't jo in ark of oplossing feiliger meitsje kinne is kompleet sûnder de arsjitektuer fan 'e komponint te begripen.
- Litte wy de Helm-komponinten beprate.
- De meast baarnende fraach is de takomst - de nije ferzje fan Helm 3.
Alles yn dit artikel jildt foar Helm 2. Dizze ferzje is op it stuit yn produksje en is nei alle gedachten dejinge dy't jo op it stuit brûke, en it is de ferzje dy't de feiligensrisiko's befettet.
Oer de sprekker: Alexander Khayorov () hat ûntwikkele foar 10 jier, helpt om ynhâld te ferbetterjen en kaam by de kommisje . No wurket hy by Chainstack as ûntwikkelingslieder - dit is in hybride tusken in ûntwikkelingsmanager en in persoan dy't ferantwurdlik is foar it leverjen fan definitive releases. Dat is, it leit op it slachfjild, wêr't alles bart fan 'e skepping fan in produkt oant syn operaasje.
Chainstack is in lyts, aktyf groeiende startup waans missy is om kliïnten te ferjitten oer de ynfrastruktuer en kompleksiteiten fan it operearjen fan desintralisearre applikaasjes; it ûntwikkelteam sit yn Singapore. Freegje Chainstack net om cryptocurrency te ferkeapjen of te keapjen, mar biede oan om te praten oer blockchain-kaders foar bedriuwen, en se sille jo lokkich antwurdzje.
Roer
Dit is in pakket (grafyk) manager foar Kubernetes. De meast yntuïtive en universele manier om applikaasjes nei in Kubernetes-kluster te bringen.
Wy prate fansels oer in mear strukturele en yndustriële oanpak dan it meitsjen fan jo eigen YAML-manifesten en it skriuwen fan lytse nutsbedriuwen.
Helm is de bêste dy't op it stuit beskikber en populêr is.
Wêrom Helm? Foaral om't it wurdt stipe troch de CNCF. Cloud Native is in grutte organisaasje en is it memmebedriuw foar projekten Kubernetes, etcd, Fluentd en oaren.
In oar wichtich feit is dat Helm in heul populêr projekt is. Doe't ik yn jannewaris 2019 begon te praten oer hoe Helm feilich te meitsjen, hie it projekt tûzen stjerren op GitHub. Tsjin maaie wiene dat der 12 tûzen.
In protte minsken binne ynteressearre yn Helm, dus sels as jo it noch net brûke, sille jo profitearje fan it witten oer de feiligens. Feiligens is wichtich.
It kearn Helm-team wurdt stipe troch Microsoft Azure en is dêrom in frij stabyl projekt, yn tsjinstelling ta in protte oaren. De frijlitting fan Helm 3 Alpha 2 mids july jout oan dat d'r nochal in protte minsken wurkje oan it projekt, en se hawwe de winsk en enerzjy om Helm te ûntwikkeljen en te ferbetterjen.
Helm lost ferskate rootproblemen fan applikaasjebehear yn Kubernetes op.
- Applikaasje ferpakking. Sels in applikaasje lykas "Hallo, wrâld" op WordPress bestiet al út ferskate tsjinsten, en jo wolle se byinoar pakke.
- Behear fan de kompleksiteit dy't komt mei it behearen fan dizze applikaasjes.
- In libbenssyklus dy't net einiget neidat de applikaasje is ynstalleare of ynset. It bliuwt libjen, it moat bywurke wurde, en Helm helpt hjirmei en besiket hjirfoar de goede maatregels en belied te bringen.
Bagging it is op in dúdlike manier organisearre: d'r binne metadata yn folsleine oerienstimming mei it wurk fan in gewoane pakketbehearder foar Linux, Windows of MacOS. Dat is, in repository, ôfhinklikens fan ferskate pakketten, meta-ynformaasje foar applikaasjes, ynstellings, konfiguraasjefunksjes, ynformaasjeyndeksearring, ensfh. Helm lit jo dit alles krije en brûke foar applikaasjes.
Complexity Management. As jo in protte applikaasjes fan itselde type hawwe, dan is parameterisaasje nedich. Sjabloanen komme hjirfan, mar om foar te kommen dat jo jo eigen manier moatte betinke om sjabloanen te meitsjen, kinne jo brûke wat Helm út 'e doaze biedt.
Applikaasje Lifecycle Management - yn myn miening is dit de meast nijsgjirrige en ûnbeheinde fraach. Dit is de reden dat ik yn 'e dei werom nei Helm kaam. Wy moasten de libbenssyklus fan 'e applikaasje yn 'e gaten hâlde en woene ús CI / CD en applikaasjesyklusen nei dit paradigma ferpleatse.
Helm lit jo:
- beheare ynset, yntrodusearret it konsept fan konfiguraasje en revyzje;
- mei súkses útfiere rollback;
- haken brûke foar ferskate eveneminten;
- tafoegje oanfoljende applikaasjekontrôles en reagearje op har resultaten.
Oanfoljend Helm hat "batterijen" - in grut oantal lekkere dingen dy't kinne wurde opnommen yn 'e foarm fan plugins, dy't jo libben ferienfâldigje. Plugins kinne selsstannich skreaun wurde, se binne frij isolearre en hawwe gjin harmonieuze arsjitektuer nedich. As jo wat wolle ymplementearje, advisearje ik it te dwaan as in plugin, en dan mooglik yn 'e streamop te nimmen.
Helm is basearre op trije haadbegripen:
- Grafyk fan 'e Repo - beskriuwing en array fan parameterisaasjes mooglik foar jo manifest.
- Konfig -dat is de wearden dy't sille wurde tapast (tekst, numerike wearden, ensfh.).
- release sammelet de twa boppeste komponinten, en tegearre se feroarje yn Release. Releases kinne ferzje wurde, en dêrmei in organisearre libbenssyklus te berikken: lyts op 'e tiid fan ynstallaasje en grut op' e tiid fan upgrade, downgrade of rollback.
Helm arsjitektuer
It diagram ferbyldet konseptueel de arsjitektuer op hege nivo fan Helm.
Lit my jo herinnerje dat Helm wat is relatearre oan Kubernetes. Dêrom kinne wy net dwaan sûnder in Kubernetes kluster (rjochthoek). De kube-apiserver-komponint sit op 'e master. Sûnder Helm hawwe wy Kubeconfig. Helm bringt ien lyts binêr, as jo it sa kinne neame, Helm CLI-hulpprogramma, dat is ynstalleare op in kompjûter, laptop, mainframe - op alles.
Mar dit is net genôch. Helm hat in tsjinner komponint neamd Tiller. It fertsjintwurdiget de belangen fan Helm binnen it kluster; it is in applikaasje binnen it Kubernetes-kluster, krekt as elke oare.
De folgjende komponint fan Chart Repo is in repository mei charts. D'r is in offisjele repository, en d'r kin in privee repository wêze fan in bedriuw of projekt.
Ynteraksje
Litte wy sjen nei hoe't de arsjitektuerkomponinten ynteraksje as wy in applikaasje wolle ynstallearje mei Helm.
- Wy prate
Helm install, tagong ta de repository (Chart Repo) en krije in Helm-diagram.
- It Helm-hulpprogramma (Helm CLI) ynteraksje mei Kubeconfig om út te finen hokker kluster kontakt moat wurde.
- Nei it ûntfangen fan dizze ynformaasje ferwiist it nut nei Tiller, dy't yn ús kluster leit, as in applikaasje.
- Tiller neamt Kube-apiserver om aksjes yn Kubernetes út te fieren, guon objekten te meitsjen (tsjinsten, pods, replika's, geheimen, ensfh.).
Folgjende sille wy it diagram komplisearje om de oanfalvektor te sjen dat de heule Helm-arsjitektuer as gehiel kin wurde bleatsteld oan. En dan sille wy besykje har te beskermjen.
Attack vector
It earste potinsjele swakke punt is befoarrjochte API-brûker. As ûnderdiel fan it skema is dit in hacker dy't admin tagong hat krigen ta de Helm CLI.
Unprivileged API brûker kin ek in gefaar foarmje as it earne yn de buert is. Sa'n brûker sil in oare kontekst hawwe, hy kin bygelyks fêstlein wurde yn ien klusternammeromte yn 'e Kubeconfig-ynstellingen.
De meast nijsgjirrige oanfal vector kin in proses dat leit binnen in kluster earne tichtby Tiller en kin tagong ta it. Dit kin in webtsjinner of mikrotsjinst wêze dy't de netwurkomjouwing fan it kluster sjocht.
In eksoatyske, mar hieltyd populêrder, oanfalsfariant omfettet Chart Repo. In diagram makke troch in gewetenloze auteur kin ûnfeilige boarnen befetsje, en jo sille it foltôgje troch it te leauwen. Of it kin it diagram ferfange dat jo downloade fan 'e offisjele repository en, bygelyks, in boarne meitsje yn' e foarm fan belied en de tagong eskalearje.
Litte wy besykje oanfallen fan al dizze fjouwer kanten ôf te fjochtsjen en út te finen wêr't problemen binne yn 'e Helm-arsjitektuer, en wêr't miskien gjin binne.
Litte wy it diagram fergrutsje, mear eleminten tafoegje, mar alle basiskomponinten hâlde.
De Helm CLI kommunisearret mei de Chart Repo, ynteraksje mei Kubeconfig, en it wurk wurdt oerbrocht nei it kluster nei de Tiller-komponint.
Tiller wurdt fertsjintwurdige troch twa objekten:
- Tiller-deploy svc, dy't in bepaalde tsjinst bleatsteld;
- Tiller-deploy pod (yn it diagram yn ien kopy yn ien replika), dêr't de hiele lading rint, dy't tagong ta it kluster.
Ferskillende protokollen en skema's wurde brûkt foar ynteraksje. Ut in feiligens eachpunt, wy binne meast ynteressearre yn:
- It meganisme wêrmei't de Helm CLI tagong hat ta de kaartrepo: hokker protokol, is d'r autentikaasje en wat kin dermei dien wurde.
- It protokol wêrmei Helm CLI, mei help fan kubectl, kommunisearret mei Tiller. Dit is in RPC-tsjinner ynstalleare yn it kluster.
- Tiller sels is tagonklik foar mikrotsjinsten dy't yn it kluster wenje en ynteraksje mei de Kube-apiserver.
Litte wy al dizze gebieten yn oarder besprekke.
RBAC
D'r hat gjin punt om te praten oer feiligens foar Helm of in oare tsjinst binnen it kluster, útsein as RBAC ynskeakele is.
It liket derop dat dit net de lêste oanbefelling is, mar ik bin der wis fan dat in protte minsken noch RBAC sels yn produksje net ynskeakele hawwe, om't it in protte gedoe is en in protte dingen moatte wurde konfigureare. Ik moedigje jo lykwols oan dit te dwaan.
- webside advokaat foar RBAC. It befettet in enoarme hoemannichte nijsgjirrige materialen dy't jo sille helpe om RBAC yn te stellen, sjen te litten wêrom't it goed is en hoe't jo der yn prinsipe mei libje kinne yn produksje.
Ik sil besykje út te lizzen hoe't Tiller en RBAC wurkje. Tiller wurket binnen it kluster ûnder in bepaalde tsjinst account. Typysk, as RBAC net is ynsteld, sil dit de superbrûker wêze. Yn 'e basiskonfiguraasje sil Tiller in admin wêze. Dit is wêrom it wurdt faak sein dat Tiller is in SSH tunnel nei jo kluster. Yn feite is dit wier, dus jo kinne in apart tawijd tsjinstaccount brûke ynstee fan it Standerttsjinstakkount yn it diagram hjirboppe.
As jo Helm inisjalisearje en it foar it earst op 'e tsjinner ynstallearje, kinne jo it tsjinstkonto ynstelle mei --service-account. Hjirmei kinne jo in brûker brûke mei de minimale fereaske set rjochten. Wier, jo moatte sa'n "krâns" meitsje: Rol en RoleBinding.
Spitigernôch sil Helm dit net foar jo dwaan. Jo as jo Kubernetes-klusterbehearder moatte fan tefoaren in set fan rollen en rolbindingen foar it tsjinstaccount tariede om Helm troch te gean.
De fraach ûntstiet - wat is it ferskil tusken Rol en ClusterRole? It ferskil is dat ClusterRole wurket foar alle nammeromten, yn tsjinstelling ta gewoane Rollen en RoleBindings, dy't allinich wurkje foar in spesjalisearre nammeromte. Jo kinne belied ynstelle foar it hiele kluster en alle nammeromten, of personaliseare foar elke nammeromte yndividueel.
It is it neamen wurdich dat RBAC in oar grut probleem oplost. In protte minsken kleie dat Helm, spitigernôch, gjin multitenancy is (stipe gjin multitenancy). As ferskate teams in kluster konsumearje en Helm brûke, is it yn prinsipe ûnmooglik om belied op te stellen en har tagong binnen dit kluster te beheinen, om't d'r in bepaald tsjinstakkount is wêrunder Helm rint, en it skept alle boarnen yn it kluster fan ûnderen , wat soms tige ûngemaklik. Dit is wier - lykas it binêre bestân sels, lykas it proses, Helm Tiller hat gjin begryp fan multitenancy.
D'r is lykwols in geweldige manier wêrmei jo Tiller meardere kearen yn in kluster kinne rinne. D'r is gjin probleem mei dit, Tiller kin yn elke nammeromte lansearre wurde. Sa kinne jo RBAC, Kubeconfig as kontekst brûke, en tagong beheine ta in spesjale Helm.
It sil der sa útsjen.
D'r binne bygelyks twa Kubeconfigs mei kontekst foar ferskate teams (twa nammeromten): X Team foar it ûntwikkelingsteam en it adminkluster. It admin-kluster hat in eigen brede Tiller, dy't leit yn 'e nammeromte fan Kube-systeem, in oerienkommende avansearre tsjinst-akkount. En in aparte nammeromte foar it ûntwikkelteam, se sille har tsjinsten kinne ynsette op in spesjale nammeromte.
Dit is in wurkbere oanpak, Tiller is net sa machthonger dat it sil grutte ynfloed op dyn budzjet. Dit is ien fan 'e flugge oplossingen.
Fiel jo frij om Tiller apart te konfigurearjen en Kubeconfig kontekst foar it team, foar in spesifike ûntwikkelder of foar it miljeu te jaan: Dev, Staging, Production (it is twifele dat alles op itselde kluster sil wêze, dit kin lykwols dien wurde).
Trochgean mei ús ferhaal, litte wy oerskeakelje fan RBAC en prate oer ConfigMaps.
ConfigMaps
Helm brûkt ConfigMaps as syn gegevenswinkel. Doe't wy praat oer arsjitektuer, der wie gjin databank oeral dat soe bewarje ynformaasje oer releases, konfiguraasjes, rollbacks, ensfh ConfigMaps wurdt brûkt foar dit.
It wichtichste probleem mei ConfigMaps is bekend - se binne yn prinsipe ûnfeilich; it is ûnmooglik om gefoelige gegevens op te slaan. Wy prate oer alles dat net boppe de tsjinst moat gean, bygelyks wachtwurden. De meast native manier foar Helm op it stuit is om te wikseljen fan it brûken fan ConfigMaps nei geheimen.
Dit wurdt dien hiel ienfâldich. Oerskriuwe de Tiller ynstelling en spesifisearje dat de opslach sil wêze geheimen. Dan krije jo foar elke ynset gjin ConfigMap, mar in geheim.
Jo kinne stelle dat geheimen sels in frjemd konsept binne en net heul feilich. It is lykwols wurdich te begripen dat de Kubernetes-ûntwikkelders sels dit dogge. Fanôf ferzje 1.10, d.w.s. Al in hiel skoft is it mooglik, alteast yn iepenbiere wolken, de juste opslach te ferbinen mei it opslaan fan geheimen. It team wurket no oan manieren om tagong ta geheimen, yndividuele pods of oare entiteiten better te fersprieden.
It is better om Storage Helm oer te dragen nei geheimen, en se wurde op har beurt sintraal befeilige.
It bliuwt fansels data opslach limyt fan 1 MB. Helm brûkt hjir ensfh as ferspraat opslach foar ConfigMaps. En dêr seagen se dat dit in gaadlik datablok wie foar replikaasje, ensfh. D'r is in nijsgjirrige diskusje oer dit op Reddit, ik advisearje dizze grappige lêzing foar it wykein te finen of it úttreksel te lêzen .
Grafyk Repos
Charts binne de meast sosjaal kwetsbere en kinne wurde in boarne fan "Man yn 'e midden", benammen as jo brûke in stock oplossing. As earste hawwe wy it oer repositories dy't wurde bleatsteld fia HTTP.
Jo moatte perfoarst Helm Repo bleatstelle oer HTTPS - dit is de bêste opsje en is goedkeap.
Soarch omtinken chart hântekening meganisme. De technology is simpel as de hel. Dit is itselde ding dat jo brûke op GitHub, in gewoane PGP-masine mei iepenbiere en privee kaaien. Stel op en wês der wis fan, mei de nedige kaaien en tekenje alles, dat dit echt jo diagram is.
Dêrnjonken, Helm client stipet TLS (net yn 'e serverside HTTP-sin, mar ûnderlinge TLS). Jo kinne server- en kliïntkaaien brûke om te kommunisearjen. Om earlik te wêzen, brûk ik sa'n meganisme net, om't ik net fan ûnderlinge sertifikaten hâld. Yn prinsipe, - it wichtichste ark foar it ynstellen fan Helm Repo foar Helm 2 - stipet ek basisauthorisaasje. Jo kinne basisferifikaasje brûke as it handiger en rêstiger is.
Der is ek in plugin , wêrtroch jo Chart Repos kinne hostje op Google Cloud Storage. Dit is hiel handich, wurket geweldich en is frij feilich, om't alle beskreaune meganismen wurde recycled.
As jo HTTPS of TLS ynskeakelje, mTLS brûke, en basisautifikaasje ynskeakelje om risiko's fierder te ferminderjen, krije jo in feilich kommunikaasjekanaal mei Helm CLI en Chart Repo.
gRPC API
De folgjende stap is tige wichtich - te befeiligjen Tiller, dy't leit yn it kluster en is, oan 'e iene kant, in tsjinner, oan' e oare kant, it sels tagong ta oare komponinten en besiket te dwaan as immen.
Sa't ik al sei, Tiller is in tsjinst dy't bleatsteld gRPC, de Helm klant komt ta it fia gRPC. Standert is fansels TLS útskeakele. Wêrom't dit dien is is in diskutabele fraach, it liket my ta om de opset oan it begjin te ferienfâldigjen.
Foar produksje en sels staging advisearje ik TLS yn te skeakeljen op gRPC.
Yn myn miening, yn tsjinstelling ta mTLS foar charts, dit is passend hjir en wurdt dien hiel simpel - generearje in PQI ynfrastruktuer, meitsje in sertifikaat, launch Tiller, oerdrage it sertifikaat by inisjalisaasje. Hjirnei kinne jo alle Helm-kommando's útfiere, josels presintearje mei it oanmakke sertifikaat en privee kaai.
Op dizze manier beskermje jo josels tsjin alle oanfragen oan Tiller fan bûten it kluster.
Sa, wy hawwe befeilige de ferbining kanaal oan Tiller, wy hawwe al besprutsen RBAC en oanpast de rjochten fan de Kubernetes apiserver, it ferminderjen fan it domein dêr't it kin ynteraksje.
Beskerme Helm
Litte wy nei it definitive diagram sjen. It is deselde arsjitektuer mei deselde pylken.
Alle ferbiningen kinne no feilich yn grien tekene wurde:
- foar Chart Repo wy brûke TLS of mTLS en basis auth;
- mTLS foar Tiller, en it is bleatsteld as in gRPC tsjinst mei TLS, wy brûke sertifikaten;
- it kluster brûkt in spesjale tsjinst account mei Role en RoleBinding.
Wy hawwe it kluster signifikant befeilige, mar ien tûk sei:
"D'r kin mar ien absolút feilige oplossing wêze - in útskeakele kompjûter, dy't leit yn in betonnen doaze en wurdt bewekke troch soldaten."
D'r binne ferskate manieren om gegevens te manipulearjen en nije oanfalfektors te finen. Lykwols, ik bin der wis fan dat dizze oanbefellings sille berikke in basis yndustry standert foar feiligens.
Bonus
Dit diel is net direkt relatearre oan feiligens, mar sil ek nuttich wêze. Ik sil jo wat nijsgjirrige dingen sjen litte wêrfan in pear minsken witte. Bygelyks, hoe't jo sykje nei charts - offisjele en net-offisjele.
Yn de repository No binne d'r sawat 300 charts en twa streamen: stâl en incubator. Elkenien dy't in bydrage leveret, wit perfekt hoe lestich it is om fan incubator nei stâl te kommen, en hoe maklik it is om út stâl te fleanen. Dit is lykwols net it bêste ark om te sykjen nei diagrammen foar Prometheus en wat jo oars wolle, om ien ienfâldige reden - it is gjin portal wêr't jo maklik kinne sykje nei pakketten.
Mar der is in tsjinst , wat it folle handiger makket om charts te finen. It wichtichste is dat d'r folle mear eksterne repositories en hast 800 sjarmes beskikber binne. Plus, jo kinne jo repository ferbine as jo om ien of oare reden jo charts net nei stabyl wolle stjoere.
Besykje hub.helm.sh en litte wy it tegearre ûntwikkelje. Dizze tsjinst is ûnder it Helm-projekt, en jo kinne sels bydrage oan syn UI as jo in front-end-ûntwikkelder binne en gewoan it uterlik wolle ferbetterje.
Ik soe ek graach jo oandacht freegje wolle Iepenje Service Broker API yntegraasje. It klinkt omslachtich en ûndúdlik, mar it lost problemen op dêr't elkenien foar stiet. Lit my útlizze mei in ienfâldich foarbyld.
D'r is in Kubernetes-kluster wêryn wy in klassike applikaasje wolle útfiere - WordPress. Algemien is in databank nedich foar folsleine funksjonaliteit. D'r binne in protte ferskillende oplossingen, jo kinne bygelyks jo eigen statefull tsjinst starte. Dit is net heul handich, mar in protte minsken dogge it.
Oaren, lykas ús by Chainstack, brûke beheare databases lykas MySQL of PostgreSQL foar har servers. Dêrom lizze ús databases earne yn 'e wolk.
Mar in probleem ûntstiet: wy moatte ús tsjinst ferbine mei in databank, in databanksmaak meitsje, de referinsjes oerdrage en it op ien of oare manier beheare. Dit alles wurdt normaal mei de hân dien troch de systeembehearder of ûntwikkelder. En d'r is gjin probleem as d'r in pear applikaasjes binne. As d'r in protte binne, moatte jo in kombinearje. D'r is sa'n harvester - it is Service Broker. It lit jo in spesjale plugin brûke foar in iepenbiere wolkkluster en bestelle boarnen fan 'e provider fia Broker, as wie it in API. Om dit te dwaan kinne jo native Kubernetes-ark brûke.
It is hiel ienfâldich. Jo kinne query, bygelyks, Managed MySQL yn Azure mei in basis tier (dit kin wurde konfigurearre). Mei de Azure API sil de databank makke wurde en taret foar gebrûk. Jo hoege jo hjir net mei te bemuoien, de plugin is dêr ferantwurdlik foar. Bygelyks, OSBA (Azure plugin) sil referinsjes weromkomme nei de tsjinst en trochjaan oan Helm. Jo sille WordPress kinne brûke mei cloud MySQL, hielendal net omgean mei behearde databases en jo gjin soargen meitsje oer statefulle tsjinsten binnen.
Wy kinne sizze dat Helm fungearret as in lijm dy't, oan 'e iene kant, kinne jo ynsette tsjinsten, en oan' e oare kant, konsumearje de boarnen fan wolk providers.
Jo kinne jo eigen plugin skriuwe en dit hiele ferhaal on-premise brûke. Dan sille jo gewoan jo eigen plugin hawwe foar de bedriuwswolkprovider. Ik advisearje dizze oanpak te besykjen, foaral as jo in grutte skaal hawwe en dev, staging, of de heule ynfrastruktuer fluch wolle ynsette foar in funksje. Dit sil it libben makliker meitsje foar jo operaasjes as DevOps.
In oare fynst dy't ik al neamde is helm-gcs plugin, wêrmei jo Google-buckets (objekt opslach) kinne brûke om Helm-kaarten op te slaan.
Jo hawwe mar fjouwer kommando's nedich om it te brûken:
- ynstallearje de plugin;
- inisjearje it;
- set it paad nei de bak, dat leit yn gcp;
- publisearje charts op 'e standert manier.
It skientme is dat de native gcp-metoade sil wurde brûkt foar autorisaasje. Jo kinne in tsjinstakkount brûke, in ûntwikkeldersakkount, wat jo wolle. It is heul handich en kostet neat om te operearjen. As jo, lykas ik, de opsless-filosofy befoarderje, dan sil dit heul handich wêze, foaral foar lytse teams.
Alternativen
Helm is net de ienige oplossing foar tsjinstbehear. D'r binne in protte fragen oer, dat is wierskynlik wêrom't de tredde ferzje sa fluch ferskynde. Fansels binne der alternativen.
Dit kinne spesjalisearre oplossingen wêze, bygelyks Ksonnet of Metaparticle. Jo kinne jo klassike ark foar ynfrastruktuerbehear brûke (Ansible, Terraform, Chef, ensfh.) Foar deselde doelen dêr't ik oer praat.
Uteinlik is der in oplossing , waans populariteit groeit.
Operator Framework is it top Helm-alternatyf om te beskôgjen.
It is mear lânseigen oan CNCF en Kubernetes, mar de barriêre foar yngong is folle heger, Jo moatte mear programmearje en manifesten minder beskriuwe.
D'r binne ferskate tafoegings, lykas Draft, Scaffold. Se meitsje it libben in stik makliker, se ferienfâldigje bygelyks de syklus fan it ferstjoeren en lansearjen fan Helm foar ûntwikkelders om in testomjouwing yn te setten. Ik soe se empowerers neame.
Hjir is in fisuele kaart fan wêr't alles is.
Op 'e x-as is it nivo fan jo persoanlike kontrôle oer wat der bart, op' e y-as is it nivo fan nativeness fan Kubernetes. Helm ferzje 2 falt earne yn 'e midden. Yn ferzje 3, net enoarm, mar sawol kontrôle as it nivo fan nativeness binne ferbettere. Oplossings op it Ksonnet-nivo binne noch inferior sels oan Helm 2. Se binne lykwols it wurdich te besjen om te witten wat oars yn dizze wrâld is. Fansels sil jo konfiguraasjebehearder ûnder jo kontrôle wêze, mar it is perfoarst net native to Kubernetes.
It Operator Framework is absolút lânseigen oan Kubernetes en lit jo it folle eleganter en skrupeler beheare (mar tink oan oer it yngongsnivo). Dit is leaver geskikt foar in spesjalisearre tapassing en it meitsjen fan behear foar it, yn stee fan in massa-harvester foar it ferpakken fan in grut oantal applikaasjes mei Helm.
Extenders ferbetterje gewoan de kontrôle in bytsje, komplementearje workflow, of snije hoeken op CI / CD-pipelines.
De takomst fan Helm
It goede nijs is dat Helm 3 komt. De alpha-ferzje fan Helm 3.0.0-alpha.2 is al útbrocht, jo kinne it besykje. It is frij stabyl, mar funksjonaliteit is noch beheind.
Wêrom hawwe jo Helm 3 nedich? As earste is dit in ferhaal oer ferdwining fan Tiller, as komponint. Dit, sa't jo al begripe, is in grutte stap foarút, want út it eachpunt fan 'e feiligens fan' e arsjitektuer is alles ferienfâldige.
Doe't Helm 2 waard makke, dat wie om de tiid fan Kubernetes 1.8 of noch earder, in protte fan 'e begripen wiene ûnfoldwaande. Bygelyks, it CRD-konsept wurdt no aktyf útfierd, en Helm sil brûke CRDom struktueren op te slaan. It sil mooglik wêze om allinich de kliïnt te brûken en it serverdiel net te ûnderhâlden. Brûk dêrtroch native Kubernetes-kommando's om te wurkjen mei struktueren en boarnen. Dit is in grutte stap foarút.
Sil ferskine stipe foar native OCI repositories (Iepen Container Initiative). Dit is in enoarm inisjatyf, en Helm is foaral ynteressearre om syn charts te pleatsen. It komt op it punt dat bygelyks Docker Hub in protte OCI-standerts stipet. Ik ried net, mar miskien sille klassike Docker-repository-providers jo de kâns begjinne te jaan om jo Helm-charts te hostjen.
It kontroversjele ferhaal foar my is Lua stipe, as sjabloanmotor foar it skriuwen fan skripts. Ik bin gjin grutte fan fan Lua, mar dit soe in folslein opsjonele funksje wêze. Ik kontrolearre dit 3 kear - it brûken fan Lua sil net nedich wêze. Dêrom, dejingen dy't Lua wolle kinne brûke, dejingen dy't fan Go hâlde, doch mei oan ús enoarme kamp en brûke go-tmpl foar dit.
Uteinlik, wat ik perfoarst miste wie skema-opkomst en falidaasje fan gegevenstype. D'r sille gjin problemen mear wêze mei int of tekenrige, gjin needsaak om nul yn dûbele quotes te wrapjen. In JSONS-skema sil ferskine wêrmei jo dit eksplisyt kinne beskriuwe foar wearden.
Sil swier ferwurke wurde evenemint-oandreaune model. It is al konseptueel beskreaun. Sjoch op de Helm 3 tûke, en jo sille sjen hoefolle eveneminten en heakken en oare dingen binne tafoege, dat sil gâns ferienfâldigje en, oan 'e oare kant, tafoegje kontrôle oer de ynset prosessen en reaksjes op harren.
Helm 3 sil ienfâldiger, feiliger en leuker wêze, net om't wy Helm 2 net leuk fine, mar om't Kubernetes mear avansearre wurdt. Dêrtroch kin Helm de ûntwikkelingen fan Kubernetes brûke en dêrop poerbêste managers foar Kubernetes meitsje.
In oar goed nijs is dat Alexander Khayorov sil jo fertelle, Lit ús jo herinnerje dat de konferinsje oer de yntegraasje fan prosessen foar ûntwikkeling, testen en operaasje sil wurde hâlden yn Moskou 30 septimber en 1 oktober. Jo kinne it noch oant 20 augustus en fertel ús oer jo ûnderfining mei de oplossing taken fan 'e DevOps-oanpak.
Folgje konferinsje checkpoints en nijs by и .
Boarne: www.habr.com