De essentie van het verhaal over de populairste pakketbeheerder voor Kubernetes zou kunnen worden weergegeven met een emoji:
- de doos is Helm (wat het dichtst in de buurt komt van de nieuwste Emoji-release);
- slot - beveiliging;
- de kleine man is de oplossing voor het probleem.
In feite zal alles iets ingewikkelder zijn en zit het verhaal vol met technische details Hoe je Helm veilig kunt maken.
- In het kort wat Helm is, voor het geval je het nog niet wist of vergeten bent. Welke problemen lost het op en waar bevindt het zich in het ecosysteem.
- Laten we eens kijken naar de Helm-architectuur. Geen enkel gesprek over beveiliging en hoe u een tool of oplossing veiliger kunt maken, is niet compleet zonder de architectuur van de component te begrijpen.
- Laten we Helm-componenten bespreken.
- De meest brandende vraag is de toekomst: de nieuwe versie van Helm 3.
Alles in dit artikel is van toepassing op Helm 2. Deze versie is momenteel in productie en is hoogstwaarschijnlijk degene die u momenteel gebruikt, en het is de versie die de beveiligingsrisico's bevat.
Over de spreker: Alexander Khayorov () ontwikkelt zich al 10 jaar en helpt de inhoud te verbeteren en sloot zich aan bij de commissie . Nu werkt hij bij Chainstack als ontwikkelingsleider - dit is een hybride tussen een ontwikkelingsmanager en een persoon die verantwoordelijk is voor het opleveren van definitieve releases. Dat wil zeggen, het bevindt zich op het slagveld, waar alles gebeurt, van de creatie van een product tot de werking ervan.
Chainstack is een kleine, actief groeiende startup wiens missie het is om klanten de infrastructuur en complexiteit van het gebruik van gedecentraliseerde applicaties te laten vergeten; het ontwikkelingsteam is gevestigd in Singapore. Vraag Chainstack niet om cryptocurrency te verkopen of te kopen, maar bied aan om te praten over enterprise blockchain-frameworks, en zij zullen u graag antwoorden.
Stuurstand
Dit is een pakket- (grafiek)beheerder voor Kubernetes. De meest intuïtieve en universele manier om applicaties naar een Kubernetes-cluster te brengen.
We hebben het natuurlijk over een meer structurele en industriële aanpak dan het maken van je eigen YAML-manifesten en het schrijven van kleine hulpprogramma's.
Helm is het beste dat momenteel verkrijgbaar en populair is.
Waarom Helm? Vooral omdat het wordt ondersteund door de CNCF. Cloud Native is een grote organisatie en is het moederbedrijf voor projecten Kubernetes, etcd, Fluentd en anderen.
Een ander belangrijk feit is dat Helm een zeer populair project is. Toen ik in januari 2019 begon te praten over hoe je Helm veilig kon maken, had het project duizend sterren op GitHub. In mei waren dat er twaalfduizend.
Veel mensen zijn geïnteresseerd in Helm, dus zelfs als u het nog niet gebruikt, zult u profiteren van de kennis over de veiligheid ervan. Veiligheid is belangrijk.
Het kernteam van Helm wordt ondersteund door Microsoft Azure en is daardoor, in tegenstelling tot veel andere, een redelijk stabiel project. De release van Helm 3 Alpha 2 medio juli geeft aan dat er behoorlijk wat mensen aan het project werken en dat ze de wens en energie hebben om Helm te ontwikkelen en te verbeteren.
Helm lost verschillende kernproblemen van applicatiebeheer op in Kubernetes.
- Applicatie verpakking. Zelfs een applicatie als “Hello, World” op WordPress bestaat al uit verschillende services, en die wil je samen verpakken.
- Het beheren van de complexiteit die gepaard gaat met het beheren van deze applicaties.
- Een levenscyclus die niet eindigt nadat de applicatie is geïnstalleerd of geïmplementeerd. Het blijft leven, het moet geactualiseerd worden, en Helm helpt hierbij en probeert hiervoor de juiste maatregelen en beleid te brengen.
Opzakken het is overzichtelijk georganiseerd: er is metadata aanwezig die volledig overeenkomt met het werk van een reguliere pakketbeheerder voor Linux, Windows of MacOS. Dat wil zeggen een repository, afhankelijkheden van verschillende pakketten, meta-informatie voor applicaties, instellingen, configuratiefuncties, informatie-indexering, enz. Met Helm kunt u dit allemaal voor applicaties verkrijgen en gebruiken.
Complexiteitsbeheer. Als u veel applicaties van hetzelfde type heeft, is parametrisering nodig. Hieruit komen sjablonen voort, maar om te voorkomen dat u uw eigen manier hoeft te bedenken om sjablonen te maken, kunt u gebruik maken van wat Helm kant-en-klaar biedt.
Beheer van de levenscyclus van applicaties - naar mijn mening is dit de meest interessante en onopgeloste vraag. Dit is de reden waarom ik destijds naar Helm kwam. We moesten de levenscyclus van applicaties in de gaten houden en wilden onze CI/CD- en applicatiecycli naar dit paradigma verplaatsen.
Met Helm kunt u:
- implementaties beheren, introduceert het concept van configuratie en revisie;
- met succes een rollback uitvoeren;
- gebruik haken voor verschillende evenementen;
- voeg extra applicatiecontroles toe en reageer op de resultaten ervan.
Bovendien Helm heeft “batterijen” - een groot aantal smakelijke dingen die kunnen worden opgenomen in de vorm van plug-ins, waardoor uw leven eenvoudiger wordt. Plug-ins kunnen onafhankelijk worden geschreven, ze zijn behoorlijk geïsoleerd en vereisen geen harmonieuze architectuur. Als je iets wilt implementeren, raad ik aan om het als plug-in te doen, en het dan eventueel in upstream op te nemen.
Helm is gebaseerd op drie hoofdconcepten:
- Kaartopslag - beschrijving en reeks parametrisaties mogelijk voor uw manifest.
- Config —dat wil zeggen de waarden die zullen worden toegepast (tekst, numerieke waarden, enz.).
- Sinds verzamelt de twee bovenste componenten en samen veranderen ze in Release. Van releases kan een versienummer worden gemaakt, waardoor een georganiseerde levenscyclus wordt bereikt: klein op het moment van installatie en groot op het moment van upgraden, downgraden of terugdraaien.
Helm-architectuur
Het diagram geeft conceptueel de architectuur op hoog niveau van Helm weer.
Laat me je eraan herinneren dat Helm iets is dat verband houdt met Kubernetes. We kunnen daarom niet zonder een Kubernetes-cluster (rechthoek). Het onderdeel kube-apiserver bevindt zich op de master. Zonder Helm hebben we Kubeconfig. Helm brengt een klein binair bestand, als je het zo kunt noemen, het Helm CLI-hulpprogramma, dat op een computer, laptop, mainframe - op wat dan ook wordt geïnstalleerd.
Maar dit is niet genoeg. Helm heeft een servercomponent genaamd Tiller. Het vertegenwoordigt de belangen van Helm binnen het cluster; het is een applicatie binnen het Kubernetes-cluster, net als alle andere.
Het volgende onderdeel van Chart Repo is een opslagplaats met grafieken. Er is een officiële repository en er kan een privérepository van een bedrijf of project zijn.
Wisselwerking
Laten we eens kijken hoe de architectuurcomponenten samenwerken als we een applicatie willen installeren met behulp van Helm.
- We zijn aan het praten
Helm install, ga naar de repository (Chart Repo) en verkrijg een Helm-diagram.
- Het Helm-hulpprogramma (Helm CLI) werkt samen met Kubeconfig om erachter te komen met welk cluster contact moet worden opgenomen.
- Na ontvangst van deze informatie verwijst het hulpprogramma naar Tiller, dat zich in ons cluster bevindt, als een applicatie.
- Tiller roept Kube-apiserver aan om acties uit te voeren in Kubernetes en enkele objecten te maken (services, pods, replica's, geheimen, enz.).
Vervolgens zullen we het diagram ingewikkelder maken om de aanvalsvector te zien waaraan de gehele Helm-architectuur als geheel kan worden blootgesteld. En dan zullen we proberen haar te beschermen.
Aanvalsvector
Het eerste potentiële zwakke punt is bevoorrechte API-gebruiker. Als onderdeel van het plan is dit een hacker die beheerderstoegang heeft gekregen tot de Helm CLI.
Onbevoegde API-gebruiker kan ook een gevaar vormen als het zich ergens in de buurt bevindt. Zo'n gebruiker zal een andere context hebben, hij kan bijvoorbeeld in één clusternaamruimte worden vastgelegd in de Kubeconfig-instellingen.
De meest interessante aanvalsvector kan een proces zijn dat zich in een cluster ergens in de buurt van Tiller bevindt en er toegang toe heeft. Dit kan een webserver of microservice zijn die de netwerkomgeving van het cluster ziet.
Een exotische, maar steeds populairder wordende aanvalsvariant is Chart Repo. Een diagram dat door een gewetenloze auteur is gemaakt, kan onveilige bronnen bevatten, en u zult het voltooien door het in vertrouwen aan te nemen. Of het kan de grafiek vervangen die u downloadt uit de officiële repository en bijvoorbeeld een bron in de vorm van beleid creëren en de toegang ervan escaleren.
Laten we proberen aanvallen van al deze vier kanten af te weren en uit te zoeken waar er problemen zijn in de Helm-architectuur, en waar er misschien geen zijn.
Laten we het diagram vergroten, meer elementen toevoegen, maar alle basiscomponenten behouden.
De Helm CLI communiceert met de Chart Repo, werkt samen met Kubeconfig en het werk wordt overgebracht naar het cluster naar de Tiller-component.
Tiller wordt weergegeven door twee objecten:
- Tiller-deploy svc, die een bepaalde service blootlegt;
- Tiller-deploy pod (in het diagram in één exemplaar in één replica), waarop de volledige belasting draait, die toegang heeft tot het cluster.
Voor de interactie worden verschillende protocollen en schema's gebruikt. Vanuit veiligheidsoogpunt zijn wij het meest geïnteresseerd in:
- Het mechanisme waarmee de Helm CLI toegang krijgt tot de kaartrepository: welk protocol, is er authenticatie en wat kan ermee worden gedaan.
- Het protocol waarmee Helm CLI, met behulp van kubectl, communiceert met Tiller. Dit is een RPC-server die in het cluster is geïnstalleerd.
- Tiller zelf is toegankelijk voor microservices die zich in het cluster bevinden en communiceert met de Kube-apiserver.
Laten we al deze gebieden in volgorde bespreken.
RBAC
Het heeft geen zin om over beveiliging voor Helm of een andere service binnen het cluster te praten, tenzij RBAC is ingeschakeld.
Het lijkt erop dat dit niet de laatste aanbeveling is, maar ik ben er zeker van dat veel mensen RBAC zelfs in productie nog steeds niet hebben ingeschakeld, omdat het een hoop gedoe is en er veel dingen moeten worden geconfigureerd. Ik moedig u echter aan dit te doen.
- website-advocaat voor RBAC. Het bevat een enorme hoeveelheid interessante materialen die je zullen helpen bij het opzetten van RBAC, laten zien waarom het goed is en hoe je er in principe mee kunt leven in de productie.
Ik zal proberen uit te leggen hoe Tiller en RBAC werken. Tiller werkt binnen het cluster onder een bepaald serviceaccount. Als RBAC niet is geconfigureerd, is dit doorgaans de superuser. In de basisconfiguratie zal Tiller een beheerder zijn. Dit is de reden waarom er vaak wordt gezegd dat Tiller een SSH-tunnel naar uw cluster is. In feite is dit waar, dus u kunt een afzonderlijk speciaal serviceaccount gebruiken in plaats van het standaardserviceaccount in het bovenstaande diagram.
Wanneer u Helm initialiseert en voor de eerste keer op de server installeert, kunt u het serviceaccount instellen met behulp van --service-account. Hierdoor kunt u een gebruiker gebruiken met de minimaal vereiste set rechten. Toegegeven, je zult zo'n "slinger" moeten maken: Role en RoleBinding.
Helaas zal Helm dit niet voor je doen. U of uw Kubernetes-clusterbeheerder moet vooraf een set rollen en rolbindingen voor het serviceaccount voorbereiden om Helm te kunnen doorgeven.
De vraag rijst: wat is het verschil tussen Role en ClusterRole? Het verschil is dat ClusterRole voor alle naamruimten werkt, in tegenstelling tot reguliere Roles en RoleBindings, die alleen voor een gespecialiseerde naamruimte werken. U kunt beleid configureren voor het hele cluster en alle naamruimten, of voor elke naamruimte afzonderlijk personaliseren.
Het is vermeldenswaard dat RBAC een ander groot probleem oplost. Veel mensen klagen dat Helm helaas geen multitenancy is (geen ondersteuning biedt voor multitenancy). Als meerdere teams een cluster gebruiken en Helm gebruiken, is het in principe onmogelijk om beleid in te stellen en hun toegang binnen dit cluster te beperken, omdat er een bepaald serviceaccount is waaronder Helm draait, en van daaruit alle bronnen in het cluster worden aangemaakt. , wat soms erg lastig is. Dit is waar, net als het binaire bestand zelf, net als het proces, Helm Tiller heeft geen concept van multitenancy.
Er is echter een geweldige manier waarop u Tiller meerdere keren in een cluster kunt uitvoeren. Dit is geen probleem, Tiller kan in elke naamruimte worden gestart. U kunt dus RBAC en Kubeconfig als context gebruiken en de toegang tot een speciale Helm beperken.
Het zal er zo uitzien.
Er zijn bijvoorbeeld twee Kubeconfigs met context voor verschillende teams (twee naamruimten): X Team voor het ontwikkelteam en het beheerderscluster. Het beheerderscluster heeft zijn eigen brede Tiller, die zich in de Kube-systeemnaamruimte bevindt, een overeenkomstig geavanceerd serviceaccount. En een aparte naamruimte voor het ontwikkelteam, zij kunnen hun diensten inzetten in een speciale naamruimte.
Dit is een werkbare aanpak; Tiller heeft niet zoveel energie nodig dat dit grote gevolgen zal hebben voor uw budget. Dit is een van de snelle oplossingen.
Voel je vrij om Tiller afzonderlijk te configureren en Kubeconfig te voorzien van context voor het team, voor een specifieke ontwikkelaar of voor de omgeving: Dev, Staging, Production (het is twijfelachtig of alles zich op hetzelfde cluster zal bevinden, maar dit kan wel).
Laten we ons verhaal voortzetten en overstappen van RBAC en praten over ConfigMaps.
configuratiekaarten
Helm gebruikt ConfigMaps als gegevensopslag. Toen we het over architectuur hadden, was er nergens een database die informatie zou opslaan over releases, configuraties, rollbacks, etc. Hiervoor wordt ConfigMaps gebruikt.
Het grootste probleem met ConfigMaps is bekend: ze zijn in principe onveilig; het is onmogelijk om gevoelige gegevens op te slaan. We hebben het over alles dat niet verder mag gaan dan de service, bijvoorbeeld wachtwoorden. De meest native manier voor Helm op dit moment is om over te schakelen van het gebruik van ConfigMaps naar geheimen.
Dit gebeurt heel eenvoudig. Overschrijf de Tiller-instelling en geef op dat de opslag geheim zal zijn. Vervolgens ontvangt u voor elke implementatie geen ConfigMap, maar een geheim.
Je zou kunnen stellen dat geheimen op zichzelf een vreemd concept zijn en niet erg veilig. Het is echter de moeite waard om te begrijpen dat de Kubernetes-ontwikkelaars dit zelf doen. Vanaf versie 1.10, d.w.z. Het is al geruime tijd mogelijk, althans in publieke clouds, om de juiste opslag aan te sluiten om geheimen op te slaan. Het team werkt nu aan manieren om de toegang tot geheimen, individuele pods of andere entiteiten beter te verdelen.
Het is beter om Storage Helm over te dragen aan geheimen, en deze worden op hun beurt centraal beveiligd.
Uiteraard zal dat zo blijven gegevensopslaglimiet van 1 MB. Helm gebruikt hier etcd als gedistribueerde opslag voor ConfigMaps. En daar vonden ze dat dit een geschikt gegevensfragment was voor replicatie, enz. Er is een interessante discussie hierover op Reddit, ik raad aan om dit grappige leesvoer voor het weekend te vinden of het uittreksel te lezen .
Grafiekopslagplaatsen
Grafieken zijn sociaal het meest kwetsbaar en kunnen een bron van “Man in the middle” worden, vooral als u een aandelenoplossing gebruikt. Allereerst hebben we het over repositories die via HTTP toegankelijk zijn.
U moet Helm Repo zeker via HTTPS beschikbaar stellen - dit is de beste optie en is niet duur.
Besteed aandacht aan diagramhandtekeningmechanisme. De technologie is zo simpel als de hel. Dit is hetzelfde dat je gebruikt op GitHub, een gewone PGP-machine met publieke en private sleutels. Stel het in en zorg ervoor dat u over de benodigde sleutels beschikt en alles ondertekent, dat dit echt uw diagram is.
Bovendien Helm-client ondersteunt TLS (niet in de HTTP-zin van de server, maar wederzijdse TLS). Om te communiceren kunt u server- en clientsleutels gebruiken. Eerlijk gezegd gebruik ik zo’n mechanisme niet omdat ik niet van onderlinge certificaten houd. In principe, - het belangrijkste hulpmiddel voor het instellen van Helm Repo voor Helm 2 - ondersteunt ook basisauthenticatie. U kunt basisauthenticatie gebruiken als dit handiger en stiller is.
Er is ook een plug-in , waarmee u Chart Repos op Google Cloud Storage kunt hosten. Dit is best handig, werkt prima en is redelijk veilig, omdat alle beschreven mechanismen gerecycled zijn.
Als u HTTPS of TLS inschakelt, mTLS gebruikt en basisverificatie inschakelt om de risico's verder te verminderen, krijgt u een beveiligd communicatiekanaal met Helm CLI en Chart Repo.
gRPC-API
De volgende stap is erg belangrijk: het beveiligen van Tiller, die zich in het cluster bevindt en enerzijds een server is, maar anderzijds zelf toegang heeft tot andere componenten en probeert zich voor te doen als iemand.
Zoals ik al zei, is Tiller een service die gRPC blootlegt, de Helm-client komt er via gRPC naar toe. Standaard is TLS uiteraard uitgeschakeld. Waarom dit werd gedaan is een discutabel vraag; het lijkt mij om de opzet in het begin te vereenvoudigen.
Voor productie en zelfs enscenering raad ik aan TLS op gRPC in te schakelen.
Naar mijn mening is dit, in tegenstelling tot mTLS voor kaarten, hier passend en wordt het heel eenvoudig gedaan: genereer een PQI-infrastructuur, maak een certificaat aan, start Tiller, draag het certificaat over tijdens initialisatie. Hierna kunt u alle Helm-opdrachten uitvoeren, waarbij u uzelf het gegenereerde certificaat en de privésleutel presenteert.
Zo bescherm je jezelf tegen alle verzoeken aan Tiller van buiten het cluster.
We hebben dus het verbindingskanaal met Tiller beveiligd, we hebben RBAC al besproken en de rechten van de Kubernetes-apiserver aangepast, waardoor het domein waarmee deze kan communiceren, is verkleind.
Beschermde helm
Laten we naar het uiteindelijke diagram kijken. Het is dezelfde architectuur met dezelfde pijlen.
Alle verbindingen kunnen nu veilig in het groen worden getekend:
- voor Chart Repo gebruiken we TLS of mTLS en basisauthenticatie;
- mTLS voor Tiller, en het wordt aangeboden als een gRPC-service met TLS, we gebruiken certificaten;
- het cluster maakt gebruik van een speciaal serviceaccount met Role en RoleBinding.
We hebben het cluster aanzienlijk beveiligd, maar een slim iemand zei:
“Er kan maar één absoluut veilige oplossing zijn: een uitgeschakelde computer, die zich in een betonnen kist bevindt en wordt bewaakt door soldaten.”
Er zijn verschillende manieren om gegevens te manipuleren en nieuwe aanvalsvectoren te vinden. Ik ben er echter van overtuigd dat deze aanbevelingen zullen leiden tot een industriële basisnorm op het gebied van veiligheid.
Bonus
Dit deel heeft niet direct betrekking op beveiliging, maar zal ook nuttig zijn. Ik zal je een aantal interessante dingen laten zien die maar weinig mensen weten. Bijvoorbeeld hoe u naar grafieken kunt zoeken - officieel en niet-officieel.
In de repository Nu zijn er ongeveer 300 kaarten en twee streams: stabiel en incubator. Iedereen die een bijdrage levert, weet heel goed hoe moeilijk het is om van couveuse naar stal te gaan, en hoe gemakkelijk het is om uit stal te vliegen. Dit is echter niet het beste hulpmiddel om naar kaarten voor Prometheus en wat u maar wilt te zoeken, om één simpele reden: het is geen portaal waar u gemakkelijk naar pakketten kunt zoeken.
Maar er is een dienst , waardoor het veel handiger is om grafieken te vinden. Het belangrijkste is dat er veel meer externe opslagplaatsen en bijna 800 charms beschikbaar zijn. Bovendien kunt u uw repository verbinden als u om welke reden dan ook uw grafieken niet naar stable wilt sturen.
Probeer hub.helm.sh en laten we het samen ontwikkelen. Deze service valt onder het Helm-project en u kunt zelfs bijdragen aan de gebruikersinterface als u een front-end-ontwikkelaar bent en alleen het uiterlijk wilt verbeteren.
Ik wil er ook graag uw aandacht op vestigen Open Service Broker API-integratie. Het klinkt omslachtig en onduidelijk, maar het lost problemen op waar iedereen mee te maken heeft. Laat me het uitleggen met een eenvoudig voorbeeld.
Er is een Kubernetes-cluster waarin we een klassieke applicatie willen draaien: WordPress. Over het algemeen is een database nodig voor volledige functionaliteit. Er zijn veel verschillende oplossingen, u kunt bijvoorbeeld uw eigen statefull-service lanceren. Dit is niet erg handig, maar veel mensen doen het.
Anderen, zoals wij bij Chainstack, gebruiken beheerde databases zoals MySQL of PostgreSQL voor hun servers. Daarom staan onze databases ergens in de cloud.
Maar er doet zich een probleem voor: we moeten onze dienst verbinden met een database, een databaseversie creëren, de referenties overdragen en deze op de een of andere manier beheren. Dit alles wordt meestal handmatig gedaan door de systeembeheerder of ontwikkelaar. En er is geen probleem als er weinig aanmeldingen zijn. Als er veel zijn, heb je een maaidorser nodig. Er is zo'n oogstmachine - het is Service Broker. Hiermee kunt u een speciale plug-in voor een openbaar cloudcluster gebruiken en via Broker resources bij de provider bestellen, alsof het een API is. Hiervoor kunt u native Kubernetes-tools gebruiken.
Het is heel simpel. U kunt bijvoorbeeld Managed MySQL in Azure opvragen met een basislaag (dit kan worden geconfigureerd). Met behulp van de Azure API wordt de database aangemaakt en klaargemaakt voor gebruik. Je hoeft je hier niet mee te bemoeien, de plugin is hiervoor verantwoordelijk. OSBA (Azure-plug-in) retourneert bijvoorbeeld de referentie aan de service en geeft deze door aan Helm. U kunt WordPress gebruiken met cloud MySQL, u hoeft helemaal niet met beheerde databases om te gaan en u hoeft zich geen zorgen te maken over de volledige services daarin.
We kunnen zeggen dat Helm fungeert als een lijm waarmee je enerzijds diensten kunt inzetten en anderzijds de middelen van cloudproviders kunt verbruiken.
U kunt uw eigen plug-in schrijven en dit hele verhaal ter plaatse gebruiken. Dan heeft u eenvoudigweg uw eigen plugin voor de corporate Cloud provider. Ik raad aan deze aanpak te proberen, vooral als je grootschalig bent en snel dev, staging of de hele infrastructuur voor een functie wilt implementeren. Dit maakt het leven eenvoudiger voor uw activiteiten of DevOps.
Een andere vondst die ik al noemde is helm-gcs-plug-in, waarmee u Google-buckets (objectopslag) kunt gebruiken om Helm-diagrammen op te slaan.
U hebt slechts vier opdrachten nodig om het te kunnen gebruiken:
- installeer de plug-in;
- initiëren;
- stel het pad in naar de bucket, die zich in gcp bevindt;
- publiceer grafieken op de standaardmanier.
Het mooie is dat voor autorisatie de native gcp-methode wordt gebruikt. U kunt een serviceaccount, een ontwikkelaarsaccount of wat u maar wilt gebruiken. Het is erg handig en kost niets om te bedienen. Als je, net als ik, de opsless-filosofie promoot, dan zal dit erg handig zijn, vooral voor kleine teams.
alternatieven
Helm is niet de enige servicemanagementoplossing. Er zijn veel vragen over, wat waarschijnlijk de reden is dat de derde versie zo snel verscheen. Natuurlijk zijn er alternatieven.
Dit kunnen gespecialiseerde oplossingen zijn, bijvoorbeeld Ksonnet of Metaarticle. U kunt uw klassieke tools voor infrastructuurbeheer (Ansible, Terraform, Chef, enz.) gebruiken voor dezelfde doeleinden waar ik het over had.
Eindelijk is er een oplossing , wiens populariteit groeit.
Operator Framework is het beste Helm-alternatief om te overwegen.
Het is meer eigen aan CNCF en Kubernetes, maar de toetredingsdrempel is veel hoger, moet je meer programmeren en minder manifesten beschrijven.
Er zijn verschillende add-ons, zoals Draft, Scaffold. Ze maken het leven een stuk eenvoudiger, ze vereenvoudigen bijvoorbeeld de cyclus van het verzenden en starten van Helm zodat ontwikkelaars een testomgeving kunnen inzetten. Ik zou ze empowerers willen noemen.
Hier is een visueel diagram van waar alles is.
Op de x-as staat het niveau van uw persoonlijke controle over wat er gebeurt, op de y-as staat het niveau van nativeness van Kubernetes. Helmversie 2 valt ergens in het midden. In versie 3 niet enorm, maar zowel de besturing als het niveau van nativeness zijn verbeterd. Oplossingen op Ksonnet-niveau zijn zelfs nog steeds inferieur aan Helm 2. Ze zijn echter de moeite waard om naar te kijken om te weten wat er nog meer in deze wereld is. Natuurlijk heeft u de controle over uw configuratiemanager, maar deze is absoluut niet eigen aan Kubernetes.
Het Operator Framework is absoluut eigen aan Kubernetes en stelt u in staat het veel eleganter en nauwgezeter te beheren (maar onthoud het instapniveau). Dit is eerder geschikt voor een gespecialiseerde toepassing en het creëren van beheer daarvoor, in plaats van een massa-oogstmachine voor het verpakken van een groot aantal toepassingen met behulp van Helm.
Extenders verbeteren eenvoudigweg de controle een beetje, vullen de workflow aan of bezuinigen op CI/CD-pijplijnen.
De toekomst van Helm
Het goede nieuws is dat Helm 3 eraan komt. De alfaversie van Helm 3.0.0-alpha.2 is al uitgebracht, je kunt hem proberen. Het is vrij stabiel, maar de functionaliteit is nog steeds beperkt.
Waarom heb je Helm 3 nodig? Allereerst gaat dit over een verhaal verdwijning van Tiller, als onderdeel. Dit is, zoals je al begrijpt, een enorme stap voorwaarts, omdat vanuit het oogpunt van de veiligheid van de architectuur alles vereenvoudigd is.
Toen Helm 2 werd gemaakt, rond de tijd van Kubernetes 1.8 of zelfs eerder, waren veel van de concepten nog onvolwassen. Zo wordt het CRD-concept nu actief geïmplementeerd, en Helm zal dat ook doen gebruik CRDstructuren op te slaan. Het is mogelijk om alleen de client te gebruiken en het servergedeelte niet te onderhouden. Gebruik daarom native Kubernetes-opdrachten om met structuren en bronnen te werken. Dit is een enorme stap voorwaarts.
Zal verschijnen ondersteuning voor native OCI-repository's (Open Container-initiatief). Dit is een enorm initiatief en Helm is vooral geïnteresseerd in het publiceren van de hitlijsten. Het komt op het punt dat Docker Hub bijvoorbeeld veel OCI-standaarden ondersteunt. Ik gok er niet op, maar misschien zullen klassieke Docker-repositoryproviders je de mogelijkheid gaan bieden om je Helm-grafieken te hosten.
Het controversiële verhaal voor mij is Lua-ondersteuning, als sjabloonengine voor het schrijven van scripts. Ik ben geen grote fan van Lua, maar dit zou een volledig optionele functie zijn. Ik heb dit drie keer gecontroleerd - het gebruik van Lua is niet nodig. Daarom sluiten degenen die Lua willen gebruiken, degenen die van Go houden, zich aan bij ons enorme kamp en gebruiken hiervoor go-tmpl.
Eindelijk, wat ik absoluut miste was het ontstaan van schema's en validatie van gegevenstypes. Er zullen geen problemen meer zijn met int of string, het is niet nodig om nul tussen dubbele aanhalingstekens te plaatsen. Er verschijnt een JSONS-schema waarmee u dit expliciet voor waarden kunt beschrijven.
Zal zwaar herwerkt worden gebeurtenisgedreven model. Het is al conceptueel beschreven. Kijk naar de Helm 3-tak en je zult zien hoeveel evenementen, hooks en andere dingen zijn toegevoegd, wat de implementatieprocessen en reacties daarop enorm zal vereenvoudigen en aan de andere kant controle zal toevoegen.
Helm 3 zal eenvoudiger, veiliger en leuker zijn, niet omdat we Helm 2 niet leuk vinden, maar omdat Kubernetes steeds geavanceerder wordt. Dienovereenkomstig kan Helm de ontwikkelingen van Kubernetes gebruiken en daarop uitstekende managers voor Kubernetes creëren.
Nog een goed nieuws is dat Alexander Khayorov zal je vertellen: Laten we u eraan herinneren dat de conferentie over de integratie van ontwikkelings-, test- en operationele processen in Moskou zal plaatsvinden 30 september en 1 oktober. Dat kan nog tot 20 augustus en vertel ons over uw ervaringen met de oplossing taken van de DevOps-aanpak.
Volg conferentiecontrolepunten en nieuws op и .
Bron: www.habr.com