🥇Introductie tot Helm 3

Opmerking. vert.: 16 mei van dit jaar markeert een belangrijke mijlpaal in de ontwikkeling van de pakketbeheerder voor Kubernetes - Helm. Op deze dag werd de eerste alpha-release van de toekomstige hoofdversie van het project - 3.0 - gepresenteerd. De release ervan zal belangrijke en langverwachte veranderingen voor Helm met zich meebrengen, waar velen in de Kubernetes-gemeenschap hoge verwachtingen van hebben. Wijzelf zijn daar één van, omdat we Helm actief gebruiken voor applicatie-implementatie: we hebben het geïntegreerd in onze tool voor het implementeren van CI/CD werf en van tijd tot tijd leveren wij onze bijdrage aan de ontwikkeling van upstream. Deze vertaling combineert 7 aantekeningen van de officiële Helm-blog, die zijn gewijd aan de eerste alpha-release van Helm 3 en die gaan over de geschiedenis van het project en de belangrijkste kenmerken van Helm 3. De auteur is Matt “bacongobbler” Fisher, een medewerker van Microsoft en een van de belangrijkste beheerders van Helm.

Op 15 oktober 2015 werd het project dat nu bekend staat als Helm geboren. Slechts een jaar na de oprichting sloot de Helm-gemeenschap zich aan bij Kubernetes, terwijl ze actief werkte aan Helm 2. In juni 2018 sloot Helm sloot zich aan bij de CNCF als een ontwikkelingsproject (incubatieproject). Snel vooruit naar het heden en de eerste alpha-release van de nieuwe Helm 3 komt eraan. (deze uitgave heeft al plaatsgevonden medio mei - ca. vert.).

In dit stuk zal ik het hebben over waar het allemaal begon, hoe we zijn gekomen waar we nu zijn, enkele van de unieke functies introduceren die beschikbaar zijn in de eerste alpha-release van Helm 3, en uitleggen hoe we van plan zijn verder te gaan.

Samenvatting:

de geschiedenis van de oprichting van Helm;
een teder afscheid van Tiller;
kaartopslagplaatsen;
releasebeheer;
veranderingen in diagramafhankelijkheden;
bibliotheekkaarten;
wat is het volgende?

De geschiedenis van Helm

geboorte

Helm 1 begon als een Open Source-project gemaakt door Deis. We waren een kleine startup geabsorbeerd Microsoft in het voorjaar van 2017. Ons andere Open Source-project, ook Deis genaamd, had een tool deisctl, waarmee (onder meer) het Deis-platform werd geïnstalleerd en geëxploiteerd Vlootcluster. Fleet was destijds een van de eerste containerorkestratieplatforms.

Medio 2015 besloten we het roer om te gooien en verhuisden Deis (destijds omgedoopt tot Deis Workflow) van Fleet naar Kubernetes. Een van de eerste die opnieuw werd ontworpen, was de installatietool. deisctl. We gebruikten het om Deis Workflow in het Fleet-cluster te installeren en te beheren.

Helm 1 is gemaakt naar het beeld van beroemde pakketbeheerders zoals Homebrew, apt en yum. Het belangrijkste doel was om taken zoals het verpakken en installeren van applicaties op Kubernetes te vereenvoudigen. Helm werd in 2015 officieel geïntroduceerd op de KubeCon-conferentie in San Francisco.

Onze eerste poging met Helm werkte, maar het was niet zonder enkele ernstige beperkingen. Hij nam een reeks Kubernetes-manifesten, op smaak gebracht met generatoren als inleidende YAML-blokken (voorzaak)*, en laadde de resultaten in Kubernetes.

* Opmerking. vert.: Vanaf de eerste versie van Helm werd gekozen voor de YAML-syntaxis om Kubernetes-bronnen te beschrijven, en werden Jinja-sjablonen en Python-scripts ondersteund bij het schrijven van configuraties. Meer hierover en de structuur van de eerste versie van Helm in het algemeen schreven we in het hoofdstuk “A Brief History of Helm” dit materiaal.

