🥇Kennismaking met Helm 3

Opmerking vertaler.: 16 mei van dit jaar is een belangrijke mijlpaal in de ontwikkeling van de pakketbeheerder voor Kubernetes — Helm. Op deze dag werd de eerste alfa-release van de toekomstige grote versie van het project — 3.0 gepresenteerd. De release zal aanzienlijke en langverwachte veranderingen in Helm brengen, waar velen in de Kubernetes-gemeenschap grote verwachtingen van hebben. Wijzelf behoren ook tot die groep, aangezien we Helm actief gebruiken voor de implementatie van toepassingen: we hebben het geïntegreerd in onze tool voor CI/CD. werf en op sporadische basis leveren we een bescheiden bijdrage aan de ontwikkeling van upstream. Deze vertaling bundelt 7 notities uit de officiële Helm-blog, die zijn gepresenteerd bij de eerste alfa-release van Helm 3 en vertellen over de geschiedenis van het project en de belangrijkste functies van Helm 3. De auteur is Matt «bacongobbler» Fisher, een medewerker van Microsoft en een van de sleutelonderhouders van Helm.

Op 15 oktober 2015 is het project geboren dat tegenwoordig bekend staat als Helm. Slechts een jaar na de oprichting voegde de Helm-gemeenschap zich bij Kubernetes, terwijl ze ook actief werkten aan Helm 2. In juni 2018 werd Helm onderdeel van CNCF als een ontwikkelend (incubating) project. Laten we naar het heden gaan — en al snel is de eerste alfa-release van de nieuwe Helm 3 op komst. (deze release heeft inmiddels plaatsgevonden in het midden van mei — red. vert.).

In dit artikel zal ik vertellen hoe alles begon, hoe we de huidige fase hebben bereikt, enkele unieke kenmerken presenteren die beschikbaar zijn in de eerste alfa-release van Helm 3, en uitleggen hoe we van plan zijn verder te ontwikkelen.

Samenvatting:

de geschiedenis van Helm;
een teder afscheid van Tiller;
chart-repositories;
releasebeheer;
veranderingen in chart-afhankelijkheden;
library charts;
wat nu?

De geschiedenis van Helm

Geboorte

Helm 1 begon als een Open Source-project, opgericht door Deis. We waren een kleine startup, overgenomen door Microsoft in de lente van 2017. Ons andere Open Source-project, dat ook Deis heet, had een tool deisctl, die onder andere werd gebruikt voor het installeren en exploiteren van het Deis-platform in de Fleet-cluster.Op dat moment was Fleet een van de eerste platforms voor containerorkestratie.

In het midden van 2015 besloten we van koers te veranderen en vertaalden we Deis (toen hernoemd naar Deis Workflow) van Fleet naar Kubernetes. Een van de eerste zaken die we herontworpen is de installatietool. deisctlWe hebben het gebruikt voor de installatie en het beheer van Deis Workflow in de Fleet-cluster.

Helm 1 is ontworpen naar het voorbeeld van bekende pakketbeheerders zoals Homebrew, apt en yum. De belangrijkste taak was om taken zoals het verpakken en installeren van applicaties in Kubernetes te vereenvoudigen. Officieel werd Helm in 2015 gepresenteerd op de KubeCon-conferentie in San Francisco.

Onze eerste poging met Helm werkte, maar het kwam met aanzienlijke beperkingen. Het gebruikte een set Kubernetes-manifesten, aangevuld met generators als invoer YAML-blokken. (front-matter)*, en het laadde de resultaten in Kubernetes.

* Opmerking vertaler.: Vanaf de eerste versie werd YAML syntaxis gekozen voor het beschrijven van Kubernetes-resources, en bij het schrijven van configuraties werden Jinja-sjablonen en Python-scripts ondersteund. Meer informatie hierover en over de opzet van de eerste versie van Helm in het algemeen hebben we geschreven in het hoofdstuk 'Korte Geschiedenis van Helm'. dit materiaal.

Bijvoorbeeld, om een veld in een YAML-bestand te vervangen, moest de volgende constructie in het manifest worden toegevoegd:

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

Het is geweldig dat er tegenwoordig sjabloon generators zijn, nietwaar?

Om verschillende redenen vereiste deze vroege Kubernetes-installer een rigide lijst van manifest-bestanden en voerde het slechts een kleine vaste reeks gebeurtenissen uit. Het was zo moeilijk in gebruik dat het R&D-team van Deis Workflow het zwaar had toen ze probeerden hun product naar dit platform te migreren — maar de zaadjes voor het idee waren al geplant. Onze eerste poging was een uitstekende gelegenheid om te leren: we realiseerden ons dat we echt gepassioneerd waren over het creëren van pragmatische tools die alledaagse problemen voor onze gebruikers oplossen.

