Helm Sécherheet

D'Essenz vun der Geschicht iwwer de populärste Package Manager fir Kubernetes kéint mat engem Emoji duergestallt ginn:

• d'Këscht ass Helm (wat am nootste bei der leschter Emoji Verëffentlechung ass);
• Spär - Sécherheet;
• de klenge Mann ass d'Léisung fir de Problem.

Tatsächlech wäert alles e bësse méi komplizéiert sinn, an d'Geschicht ass voller technesch Detailer iwwer Wéi maachen Helm sécher.

• Kuerz wat Helm ass am Fall wou Dir net wousst oder vergiess hutt. Wéi eng Problemer léist et a wou ass et am Ökosystem.
• Loosst eis d'Helm Architektur kucken. Kee Gespréich iwwer Sécherheet a wéi een Tool oder Léisung méi sécher mécht ass komplett ouni d'Architektur vun der Komponent ze verstoen.
• Loosst eis Helm Komponenten diskutéieren.
• Déi brennendste Fro ass d'Zukunft - déi nei Versioun vum Helm 3. 

Alles an dësem Artikel gëllt fir Helm 2. Dës Versioun ass am Moment an der Produktioun an ass héchstwahrscheinlech deen Dir am Moment benotzt, an et ass d'Versioun déi d'Sécherheetsrisiken enthält.

Iwwert de Spriecher: Alexander Khayorov (ENG)allexx) huet fir 10 Joer entwéckelt, hëlleft Inhalt ze verbesseren Moskau Python Conf++ a koum an de Comité Helm Sommet. Elo schafft hien bei Chainstack als Entwécklungsleit - dëst ass en Hybrid tëscht engem Entwécklungsmanager an enger Persoun déi verantwortlech ass fir d'Finale Verëffentlechungen ze liwweren. Dat ass, et ass op der Schluechtfeld etabléiert, wou alles aus der Kreatioun vun engem Produit bis seng Operatioun geschitt.

Chainstack ass e klengen, aktiv wuessende Startup deem seng Missioun ass Clienten z'erméiglechen iwwer d'Infrastruktur an d'Komplexitéit vun de dezentraliséierten Uwendungen ze vergiessen; d'Entwécklungsteam ass zu Singapur. Frot Chainstack net fir cryptocurrency ze verkafen oder ze kafen, awer bidde fir iwwer Enterprise Blockchain Kaderen ze schwätzen, a si äntweren Iech glécklech.

Helm

Dëst ass e Package (Chart) Manager fir Kubernetes. Déi intuitivst an universellst Manéier fir Uwendungen an e Kubernetes Cluster ze bréngen.

Mir schwätzen natierlech iwwer eng méi strukturell an industriell Approche wéi Är eege YAML Manifestatiounen ze kreéieren a kleng Utilities ze schreiwen.

Helm ass dee Beschten deen de Moment verfügbar ass a populär ass.

Firwat Helm? Virun allem well et vum CNCF ënnerstëtzt gëtt. Cloud Native ass eng grouss Organisatioun an ass d'Muttergesellschaft fir Projeten Kubernetes, etcd, Fluentd an anerer.

En anere wichtege Fakt ass datt Helm e ganz populäre Projet ass. Wéi ech ugefaang hunn ze schwätzen iwwer wéi ech Helm sécher maachen am Januar 2019, hat de Projet dausend Stären op GitHub. Bis Mee waren et der 12 dausend.

Vill Leit interesséieren sech fir Helm, also och wann Dir se nach net benotzt, profitéiert Dir vu senger Sécherheet ze wëssen. Sécherheet ass wichteg.

De Kär Helm Team gëtt vun Microsoft Azure ënnerstëtzt an ass dofir e relativ stabile Projet, am Géigesaz zu villen aneren. D'Verëffentlechung vum Helm 3 Alpha 2 Mëtt Juli weist datt et zimmlech vill Leit um Projet schaffen, a si hunn de Wonsch an d'Energie fir Helm z'entwéckelen an ze verbesseren.

Helm léist verschidde Rootproblemer vun der Applikatiounsmanagement a Kubernetes.

• Applikatioun Verpakung. Och eng Applikatioun wéi "Hallo, Welt" op WordPress besteet schonn aus verschiddene Servicer, an Dir wëllt se zesummen packen.
• Gestioun vun der Komplexitéit déi mat der Gestioun vun dësen Uwendungen kënnt.
• E Liewenszyklus deen net endet nodeems d'Applikatioun installéiert oder ofgesat ass. Et leeft weider, et muss aktualiséiert ginn, an den Helm hëlleft domat a probéiert déi richteg Moossnamen a Politik dofir ze bréngen.

