🥇Het Helm-apparaat en zijn valkuilen

Typhon vrachtvervoerconcept, Anton Swanepoel

Mijn naam is Dmitry Sugrobov, ik ben een ontwikkelaar bij Leroy Merlin. In dit artikel vertel ik je waarom Helm nodig is, hoe het het werken met Kubernetes vereenvoudigt, wat er veranderd is in de derde versie en hoe je het kunt gebruiken om applicaties in productie te updaten zonder downtime.

Dit is een samenvatting gebaseerd op een toespraak op een conferentie @Kubernetes-conferentie by Mail.ru Cloud-oplossingen – als je niet wilt lezen, bekijk dan de video.

Waarom we Kubernetes gebruiken in de productie

Leroy Merlin is een leider op de doe-het-zelf-retailmarkt in Rusland en Europa. Ons bedrijf heeft ruim honderd ontwikkelaars, 33 interne medewerkers en een groot aantal mensen die hypermarkten en de website bezoeken. Om ze allemaal blij te maken, hebben we besloten de standaardbenaderingen in de industrie te volgen. Ontwikkel nieuwe applicaties met behulp van microservice-architectuur; gebruik containers om omgevingen te isoleren en een goede levering te garanderen; en gebruik Kubernetes voor orkestratie. De prijs voor het gebruik van orkestrators wordt snel goedkoper: het aantal technici die bekwaam zijn in de technologie groeit op de markt en er verschijnen aanbieders die Kubernetes als een dienst aanbieden.

Alles wat Kubernetes doet kan natuurlijk ook op andere manieren, bijvoorbeeld door sommige Jenkins en docker-compose te bedekken met scripts, maar waarom het leven ingewikkeld maken als er een kant-en-klare en betrouwbare oplossing is? Daarom zijn we bij Kubernetes uitgekomen en gebruiken het nu een jaar in productie. We hebben momenteel vierentwintig Kubernetes-clusters, waarvan de oudste meer dan een jaar oud is, met ongeveer tweehonderd pods.

De vloek van grote YAML-bestanden in Kubernetes

Om een microservice in Kubernetes te lanceren, zullen we minimaal vijf YAML-bestanden maken: voor Deployment, Service, Ingress, ConfigMap, Secrets - en deze naar het cluster sturen. Voor de volgende toepassing zullen we hetzelfde pakket met stijlen schrijven, voor de derde zullen we er nog een schrijven, enzovoort. Als we het aantal documenten vermenigvuldigen met het aantal omgevingen, krijgen we al honderden bestanden, en dan houden we nog geen rekening met dynamische omgevingen.

Adam Reese, hoofdonderhouder van Helm, introduceerde het concept van "Ontwikkelingscyclus in Kubernetes", die er als volgt uitziet:

YAML kopiëren - kopieer een YAML-bestand.
Plak YAML - plak het.
Inspringingen repareren - inspringingen repareren.
Herhaal - herhaal opnieuw.

De optie werkt, maar je moet de YAML-bestanden vele malen kopiëren. Om deze cyclus te veranderen werd Helm uitgevonden.

Wat is Helm

Ten eerste, Helm- pakket manager, waarmee u de programma's die u nodig hebt, kunt vinden en installeren. Om bijvoorbeeld MongoDB te installeren, hoeft u niet naar de officiële website te gaan en binaire bestanden te downloaden, voer gewoon de opdracht uit helm install stable/mongodb.

Ten tweede, Helm - sjabloon-engine, helpt bij het parametriseren van bestanden. Laten we terugkeren naar de situatie met YAML-bestanden in Kubernetes. Het is gemakkelijker om hetzelfde YAML-bestand te schrijven en er enkele tijdelijke aanduidingen aan toe te voegen, waarin Helm de waarden zal vervangen. Dat wil zeggen dat er in plaats van een groot aantal steigers een reeks sjablonen zal zijn waarin de vereiste waarden op het juiste moment zullen worden vervangen.

Ten derde, Helm - implementatie meester. Hiermee kunt u applicaties installeren, terugdraaien en updaten. Laten we uitzoeken hoe we dit kunnen doen.

Helm gebruiken om uw eigen applicaties te implementeren