Op basis van de ervaringen van eerdere fouten gingen we verder met de ontwikkeling van Helm 2.

De creatie van Helm 2

Eind 2015 nam het Google-team contact met ons op. Ze werkten aan een vergelijkbare tool voor Kubernetes. Deployment Manager voor Kubernetes was een port van een bestaand hulpmiddel dat werd gebruikt voor Google Cloud Platform. ‘Willen we niet,’ vroegen ze, ‘een paar dagen besteden aan het bespreken van overeenkomsten en verschillen?’

In januari 2016 kwamen de teams van Helm en Deployment Manager samen in Seattle om ideeën uit te wisselen. De gesprekken resulteerden in een ambitieus plan: de twee projecten samen te voegen om Helm 2 te creëren. Samen met Deis en Google voegde het team ontwikkelaars de jongens van SkippBox (nu onderdeel van Bitnami — vert.), en we begonnen met het werken aan Helm 2.

We wanted to maintain the simplicity of using Helm but add the following:

chart templates for customization;
in-cluster management for teams;
a first-class chart repository;
a stable package format with signing capabilities;
a strong commitment to semantic versioning and maintaining backward compatibility between versions.

To achieve these goals, a second element was added to the Helm ecosystem. This in-cluster component was called Tiller and was responsible for installing and managing Helm charts.

Since the release of Helm 2 in 2016, Kubernetes has undergone several significant innovations. Role-Based Access Control (RBAC) was introduced, which ultimately replaced Attribute-Based Access Control (ABAC). New resource types were introduced (Deployments were still in beta at that time). Custom Resource Definitions were invented (initially called Third Party Resources or TPRs). Most importantly, a set of best practices emerged.

Against the backdrop of all these changes, Helm continued to faithfully serve Kubernetes users. After three years and numerous new additions, it became clear that significant changes to the codebase were necessary for Helm to continue meeting the growing needs of the evolving ecosystem.

A Fond Farewell to Tiller

During the development of Helm 2, we introduced Tiller as part of our integration with Google’s Deployment Manager. Tiller played a crucial role for teams working within a shared cluster: it allowed various specialists managing the infrastructure to interact with the same set of releases.

Omdat rolgebaseerde toegang (RBAC) standaard was ingeschakeld in Kubernetes 1.6, werd het werken met Tiller in productie ingewikkelder. Vanwege het enorme aantal mogelijke beveiligingsbeleid was onze positie om standaard een permissieve configuratie aan te bieden. Dit stelde nieuwkomers in staat om te experimenteren met Helm en Kubernetes zonder zich eerst in de beveiligingsinstellingen te hoeven verdiepen. Helaas kon deze permissieve configuratie de gebruiker te veel rechten geven die niet nodig waren. DevOps- en SRE-ingenieurs moesten extra operationele stappen leren om Tiller in een multi-tenant cluster te installeren.

Door te leren hoe leden van de gemeenschap Helm in specifieke situaties gebruiken, realiseerden we ons dat de releasebeheerder Tiller niet hoefde te vertrouwen op een intraclustercomponent om staten te behouden of als centrale hub voor release-informatie te fungeren. In plaats daarvan zouden we eenvoudigweg informatie van de Kubernetes API-server kunnen ontvangen, de chart aan de klantzijde kunnen genereren en de installatie-informatie in Kubernetes kunnen opslaan.

De belangrijkste taak van Tiller kon ook zonder Tiller worden uitgevoerd, waardoor een van onze eerste beslissingen met betrekking tot Helm 3 was om Tiller volledig te laten vallen.

Met het vertrek van Tiller is het beveiligingsmodel van Helm radicaal vereenvoudigd. Helm 3 ondersteunt nu alle moderne methoden voor beveiliging, identificatie en autorisatie van de huidige Kubernetes. De rechten van Helm worden gedefinieerd met behulp van het kubeconfig-bestand. Clusterbeheerders kunnen de rechten van gebruikers op elke gewenste detaillering beperken. Releases worden nog steeds binnen het cluster bijgehouden, en de overige functionaliteit van Helm blijft behouden.

Chart-repositories

Op hoog niveau is een chart-repository een plek waar charts kunnen worden opgeslagen en gedeeld. De Helm-client verpakt en verstuurt charts naar de repository. Simpel gezegd, een chart-repository is een primitieve HTTP-server met een index.yaml-bestand en enkele verpakte charts.