Bagging et ass op eng kloer Manéier organiséiert: et gëtt Metadaten voll am Aklang mat der Aarbecht vun engem normale Package Manager fir Linux, Windows oder MacOS. Dat ass, e Repository, Ofhängegkeete vu verschiddene Packagen, Meta-Informatioun fir Uwendungen, Astellungen, Konfiguratiounsfeatures, Informatiounsindexéierung, etc. Helm erlaabt Iech all dëst fir Uwendungen ze kréien an ze benotzen.

Komplexitéit Management. Wann Dir vill Uwendungen vum selwechten Typ hutt, ass Parameteriséierung néideg. Schabloune kommen dovun aus, awer fir ze vermeiden datt Dir Är eege Manéier fir Schablounen ze kreéieren, kënnt Dir benotzen wat Helm aus der Këscht offréiert.

Applikatioun Lifecycle Management - Menger Meenung no ass dat déi interessantst an ongeléist Fro. Dofir sinn ech deemools op Helm komm. Mir hu missen en Aa op den Applikatiounsliewenszyklus behalen a wollten eis CI/CD an Applikatiounszyklen op dëst Paradigma réckelen.

Helm erlaabt Iech:

• Deployment verwalten, stellt d'Konzept vun der Konfiguratioun an der Revisioun vir;
• erfollegräich Rollback duerchzeféieren;
• benotzen Haken fir verschidden Evenementer;
• füügt zousätzlech Uwendungschecken un a reagéiert op hir Resultater.

Zousätzlech Helm huet "Batterien" - eng grouss Zuel vu leckere Saachen, déi a Form vu Plugins abegraff kënne ginn, Äert Liewen vereinfacht. Plugins kënnen onofhängeg geschriwwe ginn, si sinn zimlech isoléiert a erfuerderen keng harmonesch Architektur. Wann Dir eppes wëllt implementéieren, empfeelen ech et als Plugin ze maachen, an dann eventuell am Upstream abegraff.

Helm baséiert op dräi Haaptkonzepter:

• Charts Repo - Beschreiwung an Array vun Parameteren méiglech fir Äert Manifest. 
• Configuréieren - dat ass, d'Wäerter déi applizéiert ginn (Text, numeresch Wäerter, etc.).
• Verëffentlechung sammelt déi zwee iewescht Komponenten, an zesummen ginn se an d'Verëffentlechung. Verëffentlechunge kënne Versioune ginn, an doduerch en organiséierte Liewenszyklus z'erreechen: kleng zum Zäitpunkt vun der Installatioun a grouss am Moment vum Upgrade, Downgrade oder Rollback.

Helm Architektur

D'Diagramm weist konzeptuell d'Héichniveau Architektur vum Helm.

Loosst mech Iech drun erënneren datt Helm eppes mat Kubernetes ass. Dofir kënne mir net ouni Kubernetes Cluster (Rektangel) maachen. D'kube-apiserver Komponente wunnt um Master. Ouni Helm hu mir Kubeconfig. Helm bréngt eng kleng Binär, wann Dir et esou nenne kënnt, Helm CLI Utility, deen op engem Computer, Laptop, Mainframe installéiert ass - op alles.

Mä dëst ass net genuch. Helm huet e Server Komponent genannt Tiller. Et representéiert d'Interesse vum Helm am Cluster; et ass eng Applikatioun am Kubernetes Cluster, grad wéi all aner.

Deen nächste Bestanddeel vum Chart Repo ass e Repository mat Charts. Et gëtt en offiziellen Repository, an et kann e private Repository vun enger Firma oder Projet sinn.

Interaktioun

Loosst eis kucken wéi d'Architekturkomponenten interagéieren wa mir eng Applikatioun mat Helm installéiere wëllen.

• Mir schwätzen Helm install, Zougang zum Repository (Chart Repo) a kritt en Helm Chart.

• Den Helm Utility (Helm CLI) interagéiert mat Kubeconfig fir erauszefannen wéi ee Cluster kontaktéiert. 
• Nodeems Dir dës Informatioun kritt hutt, bezeechent den Utility den Tiller, deen an eisem Cluster ass, als Applikatioun. 
• Tiller rifft Kube-apiserver fir Aktiounen an Kubernetes auszeféieren, e puer Objeten ze kreéieren (Servicer, Pods, Repliken, Geheimnisser, etc.).