Laten we de Helm-client op uw computer installeren, volgens de ambtenaar instructies. Vervolgens maken we een set YAML-bestanden. In plaats van specifieke waarden op te geven, laten we tijdelijke aanduidingen achter, die Helm in de toekomst met informatie zal vullen. Een set van dergelijke bestanden wordt een Helm-diagram genoemd. Het kan op drie manieren naar de Helm-consoleclient worden verzonden:

geef een map met sjablonen aan;
pak het archief in een .tar en wijs ernaar;
plaats de sjabloon in een externe repository en voeg een link toe naar de repository in de Helm-client.

Je hebt ook een bestand met waarden nodig: waarden.yaml. De gegevens van daaruit worden in de sjabloon ingevoegd. Laten we het ook creëren.

De tweede versie van Helm heeft een extra serverapplicatie: Tiller. Het hangt buiten Kubernetes en wacht op verzoeken van de Helm-client, en wanneer het wordt aangeroepen, vervangt het de vereiste waarden in de sjabloon en stuurt deze naar Kubernetes.

Helm 3 is eenvoudiger: in plaats van sjablonen op de server te verwerken, wordt informatie nu volledig aan de Helm-clientzijde verwerkt en rechtstreeks naar de Kubernetes API gestuurd. Deze vereenvoudiging verbetert de clusterbeveiliging en vergemakkelijkt het uitrolschema.

Hoe werkt het allemaal

Voer de opdracht uit helm install. Laten we de naam van de applicatierelease aangeven en het pad naar waarden.yaml geven. Aan het einde zullen we de repository aangeven waarin de grafiek zich bevindt en de naam van de grafiek. In het voorbeeld zijn dit respectievelijk “lmru” en “bestchart”.

helm install --name bestapp --values values.yaml lmru/bestchart

De opdracht kan slechts één keer worden uitgevoerd, maar kan in plaats daarvan opnieuw worden uitgevoerd install moet gebruiken upgrade. Voor de eenvoud kunt u in plaats van twee opdrachten de opdracht uitvoeren upgrade met extra sleutel --install. Wanneer Helm voor de eerste keer wordt uitgevoerd, verzendt hij een opdracht om de release te installeren en zal deze in de toekomst bijwerken.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Valkuilen bij het implementeren van nieuwe versies van een applicatie met Helm

Op dit punt in het verhaal speel ik Who Wants to Be a Millionaire met het publiek, en we zoeken uit hoe we Helm zover kunnen krijgen dat hij de versie van de app bijwerkt. Bekijk de video.

Toen ik leerde hoe Helm werkt, werd ik verrast door vreemd gedrag bij het bijwerken van versies van actieve applicaties. Ik heb de applicatiecode bijgewerkt, een nieuwe afbeelding naar het Docker-register geüpload, de implementatieopdracht verzonden - en er gebeurde niets. Hieronder staan enkele niet geheel succesvolle manieren om applicaties bij te werken. Door ze allemaal in meer detail te bestuderen, begin je de interne structuur van het instrument te begrijpen en de redenen voor dit niet voor de hand liggende gedrag.

Methode 1. Wijzig geen informatie sinds de laatste lancering

Zoals het zegt officiële website Helm: “Kubernetes-diagrammen kunnen groot en complex zijn, dus Helm probeert nergens te veel aan te raken.” Als u daarom de nieuwste versie van de toepassingsimage in het docker-register bijwerkt en de opdracht uitvoert helm upgrade, dan gebeurt er niets. Helm zal denken dat er niets is veranderd en dat er geen opdracht naar Kubernetes hoeft te worden gestuurd om de applicatie bij te werken.

Hier en hieronder wordt de nieuwste tag uitsluitend als voorbeeld weergegeven. Wanneer u deze tag opgeeft, downloadt Kubernetes de installatiekopie elke keer uit het docker-register, ongeacht de parameter imagePullPolicy. Het gebruik van de nieuwste productiemethoden is ongewenst en veroorzaakt bijwerkingen.

Methode 2. LABEL in afbeelding bijwerken