Hoewel er enkele voordelen zijn aan het feit dat de API van de chart-repository voldoet aan de basisvereisten voor opslag, zijn er ook enkele nadelen:

Chart repositories zijn slecht compatibel met de meeste beveiligingsimplementaties die nodig zijn in een productieomgeving. Het hebben van een standaard API voor authenticatie en autorisatie is van cruciaal belang in productie-scenario's.
De tools van Helm voor het bijhouden van de herkomst van charts, die worden gebruikt voor ondertekening, integriteitscontrole en herkomst, zijn een optioneel onderdeel van het publicatieproces van een Chart.
In multi-user scenario's kan dezelfde chart door een andere gebruiker worden geüpload, wat de opslagruimte die nodig is voor dezelfde content, verdubbelt. Om dit probleem op te lossen, zijn er slimmere repositories ontwikkeld, maar deze maken geen deel uit van de formele specificatie.
Het gebruik van een enkele indexbestand voor het zoeken, opslaan van metadata en ophalen van charts heeft het ontwikkelen van veilige multi-user implementaties bemoeilijkt.

Project Docker Distribution (ook bekend als Docker Registry v2) is de opvolger van Docker Registry en fungeert feitelijk als een set tools voor het verpakken, verzenden, opslaan en leveren van Docker-images. Veel grote cloudservices bieden producten gebaseerd op Distribution. Dankzij deze verhoogde aandacht heeft het Distribution-project geprofiteerd van jarenlange verbeteringen, beste praktijken op het gebied van veiligheid en testen in 'live' omgevingen, waardoor het een van de meest succesvolle onbezongen helden in de wereld van Open Source is geworden.

Maar wist u dat het Distribution-project is ontwikkeld om elke vorm van content te distribueren en niet alleen container images?

Dankzij de inspanningen van Open Container Initiative (of OCI) kunnen Helm-charts worden gehost op elke instantie van Distribution. Tot nu toe is dit proces experimenteel. Het werk aan de ondersteuning van inlogfuncties en andere functies die nodig zijn voor een complete Helm 3-ervaring is nog niet afgerond, maar we zijn erg enthousiast over de mogelijkheid om te leren van de ontdekkingen die de OCI- en Distribution-teams in de loop der jaren hebben gedaan. Dankzij hun mentorschap en begeleiding leren we wat het betekent om een hoog-beschikbare service op grote schaal te exploiteren.

Een meer gedetailleerde beschrijving van enkele aankomende wijzigingen in de Helm-chart repositories is beschikbaar. via de link.

Releasebeheer

In Helm 3 wordt de status van de applicatie binnen de cluster bijgehouden door een paar objecten:

release object - vertegenwoordigt een instantie van de applicatie;
release versie geheim - vertegenwoordigt de gewenste staat van de applicatie op een specifiek moment in de tijd (bijvoorbeeld, de release van een nieuwe versie).

Aanroep helm install maakt de release object en release versie geheim aan. Aanroep helm upgrade vereist een release object (dat het kan wijzigen) en maakt een nieuw release versie geheim aan, dat nieuwe waarden en een voorbereide manifest bevat.

Release object bevat informatie over de release, waarbij de release een specifieke installatie van een benoemde chart en waarden is. Dit object beschrijft metadata op het hoogste niveau over de release. Het release object wordt gedurende de hele levenscyclus van de applicatie behouden en fungeert als eigenaar van alle release versie geheimen, evenals alle objecten die rechtstreeks door de Helm chart worden aangemaakt.

Release versie geheim koppelt de release aan een reeks revisies (installaties, upgrades, terugrol, verwijdering).

In Helm 2 waren revisies uitsluitend sequentieel. Aanroep helm install creëerde v1, de volgende upgrade - v2, enzovoort. Release en release versie geheim werden samengevoegd in een enkel object, bekend als revisie. Revisies werden opgeslagen in dezelfde namespace als Tiller, wat betekende dat elke release 'globaal' was qua namespace; als gevolg hiervan kon slechts één instantie van de naam worden gebruikt.

In Helm 3 is elke release gekoppeld aan een of meerdere release versie geheimen. Het release object beschrijft altijd de huidige release die is uitgerold in Kubernetes. Elke release versie geheim beschrijft slechts één versie van deze release. Een upgrade bijvoorbeeld, creëert een nieuwe release versie geheim en wijzigt vervolgens het release object zodat het naar deze nieuwe versie verwijst. In het geval van een terugrol kunnen eerdere release versie geheimen worden gebruikt om de release naar de vorige staat terug te brengen.