Als nächst wäerte mir d'Diagramm komplizéiere fir den Attackvektor ze gesinn, un deem d'ganz Helm Architektur als Ganzt ausgesat ka ginn. An da wäerte mir probéieren hir ze schützen.

Attack Vektor

Den éischte potenziellen schwaache Punkt ass privilegiéierten API-de Benotzer. Als Deel vum Schema ass dëst en Hacker deen Admin Zougang zum Helm CLI kritt huet.

Onprivilegéierten API Benotzer kann och eng Gefor duerstellen wann et iergendwou an der Géigend ass. Sou e Benotzer wäert en anere Kontext hunn, zum Beispill, hien kann an engem Cluster Nummraum an de Kubeconfig Astellunge fixéiert ginn.

Den interessantsten Attackvektor kann e Prozess sinn, deen an engem Stärekoup iergendwou bei Tiller läit a kann et zougräifen. Dëst kann e Webserver oder Mikroservice sinn, deen d'Netzëmfeld vum Cluster gesäit.

Eng exotesch, awer ëmmer méi populär Attackvariant beinhalt Chart Repo. Eng Grafik erstallt vun engem skrupellosen Auteur kann onsécher Ressourcen enthalen, an Dir wäert et fäerdeg bréngen andeems Dir et op Glawen hëlt. Oder et kann d'Diagramm ersetzen, déi Dir aus dem offiziellen Repository eroflueden an, zum Beispill, eng Ressource a Form vu Politik erstellen an hiren Zougang eskaléieren.

Loosst eis probéieren Attacke vun all deene véier Säiten ofzeschléissen an erauszefannen, wou et Problemer an der Helm-Architektur gëtt, a wou et vläicht keng gëtt.

Loosst eis d'Diagramm vergréisseren, méi Elementer addéieren, awer behalen all d'Basiskomponenten.

Den Helm CLI kommunizéiert mat der Chart Repo, interagéiert mat Kubeconfig, an d'Aarbecht gëtt an de Stärekoup op den Tiller Komponent transferéiert.

Tiller gëtt duerch zwee Objete vertruede:

• Tiller-deploy svc, déi e bestëmmte Service aussetzt;
• Tiller-deploy Pod (am Diagramm an enger eenzeger Kopie an enger Replika), op deem d'ganz Laascht leeft, déi op de Cluster kënnt.

Verschidde Protokoller a Schemae gi fir Interaktioun benotzt. Aus Sécherheetssiicht si mir am meeschten interesséiert fir:

• De Mechanismus, duerch deen den Helm CLI op d'Diagrammrepo zougräift: wéi ee Protokoll, gëtt et Authentifikatioun a wat ka mat deem gemaach ginn.
• De Protokoll, duerch deen den Helm CLI, mat kubectl, mat Tiller kommunizéiert. Dëst ass en RPC Server deen am Cluster installéiert ass.
• Tiller selwer ass zougänglech fir Mikroservicer déi am Cluster wunnen an interagéieren mam Kube-apiserver.

Loosst eis all dës Beräicher an Uerdnung diskutéieren.

RBAC

Et ass kee Sënn iwwer Sécherheet fir Helm oder all aner Service am Cluster ze schwätzen, ausser RBAC ass aktivéiert.

Et schéngt, datt dëst net déi lescht Empfehlung ass, awer ech si sécher datt vill Leit nach ëmmer RBAC och an der Produktioun net aktivéiert hunn, well et vill Opschwong ass a vill Saache musse konfiguréiert ginn. Ech encouragéieren Iech awer dëst ze maachen.

https://rbac.dev/ - Websäit Affekot fir RBAC. Et enthält eng riesech Unzuel vun interessanten Materialien, déi Iech hëllefen, RBAC opzestellen, ze weisen firwat et gutt ass a wéi een am Fong domat an der Produktioun liewen.

Ech probéieren ze erklären wéi den Tiller an de RBAC funktionnéieren. Tiller schafft am Stärekoup ënner engem bestëmmte Service Kont. Typesch, wann RBAC net konfiguréiert ass, ass dëst de Superuser. An der Basiskonfiguratioun wäert Tiller en Admin sinn. Dofir gëtt dacks gesot datt Tiller en SSH-Tunnel fir Äre Stärekoup ass. Tatsächlech ass dat richteg, sou datt Dir e separaten dedizéierten Servicekonto benotze kënnt amplaz vum Standard Service Account am Diagramm hei uewen.