Zoals in hetzelfde geschreven documentatie, “Helm zal een applicatie alleen updaten als deze sinds de laatste release is gewijzigd.” Een logische optie hiervoor lijkt het bijwerken van het LABEL in de docker-image zelf. Helm kijkt echter niet naar de applicatie-images en heeft geen idee van eventuele wijzigingen daarin. Dienovereenkomstig zal Helm bij het bijwerken van labels in de afbeelding er niets van weten en wordt de opdracht voor het bijwerken van de applicatie niet naar Kubernetes verzonden.

Methode 3: Gebruik een sleutel --force

Laten we de handleidingen raadplegen en de vereiste sleutel zoeken. De sleutel is het meest logisch --force. Ondanks de voor de hand liggende naam is het gedrag anders dan verwacht. In plaats van een applicatie-update af te dwingen, is het echte doel ervan een release te herstellen die de status FAILED heeft. Als u deze toets niet gebruikt, moet u de opdrachten opeenvolgend uitvoeren helm delete && helm install --replace. Er wordt voorgesteld om in plaats daarvan de sleutel te gebruiken --force, wat de opeenvolgende uitvoering van deze opdrachten automatiseert. Meer informatie hierin trek verzoek. Om Helm te vertellen de applicatieversie bij te werken, zal deze sleutel helaas niet werken.

Methode 4. Wijzig labels rechtstreeks in Kubernetes

Label rechtstreeks in het cluster bijwerken met behulp van de opdracht kubectl edit - slecht idee. Deze actie zal leiden tot inconsistentie van informatie tussen de actieve applicatie en de applicatie die oorspronkelijk voor implementatie was verzonden. Het gedrag van Helm tijdens de implementatie verschilt in dit geval van de versie: Helm 2 zal niets doen en Helm 3 zal de nieuwe versie van de applicatie implementeren. Om te begrijpen waarom, moet je begrijpen hoe Helm werkt.

Hoe werkt Helm?

Om te bepalen of een applicatie is gewijzigd sinds de laatste release, kan Helm het volgende gebruiken:

applicatie draaien in Kubernetes;
nieuwe waarden.yaml en huidige grafiek;
Helm's interne vrijgave-informatie.

Voor de meer nieuwsgierigen: waar bewaart Helm interne informatie over releases?Door het commando uit te voeren helm history, krijgen we alle informatie over de versies die met Helm zijn geïnstalleerd.

Er is ook gedetailleerde informatie over de verzonden sjablonen en waarden. Wij kunnen het aanvragen:

In de tweede versie van Helm bevindt deze informatie zich in dezelfde naamruimte waar Tiller draait (standaard kube-systeem), in de ConfigMap, gemarkeerd met het label “OWNER=TILLER”:

Toen de derde versie van Helm verscheen, werd de informatie verplaatst naar geheimen en naar dezelfde naamruimte waar de applicatie draaide. Hierdoor werd het mogelijk om meerdere applicaties tegelijkertijd in verschillende naamruimten met dezelfde releasenaam te draaien. In de tweede versie was het een serieuze hoofdpijn als naamruimten geïsoleerd zijn maar elkaar kunnen beïnvloeden.

De tweede Helm gebruikt, wanneer hij probeert te begrijpen of een update nodig is, slechts twee informatiebronnen: wat er nu aan wordt verstrekt, en interne informatie over releases, die in de ConfigMap ligt.

De derde Helm maakt gebruik van een drievoudige merge-strategie: naast die informatie wordt ook rekening gehouden met de applicatie die op dit moment in Kubernetes draait.

Om deze reden zal de oude versie van Helm niets doen, omdat deze geen rekening houdt met de applicatie-informatie in het cluster, maar Helm 3 zal de wijzigingen ontvangen en de nieuwe applicatie verzenden voor implementatie.

Methode 5. Gebruik de schakelaar --recreate-pods

Met een sleutel --recreate-pods Met de sleutel kunt u bereiken wat u oorspronkelijk van plan was --force. De containers zullen opnieuw opstarten en, volgens het imagePullPolicy: Always-beleid voor de nieuwste tag (meer hierover in de voetnoot hierboven), zal Kubernetes een nieuwe versie van de image downloaden en lanceren. Dit zal niet op de beste manier gebeuren: zonder rekening te houden met het Strategietype van de implementatie, zullen alle oude applicatie-instances abrupt worden uitgeschakeld en nieuwe worden gelanceerd. Tijdens het opnieuw opstarten zal het systeem niet werken, gebruikers zullen er last van hebben.