Na de afschaffing van Tiller slaat Helm 3 releasegegevens op in dezelfde namespace als de release. Deze wijziging maakt het mogelijk om een chart met dezelfde naam in een andere namespace te installeren, en de gegevens worden behouden tussen updates/herstarts van de cluster in etcd. Bijvoorbeeld, je kunt WordPress installeren in de namespace 'foo', en vervolgens in de namespace 'bar', en beide releases kunnen 'wordpress' heten.

Wijzigingen in de afhankelijkheden van charts

Charts, verpakt (met behulp van helm package) voor gebruik met Helm 2 kan worden geïnstalleerd met Helm 3. Het ontwikkelingsproces van charts is echter volledig herzien, dus moeten er enkele wijzigingen worden aangebracht om door te gaan met het ontwikkelen van charts met Helm 3. In het bijzonder is het systeem voor afhankelijkheidsbeheer van charts veranderd.

Het afhankelijkheidsbeheersysteem van de chart is overgeschakeld van requirements.yaml en requirements.lock en een werkende opdracht krijgen. Chart.yaml en Chart.lock. Dit betekent dat charts die het commando helm dependency, enige configuratie vereisen om in Helm 3 te werken.

Laten we een voorbeeld bekijken. Laten we een afhankelijkheid toevoegen aan een chart in Helm 2 en zien wat er verandert bij de overstap naar Helm 3.

In Helm 2 requirements.yaml zag er als volgt 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 weergegeven in uw Chart.yaml:

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

Charts worden nog steeds gedownload en geplaatst in de directory charts/, dus subcharts (subcharts), bevinden zich in de map charts/, blijven ongewijzigd werken.

Introductie van Library Charts

Helm 3 ondersteunt een klasse charts genoemd library charts (library chart). Deze chart wordt door andere charts gebruikt, maar genereert zelf geen release-artifacten. De sjablonen van library charts kunnen alleen elementen define. Andere inhoud wordt eenvoudigweg genegeerd. Dit stelt gebruikers in staat om codefragmenten opnieuw te gebruiken en uit te wisselen, die in veel charts kunnen worden gebruikt, en voorkomt duplicatie terwijl het principe van DRY.

wordt nageleefd. Library charts worden gedeclareerd in de sectie dependencies in het bestand Chart.yaml. De installatie en het beheer zijn niet anders dan bij andere charts.

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

We kijken ernaar uit welke gebruiksmogelijkheden deze component biedt voor chart-ontwikkelaars, evenals de beste praktijken die kunnen ontstaan door library charts.

Wat nu?

Helm 3.0.0-alpha.1 is de basis waar we op voortbouwen om een nieuwe versie van Helm te creëren. In het artikel beschrijf ik enkele interessante mogelijkheden van Helm 3. Veel daarvan bevinden zich nog in een vroeg stadium van ontwikkeling en dat is normaal; het doel van een alpha-release is om het idee te testen, feedback van de eerste gebruikers te verzamelen en onze veronderstellingen te bevestigen.

Zodra de alpha-versie is uitgebracht (ter herinnering, dat is al gebeurd – opmerking vert.), we zullen beginnen met het aannemen van patches voor Helm 3 van de gemeenschap. Het is belangrijk om een solide basis te creëren waarmee nieuwe functionaliteiten kunnen worden ontwikkeld en geaccepteerd, terwijl gebruikers betrokken kunnen raken in het proces door tickets te openen en correcties aan te brengen.

In dit artikel heb ik geprobeerd enkele belangrijke verbeteringen te belichten die in Helm 3 zullen verschijnen, maar deze lijst kan in geen geval als uitputtend worden beschouwd. Het uitgebreide plan voor Helm 3 omvat innovaties zoals verbeterde update-strategieën, diepere integratie met OCI-registers en het gebruik van JSON-schema's voor het valideren van chart-waarden. We zijn ook van plan om de codebasis op te schonen en delen bij te werken die de afgelopen drie jaar verwaarloosd zijn.

Als je denkt dat we iets gemist hebben, horen we graag je gedachten!

Doe mee aan de discussie in onze Slack-kanalen:

#helm-users voor vragen en eenvoudig contact met de gemeenschap;
#helm-dev voor het bespreken van pull requests, code en bugs.

Je kunt ook deelnemen aan onze wekelijkse Public Developer Calls op donderdag om 19:30 MSK. De vergaderingen zijn gewijd aan het bespreken van taken waaraan belangrijke ontwikkelaars en de gemeenschap werken, evenals de thema's die deze week aan bod komen. Iedereen is welkom om deel te nemen en zich bij de vergadering aan te sluiten. De link is beschikbaar in het Slack-kanaal #helm-dev.