Wann Dir Helm initialiséiert an et fir d'éischte Kéier um Server installéiert, kënnt Dir de Servicekonto benotzen --service-account. Dëst erlaabt Iech e Benotzer mat dem minimum erfuerderleche Set vu Rechter ze benotzen. True, Dir musst esou eng "Girland" erstellen: Roll a RolleBinding.

Leider wäert Helm dat net fir Iech maachen. Dir oder Äre Kubernetes Cluster Administrateur muss am Viraus e Set vu Rollen a RolleBindings fir de Servicekonto virbereeden fir Helm ze passéieren.

D'Fro stellt sech - wat ass den Ënnerscheed tëscht Roll a ClusterRole? Den Ënnerscheed ass datt ClusterRole fir all Nummraim funktionnéiert, am Géigesaz zu normale Rollen a RoleBindings, déi nëmme fir e spezialiséierte Nummraum funktionnéieren. Dir kënnt Politik fir de ganze Stärekoup an all Nummraim konfiguréieren, oder personaliséiert fir all Nummraum individuell.

Et ass derwäert ze ernimmen datt RBAC en anere grousse Problem léist. Vill Leit beschwéieren datt Helm, leider, net Multitenancy ass (ënnerstëtzt net Multitenancy). Wann e puer Teams e Cluster verbrauchen an Helm benotzen, ass et am Fong onméiglech Politiken opzestellen an hiren Zougang bannent dësem Cluster ze limitéieren, well et e gewësse Servicekonto ass, ënner deem den Helm leeft, an et erstellt all d'Ressourcen am Cluster vun drënner. , déi heiansdo ganz onbequem. Dëst ass wouer - wéi d'binär Datei selwer, wéi de Prozess, Helm Tiller huet kee Konzept vu Multitenancy.

Wéi och ëmmer, et gëtt e super Wee deen Iech erlaabt Tiller e puer Mol an engem Cluster ze lafen. Et gëtt kee Problem mat dësem, Tiller kann an all Nummraum lancéiert ginn. Also kënnt Dir RBAC, Kubeconfig als Kontext benotzen, an den Zougang zu engem speziellen Helm limitéieren.

Et wäert esou ausgesinn.

Zum Beispill ginn et zwee Kubeconfigs mat Kontext fir verschidden Teams (zwee Nummraim): X Team fir d'Entwécklungsteam an den Admincluster. Den Admincluster huet säin eegene breet Tiller, deen am Kube-System Nummraum läit, en entspriechend fortgeschratt Service-Kont. An e separaten Nummraum fir d'Entwécklungsteam, si kënnen hir Servicer an e speziellen Nummraum ofsetzen.

Dëst ass eng funktionell Approche, Tiller ass net sou Kraafthonger, datt et Äre Budget vill beaflosst. Dëst ass eng vun de schnelle Léisungen.

Fillt Iech gratis Tiller separat ze konfiguréieren an de Kubeconfig Kontext fir d'Team, fir e spezifeschen Entwéckler oder fir d'Ëmwelt ze bidden: Dev, Staging, Production (et ass zweifelhaft datt alles am selwechte Cluster wäert sinn, awer dëst kann gemaach ginn).

Fuert eis Geschicht weider, loosst eis vun RBAC wiesselen an iwwer ConfigMaps schwätzen.

ConfigMaps

Helm benotzt ConfigMaps als säin Dategeschäft. Wa mir iwwer Architektur geschwat hunn, gouf et keng Datebank iwwerall déi Informatioun iwwer Verëffentlechungen, Konfiguratiounen, Rollbacks, etc. ConfigMaps gëtt dofir benotzt.

Den Haaptproblem mat ConfigMaps ass bekannt - si sinn am Prinzip onsécher; et ass onméiglech sensibel Donnéeën ze späicheren. Mir schwätzen iwwer alles wat net iwwer de Service sollt goen, zum Beispill Passwierder. Dee gebiertegste Wee fir Helm elo ass fir vu ConfigMaps op Geheimnisser ze wiesselen.

Dëst gëtt ganz einfach gemaach. Iwwerschreift d'Tiller-Astellung a präziséiert datt d'Späichere Geheimnisser sinn. Dann fir all Détachement kritt Dir net eng ConfigMap, mee e Geheimnis.