Bij Kubernetes zelf bestond een soortgelijk probleem ook al langere tijd. En nu, 4 jaar na de opening Uitgifte, is het probleem opgelost en vanaf versie 1.15 van Kubernetes verschijnt de mogelijkheid om pods opnieuw te starten.

Helm schakelt eenvoudig alle applicaties uit en lanceert nieuwe containers in de buurt. U kunt dit niet in productie doen, om geen downtime van de applicatie te veroorzaken. Dit is alleen nodig voor ontwikkelingsbehoeften en kan alleen worden uitgevoerd in podiumomgevingen.

Hoe kan ik de applicatieversie bijwerken met Helm?

We zullen de waarden wijzigen die naar Helm zijn verzonden. Meestal zijn dit waarden die worden vervangen in plaats van de afbeeldingstag. In het geval van nieuwste, dat vaak wordt gebruikt voor onproductieve omgevingen, is de veranderlijke informatie een annotatie, die nutteloos is voor Kubernetes zelf, en voor Helm zal het fungeren als signaal voor de noodzaak om de applicatie bij te werken. Opties voor het invullen van de annotatiewaarde:

Willekeurige waarde met behulp van de standaardfunctie - {{ randAlphaNum 6 }}.
Er is een voorbehoud: na elke implementatie waarbij een diagram met een dergelijke variabele wordt gebruikt, zal de annotatiewaarde uniek zijn en gaat Helm ervan uit dat er veranderingen zijn. Het blijkt dat we de applicatie altijd opnieuw zullen opstarten, zelfs als we de versie niet hebben gewijzigd. Dit is niet kritisch, aangezien er geen downtime zal zijn, maar het is nog steeds onaangenaam.
Plak huidige datum en tijd - {{ .Release.Date }}.
Een variant is vergelijkbaar met een willekeurige waarde met een permanent unieke variabele.
Een correctere manier is om te gebruiken controlesommen. Dit is de SHA van de afbeelding of de SHA van de laatste commit in de git - {{ .Values.sha }}.
Ze moeten worden geteld en naar de Helm-client aan de bellende kant worden verzonden, bijvoorbeeld in Jenkins. Als de toepassing is gewijzigd, verandert de controlesom. Daarom zal Helm de applicatie alleen bijwerken wanneer dat nodig is.

Laten we onze pogingen samenvatten

Helm brengt wijzigingen op de minst invasieve manier aan, dus elke wijziging op het niveau van de applicatie-image in het Docker-register zal niet resulteren in een update: er gebeurt niets nadat de opdracht is uitgevoerd.
sleutel --force gebruikt om problematische releases te herstellen en wordt niet geassocieerd met gedwongen updates.
sleutel --recreate-pods zal applicaties met kracht updaten, maar zal het op een vandalistische manier doen: het zal abrupt alle containers uitschakelen. Gebruikers zullen hier last van hebben; dit moet je niet in productie doen.
Breng rechtstreeks wijzigingen aan in het Kubernetes-cluster met behulp van de opdracht kubectl edit niet doen: we zullen de consistentie doorbreken en het gedrag zal verschillen afhankelijk van de versie van Helm.
Met de release van de nieuwe versie van Helm zijn er veel nuances verschenen. Problemen in de Helm-repository worden in duidelijke taal beschreven, zodat u de details beter kunt begrijpen.
Door een bewerkbare annotatie aan een diagram toe te voegen, wordt het flexibeler. Hierdoor kunt u de applicatie correct uitrollen, zonder downtime.

Een ‘wereldvrede’-gedachte die op alle gebieden van het leven werkt: lees de instructies vóór gebruik, niet erna. Alleen met volledige informatie is het mogelijk betrouwbare systemen te bouwen en gebruikers blij te maken.

Andere gerelateerde links:

Dit rapport werd voor het eerst gepresenteerd op @Kubernetes-conferentie door Mail.ru Cloud Solutions. Kijk video andere optredens en abonneer je op evenementaankondigingen op Telegram Rond Kubernetes bij Mail.ru Group.

Bron: www.habr.com

Het Helm-apparaat en zijn valkuilen