Om bijvoorbeeld een veld in een YAML-bestand te vervangen, moest u de volgende constructie aan het manifest toevoegen:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Het is geweldig dat er tegenwoordig sjabloonengines bestaan, nietwaar?

Om vele redenen had dit vroege Kubernetes-installatieprogramma een hardgecodeerde lijst met manifestbestanden nodig en voerde het slechts een kleine, vaste reeks gebeurtenissen uit. Het was zo moeilijk te gebruiken dat het Deis Workflow R&D-team het moeilijk had toen ze probeerden hun product naar dit platform over te brengen, maar de kiem voor het idee was al gezaaid. Onze eerste poging was een geweldige leermogelijkheid: we realiseerden ons dat we echt gepassioneerd waren in het creëren van pragmatische tools die alledaagse problemen voor onze gebruikers oplossen.

Op basis van de ervaring met fouten uit het verleden zijn we begonnen met de ontwikkeling van Helm 2.

Roer maken 2

Eind 2015 nam het Google-team contact met ons op. Ze werkten aan een soortgelijke tool voor Kubernetes. Deployment Manager voor Kubernetes was een port van een bestaande tool die werd gebruikt voor Google Cloud Platform. ‘Zouden we het leuk vinden’, vroegen ze, ‘een paar dagen de tijd te nemen om de overeenkomsten en verschillen te bespreken?’

In januari 2016 kwamen de teams Helm en Deployment Manager bijeen in Seattle om ideeën uit te wisselen. De onderhandelingen eindigden met een ambitieus plan: beide projecten combineren om Helm 2 te creëren. Samen met Deis en Google, de jongens van SkippBox (nu onderdeel van Bitnami - ca. vert.), en we begonnen te werken aan Helm 2.

We wilden het gebruiksgemak van Helm behouden, maar voegen het volgende toe:

grafieksjablonen voor maatwerk;
intraclusterbeheer voor teams;
kaartenopslag van wereldklasse;
stabiel pakketformaat met handtekeningoptie;
een sterke toewijding aan semantisch versiebeheer en het handhaven van achterwaartse compatibiliteit tussen versies.

Om deze doelen te bereiken is er een tweede element toegevoegd aan het Helm-ecosysteem. Deze intra-clustercomponent heette Tiller en was verantwoordelijk voor het installeren en beheren van Helm-kaarten.