Dir kënnt plädéieren datt Geheimnisser selwer e komescht Konzept sinn an net ganz sécher. Wéi och ëmmer, et ass derwäert ze verstoen datt d'Kubernetes Entwéckler selwer dëst maachen. Vun der Versioun 1.10 un, d.h. Zënter enger laanger Zäit ass et méiglech, op d'mannst an ëffentleche Wolleken, déi richteg Späichere mat Geheimnisser ze verbannen. D'Team schafft elo un Weeër fir den Zougang zu Geheimnisser, eenzel Pods oder aner Entitéite besser ze verdeelen.

Et ass besser Storage Helm op Geheimnisser ze transferéieren, a si sinn am Géigendeel zentral geséchert.

Natierlech bleift et Datenspeicherlimit vun 1 MB. Helm hei benotzt etcd als verdeelt Späichere fir ConfigMaps. An do hunn se geduecht datt dëst e passenden Datebit fir Replikatioun wier, etc. Et gëtt eng interessant Diskussioun iwwer dëst op Reddit, ech recommandéieren dës witzeg Liesung fir de Weekend ze fannen oder den Extrait ze liesen hei.

Chart Repos

Charts sinn déi sozial vulnérabel a kënnen eng Quell vum "Mann an der Mëtt" ginn, besonnesch wann Dir eng Aktieléisung benotzt. Als éischt schwätze mir iwwer Repositories déi iwwer HTTP ausgesat sinn.

Dir musst definitiv Helm Repo iwwer HTTPS ausstellen - dëst ass déi bescht Optioun an ass preiswert.

Opgepasst Diagramm Ënnerschrëft Mechanismus. D'Technologie ass einfach wéi d'Häll. Dëst ass datselwecht wat Dir op GitHub benotzt, eng regulär PGP Maschinn mat ëffentlechen a private Schlësselen. Setzt op a gitt sécher, déi néideg Schlësselen ze hunn an alles z'ënnerschreiwen, datt dëst wierklech Är Diagramm ass.

Ausserdeem, Helm Client ënnerstëtzt TLS (net am Server-Säit HTTP Sënn, mee géigesäitege TLS). Dir kënnt Server- a Clientschlëssel benotze fir ze kommunizéieren. Fir éierlech ze sinn, benotzen ech net sou e Mechanismus, well ech géigesäiteg Zertifikater net gär hunn. Prinzipiell, Chartmuseum - den Haaptinstrument fir Helm Repo fir Helm 2 opzestellen - ënnerstëtzt och Basis Auth. Dir kënnt Basis Autorisatioun benotzen wann et méi bequem a méi roueg ass.

Et gëtt och e Plugin helm-gcs, wat Iech erlaabt Chart Repos op Google Cloud Storage ze hosten. Dëst ass zimmlech bequem, funktionnéiert super an ass ganz sécher, well all déi beschriwwe Mechanismen recycléiert ginn.

Wann Dir HTTPS oder TLS aktivéiert, benotzt mTLS, an aktivéiert Basisautoritéit fir Risiken weider ze reduzéieren, kritt Dir e séchere Kommunikatiounskanal mam Helm CLI an Chart Repo.

gRPC API

Deen nächste Schrëtt ass ganz wichteg - den Tiller ze sécheren, deen am Stärekoup läit an engersäits e Server ass, op der anerer Säit huet hien selwer Zougang zu anere Komponenten a probéiert sech als een ze maachen.

Wéi ech scho gesot hunn, Tiller ass e Service deen gRPC aussetzt, den Helm Client kënnt iwwer gRPC. Par défaut ass natierlech TLS behënnert. Firwat dat gemaach gouf ass eng diskutabel Fro, et schéngt mir de Setup am Ufank ze vereinfachen.

Fir Produktioun a souguer Inszenéierung, ech recommandéieren TLS op gRPC z'aktivéieren.

Menger Meenung no, am Géigesaz zu mTLS fir Charts, ass dat hei ubruecht a gëtt ganz einfach gemaach - eng PQI Infrastruktur generéieren, e Certificat erstellen, Tiller starten, den Zertifika während der Initialiséierung transferéieren. Duerno kënnt Dir all Helm Kommandoen ausféieren, Iech selwer mam generéierten Zertifika a private Schlëssel presentéieren.

Sou schützt Dir Iech virun all Ufro un Tiller vun ausserhalb vum Cluster.

Also, mir hunn de Verbindungskanal op Tiller geséchert, mir hu scho RBAC diskutéiert an d'Rechter vum Kubernetes apiserver ugepasst, d'Domain ze reduzéieren mat deem et interagéiere kann.

Geschützt Helm

Loosst eis de finalen Diagramm kucken. Et ass déi selwecht Architektur mat de selwechte Pfeile.

All Verbindunge kënnen elo sécher a gréng gezeechent ginn:

• fir Chart Repo benotze mir TLS oder mTLS a Basis Auth;
• mTLS fir Tiller, an et gëtt als gRPC Service mat TLS ausgesat, mir benotzen Certificaten;
• de Stärekoup benotzt e spezielle Servicekonto mat Roll a RoleBinding. 

Mir hunn de Stärekoup bedeitend geséchert, awer een Smart sot:

"Et kann nëmmen eng absolut sécher Léisung ginn - en ausgeschaltene Computer, deen an enger konkreter Këscht läit a vun Zaldoten bewaacht gëtt."

Et gi verschidde Weeër fir Daten ze manipuléieren an nei Attackvektoren ze fannen. Wéi och ëmmer, ech sinn zouversiichtlech datt dës Empfehlungen e Basisindustriestandard fir Sécherheet erreechen.

Bonus

Dësen Deel ass net direkt mat der Sécherheet verbonnen, awer wäert och nëtzlech sinn. Ech weisen Iech e puer interessant Saachen, déi wéineg Leit wëssen. Zum Beispill, wéi Dir fir Charts sichen - offiziell an inoffiziell.

Am Repository github.com/helm/charts Elo ginn et ongeféier 300 Charts an zwee Streamen: Stall an Inkubator. Jiddereen, dee bäidréit, weess ganz gutt, wéi schwéier et ass, vum Inkubator op de Stall ze kommen, a wéi einfach et ass aus dem Stall ze fléien. Wéi och ëmmer, dëst ass net dat bescht Tool fir Charts fir Prometheus ze sichen a wat och ëmmer Dir wëllt, aus engem einfache Grond - et ass kee Portal wou Dir bequem no Packagen sichen kënnt.

Mee et gëtt e Service hub.helm.sh, wat et vill méi bequem mécht Charts ze fannen. Virun allem, et gi vill méi extern Repositories a bal 800 Charme verfügbar. Plus, Dir kënnt Äre Repository verbannen wann Dir aus irgendege Grënn Är Charts net stabil wëllt schécken.

Probéiert hub.helm.sh a loosst eis et zesumme entwéckelen. Dëse Service ass ënner dem Helm Projet, an Dir kënnt souguer zu sengem UI bäidroen wann Dir e Front-End Entwéckler sidd a just d'Erscheinung wëllt verbesseren.

Ech wëll och Är Opmierksamkeet op Open Service Broker API Integratioun. Et kléngt ëmständlech an onkloer, awer et léist Problemer mat deenen jidderee konfrontéiert ass. Loosst mech mat engem einfache Beispill erklären.

Et gëtt e Kubernetes Cluster an deem mir eng klassesch Applikatioun wëllen lafen - WordPress. Allgemeng ass eng Datebank fir voll Funktionalitéit gebraucht. Et gi vill verschidde Léisungen, zum Beispill, Dir kënnt Ären eegene statefull Service starten. Dëst ass net ganz bequem, awer vill Leit maachen et.

Anerer, wéi eis bei Chainstack, benotzen verwalteten Datenbanken wéi MySQL oder PostgreSQL fir hir Serveren. Dofir sinn eis Datenbanken iergendwou an der Wollek.

Awer e Problem entsteet: mir mussen eise Service mat enger Datebank verbannen, en Datebankaroma erstellen, d'Umeldungsinformatioun transferéieren an iergendwéi verwalten. All dëst gëtt normalerweis manuell vum Systemadministrator oder Entwéckler gemaach. An et gëtt kee Problem wann et wéineg Uwendungen sinn. Wann et vill vun hinnen sinn, braucht Dir eng Kombinatioun. Et gëtt sou en Harvester - et ass Service Broker. Et erlaabt Iech e spezielle Plugin fir e Public Cloud Cluster ze benotzen an d'Ressourcen vum Provider duerch Broker ze bestellen, wéi wann et eng API wier. Fir dëst ze maachen, kënnt Dir gebierteg Kubernetes Tools benotzen.