Sinds de release van Helm 2 in 2016 heeft Kubernetes een aantal grote innovaties toegevoegd. Rolgebaseerde toegangscontrole toegevoegd (RBAC), dat uiteindelijk Attribute-Based Access Control (ABAC) verving. Er werden nieuwe resourcetypen geïntroduceerd (implementaties bevonden zich toen nog in de bètafase). Er zijn aangepaste resourcedefinities (oorspronkelijk Third Party Resources of TPR's genoemd) uitgevonden. En het allerbelangrijkste: er is een reeks best practices ontstaan.

Te midden van al deze veranderingen bleef Helm Kubernetes-gebruikers trouw van dienst. Na drie jaar en veel nieuwe toevoegingen was het duidelijk dat het tijd was om aanzienlijke wijzigingen in de codebase aan te brengen om ervoor te zorgen dat Helm kon blijven voldoen aan de groeiende behoeften van een evoluerend ecosysteem.

Een teder afscheid van Tiller

Tijdens de ontwikkeling van Helm 2 hebben we Tiller geïntroduceerd als onderdeel van onze integratie met Deployment Manager van Google. Tiller speelde een belangrijke rol voor teams die binnen een gemeenschappelijk cluster werkten: het stelde verschillende specialisten die de infrastructuur beheerden in staat om met dezelfde reeks releases te communiceren.

Omdat op rollen gebaseerde toegangscontrole (RBAC) standaard was ingeschakeld in Kubernetes 1.6, werd het werken met Tiller in de productie moeilijker. Vanwege het enorme aantal mogelijke beveiligingsbeleidslijnen is ons standpunt geweest om standaard een tolerante configuratie aan te bieden. Hierdoor konden nieuwkomers experimenteren met Helm en Kubernetes zonder eerst in de beveiligingsinstellingen te hoeven duiken. Helaas kan deze machtigingsconfiguratie de gebruiker een te breed scala aan machtigingen geven die hij niet nodig heeft. DevOps- en SRE-ingenieurs moesten aanvullende operationele stappen leren bij het installeren van Tiller in een multi-tenant cluster.

Nadat we hadden geleerd hoe de community Helm in specifieke situaties gebruikte, realiseerden we ons dat het releasebeheersysteem van Tiller niet afhankelijk hoefde te zijn van een intra-clustercomponent om de status te behouden of te functioneren als een centrale hub voor release-informatie. In plaats daarvan konden we eenvoudigweg informatie ontvangen van de Kubernetes API-server, een diagram genereren aan de clientzijde en een record van de installatie opslaan in Kubernetes.

Het hoofddoel van Tiller had zonder Tiller kunnen worden bereikt, dus een van onze eerste beslissingen met betrekking tot Helm 3 was om Tiller volledig te verlaten.

Nu Tiller er niet meer is, is het beveiligingsmodel van Helm radicaal vereenvoudigd. Helm 3 ondersteunt nu alle moderne beveiligings-, identiteits- en autorisatiemethoden van de huidige Kubernetes. Helm-machtigingen worden bepaald met behulp van kubeconfig-bestand. Clusterbeheerders kunnen gebruikersrechten beperken tot elk detailniveau. Releases worden nog steeds binnen het cluster opgeslagen en de rest van de Helm-functionaliteit blijft intact.

Grafiekopslagplaatsen

Op een hoog niveau is een diagramrepository een plaats waar diagrammen kunnen worden opgeslagen en gedeeld. De Helm-client verpakt en verzendt de diagrammen naar de repository. Simpel gezegd is een diagramrepository een primitieve HTTP-server met een index.yaml-bestand en enkele verpakte diagrammen.

Hoewel er enkele voordelen zijn verbonden aan het voldoen aan de meeste elementaire opslagvereisten van de Charts Repository API, zijn er ook enkele nadelen:

Grafiekopslagplaatsen zijn niet compatibel met de meeste beveiligingsimplementaties die vereist zijn in een productieomgeving. Het hebben van een standaard API voor authenticatie en autorisatie is uiterst belangrijk in productiescenario’s.
Helm's tools voor de herkomst van kaarten, die worden gebruikt om de integriteit en herkomst van een kaart te ondertekenen en te verifiëren, zijn een optioneel onderdeel van het kaartpublicatieproces.
In scenario's voor meerdere gebruikers kan hetzelfde diagram door een andere gebruiker worden geüpload, waardoor de hoeveelheid ruimte die nodig is om dezelfde inhoud op te slaan, wordt verdubbeld. Om dit probleem op te lossen zijn slimmere repositories ontwikkeld, maar deze maken geen deel uit van de formele specificatie.
Het gebruik van één enkel indexbestand voor het zoeken, opslaan van metagegevens en het ophalen van grafieken heeft het moeilijk gemaakt om veilige implementaties voor meerdere gebruikers te ontwikkelen.

Project Docker-distributie (ook bekend als Docker Registry v2) is de opvolger van Docker Registry en fungeert in wezen als een set tools voor het verpakken, verzenden, opslaan en leveren van Docker-images. Veel grote clouddiensten bieden op distributie gebaseerde producten. Dankzij deze toegenomen aandacht heeft het Distributieproject geprofiteerd van jarenlange verbeteringen, best practices op het gebied van beveiliging en veldtesten, waardoor het een van de meest succesvolle onbezongen helden van de Open Source-wereld is geworden.

Maar wist u dat het Distributieproject is ontworpen om elke vorm van inhoud te distribueren, niet alleen containerafbeeldingen?

Dankzij de inspanningen Open Container-initiatief (of OCI), kunnen Helm-diagrammen op elk distributie-exemplaar worden geplaatst. Voorlopig is dit proces experimenteel. Inlogondersteuning en andere functies die nodig zijn voor een volledige Helm 3 zijn een werk in uitvoering, maar we zijn verheugd om te leren van de ontdekkingen die de OCI- en distributieteams door de jaren heen hebben gedaan. En door hun mentorschap en begeleiding leren we hoe het is om op schaal een zeer beschikbare dienst te exploiteren.

Er is een meer gedetailleerde beschrijving beschikbaar van enkele aankomende wijzigingen in de Helm-diagramopslagplaatsen link.

авление елизами

In Helm 3 wordt de applicatiestatus binnen het cluster gevolgd door een paar objecten:

release-object - vertegenwoordigt een applicatie-instantie;
releaseversiegeheim - vertegenwoordigt de gewenste status van de applicatie op een specifiek tijdstip (bijvoorbeeld de release van een nieuwe versie).

telefoontje helm install maakt een releaseobject en een releaseversiegeheim. Telefoongesprek helm upgrade vereist een releaseobject (dat het kan wijzigen) en creëert een nieuw releaseversiegeheim met de nieuwe waarden en een voorbereid manifest.

Release-object bevat informatie over de release, waarbij release een specifieke installatie is van een benoemd diagram en waarden. Dit object beschrijft de metadata op het hoogste niveau over de release. Het release-object blijft gedurende de hele levenscyclus van de toepassing bestaan en is de eigenaar van alle releaseversiegeheimen, evenals van alle objecten die rechtstreeks door het Helm-diagram worden gemaakt.

Het releaseversiegeheim koppelt een release aan een reeks revisies (installatie, updates, rollbacks, verwijdering).

In Helm 2 waren de herzieningen uiterst consistent. Telefoongesprek helm install gemaakt v1, de daaropvolgende update (upgrade) - v2, enzovoort. Release en releaseversiegeheim zijn samengevoegd tot één object dat bekend staat als revisie. Revisies werden opgeslagen in dezelfde naamruimte als Tiller, wat betekende dat elke release "globaal" was qua naamruimte; Als gevolg hiervan kon slechts één exemplaar van de naam worden gebruikt.

In Helm 3 is elke release gekoppeld aan een of meer releaseversiegeheimen. Het release-object beschrijft altijd de huidige release die in Kubernetes is geïmplementeerd. Elk releaseversiegeheim beschrijft slechts één versie van die release. Een upgrade zal bijvoorbeeld een nieuw releaseversiegeheim creëren en vervolgens het releaseobject wijzigen zodat het naar die nieuwe versie verwijst. In het geval van een terugdraaiing kunt u versiegeheimen van eerdere releases gebruiken om de release terug te draaien naar een eerdere staat.

Nadat Tiller is verlaten, slaat Helm 3 releasegegevens op in dezelfde naamruimte als de release. Met deze wijziging kunt u een diagram met dezelfde releasenaam in een andere naamruimte installeren en worden de gegevens opgeslagen tussen clusterupdates/opnieuw opstarten in etcd. U kunt bijvoorbeeld WordPress installeren in de naamruimte "foo" en vervolgens in de naamruimte "bar", en beide releases kunnen de naam "wordpress" krijgen.

Wijzigingen in diagramafhankelijkheden

Grafieken verpakt (met behulp van helm package) voor gebruik met Helm 2 kan worden geïnstalleerd met Helm 3, maar de werkstroom voor het ontwikkelen van diagrammen is volledig herzien, dus er moeten enkele wijzigingen worden aangebracht om de ontwikkeling van diagrammen met Helm 3 voort te zetten. Met name het beheersysteem voor diagramafhankelijkheid is veranderd.

Het afhankelijkheidsbeheersysteem van het diagram is verplaatst van requirements.yaml и requirements.lock op Chart.yaml и Chart.lock. Dit betekent dat de grafieken die de opdracht hebben gebruikt helm dependency, vereist enige configuratie om in Helm 3 te werken.

Laten we eens kijken naar een voorbeeld. Laten we een afhankelijkheid toevoegen aan het diagram in Helm 2 en kijken wat er verandert als we naar Helm 3 gaan.

In Helm 2 requirements.yaml zag er zo uit:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

In Helm 3 wordt dezelfde afhankelijkheid weerspiegeld in uw Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Grafieken worden nog steeds gedownload en in de directory geplaatst charts/, dus subdiagrammen (subgrafieken), liggend in de catalogus charts/, zal zonder wijzigingen blijven werken.

Introductie van bibliotheekgrafieken

Helm 3 ondersteunt een klasse diagrammen die bibliotheekdiagrammen worden genoemd (bibliotheekdiagram). Dit diagram wordt door andere diagrammen gebruikt, maar veroorzaakt op zichzelf geen release-artefacten. Sjablonen voor bibliotheekdiagrammen kunnen alleen elementen declareren define. Andere inhoud wordt eenvoudigweg genegeerd. Hierdoor kunnen gebruikers codefragmenten hergebruiken en delen die in meerdere diagrammen kunnen worden gebruikt, waardoor duplicatie wordt vermeden en het principe wordt nageleefd DRY.

Bibliotheekdiagrammen worden in de sectie gedeclareerd dependencies in bestand Chart.yaml. Het installeren en beheren ervan verschilt niet van andere kaarten.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

We zijn enthousiast over de gebruiksscenario's die dit onderdeel zal bieden voor diagramontwikkelaars, evenals over de best practices die uit bibliotheekdiagrammen kunnen voortkomen.

Wat is het volgende?

Helm 3.0.0-alpha.1 is de basis waarop we een nieuwe versie van Helm beginnen te bouwen. In het artikel beschreef ik enkele interessante kenmerken van Helm 3. Veel ervan bevinden zich nog in de beginfase van ontwikkeling en dit is normaal; Het doel van een alpha-release is om het idee te testen, feedback van vroege gebruikers te verzamelen en onze aannames te bevestigen.

Zodra de alpha-versie uitkomt (onthoud dat dit zo is al gebeurd — ca. vert.), zullen we patches voor Helm 3 gaan accepteren van de community. U moet een sterke basis creëren die het mogelijk maakt nieuwe functionaliteit te ontwikkelen en toe te passen, en ervoor te zorgen dat gebruikers zich betrokken voelen bij het proces door tickets te openen en oplossingen aan te brengen.

Ik heb geprobeerd enkele van de belangrijkste verbeteringen voor Helm 3 te benadrukken, maar deze lijst is zeker niet uitputtend. De volledige routekaart voor Helm 3 bevat functies zoals verbeterde updatestrategieën, diepere integratie met OCI-registers en het gebruik van JSON-schema's om diagramwaarden te valideren. We zijn ook van plan de codebase op te schonen en delen ervan bij te werken die de afgelopen drie jaar zijn verwaarloosd.

Als u het gevoel heeft dat we iets hebben gemist, horen we graag uw mening!

Doe mee aan de discussie op onze Slappe kanalen:

#helm-users voor vragen en eenvoudige communicatie met de community;
#helm-dev om pull-verzoeken, code en bugs te bespreken.

Je kunt ook chatten tijdens onze wekelijkse Public Developer Calls op donderdag om 19:30 MSK. Bijeenkomsten zijn gewijd aan het bespreken van kwesties waar belangrijke ontwikkelaars en de community aan werken, evenals gespreksonderwerpen voor de week. Iedereen kan deelnemen en deelnemen aan de vergadering. Link beschikbaar in Slack-kanaal #helm-dev.

Maak kennis met Helm3