Et ass ganz einfach. Dir kënnt Ufroen, zum Beispill, Managed MySQL an Azure mat engem Basisniveau (dëst kann konfiguréiert ginn). Mat der Azure API gëtt d'Datebank erstallt a virbereet fir ze benotzen. Dir braucht Iech net domatter ze stéieren, de Plugin ass dofir verantwortlech. Zum Beispill, OSBA (Azure Plugin) wäert Umeldungsinformatioune fir de Service zréckginn an et un Helm weiderginn. Dir wäert fäeg sinn WordPress mat Cloud MySQL ze benotzen, guer net mat verwalteten Datenbanken ëmzegoen an Iech keng Suergen iwwer statefull Servicer dobannen.

Mir kënne soen datt Helm als Klebstoff wierkt, deen Iech engersäits erlaabt Iech Servicer z'installéieren, an op der anerer Säit d'Ressourcen vun de Cloud Provider ze konsuméieren.

Dir kënnt Ären eegene Plugin schreiwen an dës ganz Geschicht on-premise benotzen. Da wäert Dir einfach Ären eegene Plugin fir de Firmen Cloud Provider hunn. Ech recommandéieren dës Approche ze probéieren, besonnesch wann Dir eng grouss Skala hutt a séier Dev, Staging oder déi ganz Infrastruktur fir eng Feature wëllt ofsetzen. Dëst wäert d'Liewen méi einfach maachen fir Är Operatiounen oder DevOps.

Eng aner Fonnt déi ech scho gesot hunn ass helm-gcs plugin, wat Iech erlaabt Google-Eemere (Objetlagerung) ze benotzen fir Helm Charts ze späicheren.

Dir braucht nëmme véier Kommandoen fir se ze benotzen:

1. installéiert de Plugin;
2. initiéieren et;
3. setzen de Wee op den Eemer, deen am gcp läit;
4. Verëffentlechen Charts am Standard Manéier.

D'Schéinheet ass datt déi gebierteg gcp Method fir d'Autorisatioun benotzt gëtt. Dir kënnt e Service Kont benotzen, en Entwéckler Kont, wat Dir wëllt. Et ass ganz praktesch a kascht näischt ze bedreiwen. Wann Dir, wéi ech, déi opslos Philosophie fördert, da wäert dat ganz bequem sinn, besonnesch fir kleng Équipen.

Alternativen

Helm ass net déi eenzeg Service Management Léisung. Et gi vill Froen doriwwer, dat ass wahrscheinlech firwat déi drëtt Versioun sou séier ass. Natierlech ginn et Alternativen.

Dës kënne spezialiséiert Léisunge sinn, zum Beispill Ksonnet oder Metaparticle. Dir kënnt Är klassesch Infrastrukturmanagement Tools (Ansible, Terraform, Chef, etc.) fir déiselwecht Zwecker benotzen, iwwer déi ech geschwat hunn.

Endlech gëtt et eng Léisung Bedreiwer Kader, deem seng Popularitéit wiisst.

Operator Framework ass déi Top Helm Alternativ fir ze berécksiichtegen.

Et ass méi gebierteg zu CNCF a Kubernetes, awer d'Barrière fir d'Entrée ass vill méi héich, Dir musst méi programméiere a Manifestatiounen manner beschreiwen.

Et gi verschidde Addons, wéi Draft, Scaffold. Si maachen d'Liewen vill méi einfach, zum Beispill, si vereinfachen den Zyklus vum Schécken a Start vun Helm fir Entwéckler fir en Testëmfeld z'installéieren. Ech géif hinnen empowerers nennen.

Hei ass eng visuell Diagramm vu wou alles ass.

Op der x-Achs ass den Niveau vun Ärer perséinlecher Kontroll iwwer dat wat geschitt, op der Y-Achs ass den Niveau vun der Gebuert vu Kubernetes. Helm Versioun 2 fällt iergendwou an der Mëtt. An der Versioun 3, net enorm, awer souwuel d'Kontroll an den Niveau vun der Nativeness goufen verbessert. Léisungen um Ksonnet Niveau sinn nach ëmmer manner wéi Helm 2. Wéi och ëmmer, si sinn derwäert ze kucken fir ze wëssen wat soss op dëser Welt ass. Natierlech wäert Äre Konfiguratiounsmanager ënner Ärer Kontroll sinn, awer et ass absolut net gebierteg zu Kubernetes.

Den Operator Framework ass absolut gebierteg zu Kubernetes an erlaabt Iech et vill méi elegant a suergfälteg ze verwalten (awer erënnert Iech un den Entréesniveau). Et ass éischter gëeegent fir eng spezialiséiert Applikatioun an d'Schafung vun der Gestioun dofir, anstatt e Masseharvester fir eng grouss Unzuel vun Uwendungen mat Helm ze packen.

Extenders verbesseren einfach d'Kontroll e bëssen, ergänzen de Workflow oder schneiden Ecken op CI / CD Pipelines.

D'Zukunft vun Helm

Déi gutt Noriicht ass datt Helm 3 kënnt. D'Alpha Versioun vum Helm 3.0.0-alpha.2 ass scho verëffentlecht ginn, Dir kënnt et probéieren. Et ass relativ stabil, awer d'Funktionalitéit ass nach ëmmer limitéiert.

Firwat braucht Dir Helm 3? Als éischt ass dëst eng Geschicht iwwer Verschwannen vun Tiller, als Bestanddeel. Dëst, wéi Dir scho versteet, ass e grousse Schrëtt no vir, well aus der Siicht vun der Sécherheet vun der Architektur ass alles vereinfacht.

Wéi Helm 2 erstallt gouf, wat ëm d'Zäit vu Kubernetes 1.8 war oder souguer virdrun, ware vill vun de Konzepter onreift. Zum Beispill gëtt d'CRD-Konzept elo aktiv ëmgesat, an den Helm wäert benotzen CRDStrukturen ze späicheren. Et wäert méiglech sinn nëmmen de Client ze benotzen an net de Serverdeel z'erhalen. Deementspriechend benotzt gebierteg Kubernetes Kommandoen fir mat Strukturen a Ressourcen ze schaffen. Dëst ass e grousse Schrëtt no vir.

Gesinn erschéngen Ënnerstëtzung fir gebierteg OCI Repositories (Open Container Initiative). Dëst ass eng rieseg Initiativ, an den Helm ass virun allem interesséiert fir seng Charts ze posten. Et kënnt zum Punkt datt zum Beispill Docker Hub vill OCI Standards ënnerstëtzt. Ech roden net, awer vläicht klassesch Docker Repository Ubidder fänken un Iech d'Méiglechkeet ze ginn Är Helm Charts ze hosten.

Déi kontrovers Geschicht fir mech ass Lua Ënnerstëtzung, als Schablounmotor fir Scripten ze schreiwen. Ech sinn net e grousse Fan vu Lua, awer dëst wier eng komplett fakultativ Feature. Ech hunn dat 3 Mol iwwerpréift - Lua benotzen ass net néideg. Dofir, déi, déi Lua benotze wëllen, déi, déi Go gär hunn, mellt Iech bei eisem grousse Camp a benotzt go-tmpl dofir.

Endlech, wat ech definitiv vermësst war Schema Entstoe an Daten Typ Validatioun. Et gi keng Probleemer méi mat Int oder String, kee Besoin fir Null an duebel Zitater ze wéckelen. E JSONS Schema erschéngt dat Iech erlaabt Iech explizit dëst fir Wäerter ze beschreiwen.

Wäert staark iwwerschafft ginn Event-Undriff Modell. Et ass scho konzeptuell beschriwwe ginn. Kuckt d'Helm 3 Branche, an Dir gesitt wéivill Eventer an Haken an aner Saache bäigefüügt goufen, wat vill vereinfachen an, op der anerer Säit, d'Kontroll iwwer d'Deploymentprozesser an d'Reaktiounen op si addéieren.

Helm 3 wäert méi einfach, méi sécher a méi lëschteg sinn, net well mir den Helm 2 net gär hunn, mee well Kubernetes méi fortgeschratt gëtt. Deementspriechend kann Helm d'Entwécklunge vu Kubernetes benotzen an exzellent Manager fir Kubernetes op et kreéieren.

Eng aner gutt Noriicht ass dat DevOpsConf Alexander Khayorov wäert Iech soen, kënne Container sécher sinn? Loosst eis Iech drun erënneren datt d'Konferenz iwwer d'Integratioun vun Entwécklung, Testen an Operatiounsprozesser zu Moskau ofgehale gëtt 30. September an 1. Oktober. Dir kënnt et nach bis den 20. August maachen e Rapport ofginn a sot eis iwwer Är Erfahrung mat der Léisung ee vu ville Aufgaben vun der DevOps Approche.

Follegt Konferenz Checkpoints an Neiegkeeten um Mailing Lëscht и Telegram Kanal.

Source: will.com