Na we presenteren zijn oudere broer - . Dit is een Open Source-project dat wordt gebruikt om systeemcomponenten in een Kubernetes-cluster te installeren, deze kunnen add-ons worden genoemd.
Waarom überhaupt toevoegingen?
Het is geen geheim dat Kubernetes geen kant-en-klaar alles-in-één product is, en om een ‘volwassen’ cluster te bouwen heb je verschillende toevoegingen nodig. Addon-operator helpt u bij het installeren, configureren en up-to-date houden van deze add-ons.
De behoefte aan extra componenten in het cluster wordt beschreven in Collega's . Kortom, de situatie met Kubernetes op dit moment is zodanig dat je voor een eenvoudige ‘play around’-installatie uit de voeten kunt met de componenten out-of-the-box, voor ontwikkelaars en testen kun je Ingress toevoegen, maar voor een volledige installatie, waarover je kunt zeggen “je productie is klaar”, je moet toevoegen met een tiental verschillende add-ons: iets voor monitoring, iets voor loggen, vergeet ingress en cert-manager niet, selecteer groepen knooppunten, voeg netwerkbeleid toe, seizoen met sysctl- en pod autoscaler-instellingen...
Wat zijn de specifieke kenmerken van het werken met hen?
Zoals de praktijk laat zien, beperkt de zaak zich niet tot één installatie. Om comfortabel met het cluster te kunnen werken, moeten add-ons worden bijgewerkt en uitgeschakeld (verwijderd uit het cluster), en u zult er enkele willen testen voordat u ze in het productiecluster installeert.
Dus misschien is Ansible hier genoeg? Misschien. Maar Over het algemeen leven volwaardige add-ons niet zonder instellingen. Deze instellingen kunnen verschillen afhankelijk van de clustervariant (aws, gce, azure, bare-metal, do, ...). Sommige instellingen kunnen niet vooraf worden opgegeven; ze moeten worden verkregen van het cluster. En het cluster is niet statisch: voor sommige instellingen zul je veranderingen in de gaten moeten houden. En hier ontbreekt Ansible al: je hebt een programma nodig dat in een cluster leeft, d.w.z. Kubernetes-operator.
Degenen die het op het werk hebben geprobeerd , zullen ze zeggen dat de taken van het installeren en bijwerken van add-ons en monitoringinstellingen volledig kunnen worden opgelost met behulp van voor shell-operator. U kunt een script schrijven dat een voorwaardelijke actie uitvoert kubectl apply en controleer bijvoorbeeld ConfigMap, waar de instellingen worden opgeslagen. Dit is ongeveer wat er in addon-operator is geïmplementeerd.
Hoe is dit georganiseerd in addon-operator?
Bij het creëren van een nieuwe oplossing zijn we uitgegaan van de volgende uitgangspunten:
- Het add-on-installatieprogramma moet ondersteuning bieden sjablonen en declaratieve configuratie. We maken geen magische scripts die add-ons installeren. Addon-operator gebruikt Helm om add-ons te installeren. Om te installeren, moet u een diagram maken en de waarden selecteren die voor de configuratie worden gebruikt.
- Instellingen kunnen zijn genereren bij installatie, ze kunnen zijn krijgen van clusterOf ontvang updates, het bewaken van clusterbronnen. Deze bewerkingen kunnen worden geïmplementeerd met behulp van hooks.
- Instellingen kunnen zijn in een cluster opslaan. Om instellingen in het cluster op te slaan, wordt een ConfigMap/addon-operator aangemaakt en de Addon-operator monitort wijzigingen in deze ConfigMap. Addon-operator geeft hooks toegang tot instellingen met behulp van eenvoudige conventies.
- Toevoeging is afhankelijk van instellingen. Als de instellingen zijn gewijzigd, rolt de Addon-operator het Helm-diagram uit met nieuwe waarden. We hebben de combinatie van het Helm-diagram, de waarden ervoor en de hooks van een module genoemd (zie hieronder voor meer details).
- Staging. Er zijn geen magische releasescripts. Het updatemechanisme is vergelijkbaar met dat van een gewone applicatie: verzamel add-ons en add-on-operators in een afbeelding, tag ze en rol ze uit.
- Resultaatcontrole. Addon-operator kan statistieken voor Prometheus leveren.
Wat is opvulling in de add-on-operator?
Een toevoeging kan worden beschouwd als alles dat nieuwe functies aan het cluster toevoegt. Het installeren van Ingress is bijvoorbeeld een goed voorbeeld van een add-on. Dit kan elke operator of controller zijn met een eigen CRD: prometheus-operator, cert-manager, kube-controller-manager, enz. Of iets kleins, maar gemakkelijker te gebruiken, bijvoorbeeld een geheime kopieermachine, die registergeheimen naar nieuwe naamruimten kopieert, of sysctl-tuner, die sysctl-parameters op nieuwe knooppunten configureert.
Om add-ons te implementeren, biedt Addon-operator verschillende concepten:
- Helmdiagram gebruikt om verschillende software in het cluster te installeren, bijvoorbeeld Prometheus, Grafana, nginx-ingress. Als het vereiste onderdeel een Helm-diagram heeft, zal het installeren ervan met behulp van de Addon-operator heel eenvoudig zijn.
- Waardenopslag. Helmdiagrammen hebben meestal veel verschillende instellingen die in de loop van de tijd kunnen veranderen. Addon-operator ondersteunt het opslaan van deze instellingen en kan hun wijzigingen controleren om het Helm-diagram opnieuw te installeren met nieuwe waarden.
- Haken zijn uitvoerbare bestanden die de Addon-operator op gebeurtenissen uitvoert en die toegang hebben tot de waardenopslag. De hook kan veranderingen in het cluster monitoren en de waarden in het waardenarchief bijwerken. Die. Met behulp van hooks kunt u ontdekkingen doen om waarden uit het cluster te verzamelen bij het opstarten of volgens een schema, of u kunt continue ontdekkingen doen, waarbij waarden uit het cluster worden verzameld op basis van veranderingen in het cluster.
- Module is een combinatie van een Helm-diagram, een waardenopslag en hooks. Modules kunnen worden in- of uitgeschakeld. Als u een module uitschakelt, worden alle Helm-kaartreleases verwijderd. Modules kunnen zichzelf dynamisch inschakelen, bijvoorbeeld als alle benodigde modules zijn ingeschakeld of als Discovery de benodigde parameters in de hooks heeft gevonden - dit gebeurt met behulp van een aanvullend ingeschakeld script.
- Mondiale haken. Dit zijn hooks “op zichzelf”, ze zijn niet opgenomen in modules en hebben toegang tot een globale waardenopslag, waarvan de waarden beschikbaar zijn voor alle hooks in modules.
Hoe werken deze onderdelen samen? Laten we naar de afbeelding uit de documentatie kijken:
Er zijn twee werkscenario's:
- De global hook wordt geactiveerd door een gebeurtenis, bijvoorbeeld wanneer een bron in het cluster verandert. Deze hook verwerkt de wijzigingen en schrijft de nieuwe waarden naar het globale waardenarchief. Addon-operator merkt dat de globale opslag is veranderd en start alle modules. Elke module bepaalt met behulp van zijn hooks of deze moet worden ingeschakeld en werkt zijn waardenopslag bij. Als de module is ingeschakeld, start de Addon-operator de installatie van het Helm-diagram. In dit geval heeft het Helm-diagram toegang tot waarden uit de moduleopslag en uit de globale opslag.
- Het tweede scenario is eenvoudiger: een modulehook wordt geactiveerd door een gebeurtenis en verandert waarden in het waardenarchief van de module. Addon-operator merkt dit op en start het Helm-diagram met bijgewerkte waarden.
De toevoeging kan worden geïmplementeerd als één enkele hook, of als één Helm-diagram, of zelfs als verschillende afhankelijke modules - dit hangt af van de complexiteit van de component die in het cluster wordt geïnstalleerd en van het gewenste niveau van configuratieflexibiliteit. In de repository () is er een sysctl-tuner add-on, die zowel als een eenvoudige module met een hook en een Helm-diagram is geïmplementeerd, als met behulp van de waardenopslag, die het mogelijk maakt om instellingen toe te voegen door ConfigMap te bewerken.
Levering van updates
Een paar woorden over het organiseren van componentupdates die Addon-operator installeert.
Om Addon-operator in een cluster uit te voeren, hebt u nodig bouw een afbeelding met toevoegingen Voeg een binair bestand toe in de vorm van hook- en Helm-diagrambestanden addon-operator en alles wat je nodig hebt voor haken: bash, kubectl, jq, python enz. Vervolgens kan deze image als een reguliere applicatie naar het cluster worden uitgerold, en hoogstwaarschijnlijk wilt u een of ander tagging-schema organiseren. Als er weinig clusters zijn, kan dezelfde aanpak als bij applicaties geschikt zijn: nieuwe release, nieuwe versie, ga naar alle clusters en corrigeer het imago van de Pods. In het geval van een uitrol naar een aanzienlijk aantal clusters was het concept van zelfupdaten vanaf een kanaal echter geschikter voor ons.
Hier is hoe we het doen:
- Een kanaal is in wezen een identificatie die op alles kan worden ingesteld (bijvoorbeeld dev/stage/ea/stable).
- De kanaalnaam is de afbeeldingstag. Wanneer u updates voor een kanaal moet uitrollen, wordt er een nieuwe afbeelding samengesteld en getagd met de kanaalnaam.
- Wanneer een nieuwe afbeelding in het register verschijnt, wordt de Addon-operator opnieuw opgestart en gestart met de nieuwe afbeelding.
Dit is geen best practice, zoals geschreven in . Het wordt niet aanbevolen om dit te doen, maar we hebben het erover een reguliere applicatie die in hetzelfde cluster leeft. In het geval van Addon-operator bestaat een applicatie uit veel implementaties verspreid over clusters, en zelf-updaten helpt veel en maakt het leven gemakkelijker.
Kanalen helpen en bij het testen: als er een hulpcluster is, kunt u deze configureren voor het kanaal stage en rol er updates in voordat het naar kanalen wordt uitgerold ea и stable. Indien met een cluster op het kanaal ea er is een fout opgetreden, u kunt hiernaar overschakelen stable, terwijl het probleem met dit cluster wordt onderzocht. Als het cluster uit de actieve ondersteuning wordt gehaald, schakelt het over naar het "bevroren" kanaal, bijvoorbeeld freeze-2019-03-20.
Naast het bijwerken van hooks en Helm-grafieken heeft u mogelijk ook nodig update en component van derden. U hebt bijvoorbeeld een bug opgemerkt in de voorwaardelijke knooppuntexporter en u heeft zelfs ontdekt hoe u deze kunt patchen. Vervolgens hebt u de PR geopend en wacht u tot de nieuwe release alle clusters doorloopt en de versie van de afbeelding vergroot. Om niet voor onbepaalde tijd te wachten, kunt u uw node-exporteur bouwen en ernaar overschakelen voordat u de PR accepteert.
Over het algemeen kan dit gedaan worden zonder Addon-operator, maar met Addon-operator zal de module voor het installeren van node-exporter zichtbaar zijn in één repository, het Dockerbestand voor het bouwen van uw image kan daar bewaard worden, het wordt gemakkelijker voor alle deelnemers aan het proces om te begrijpen wat er gebeurt... En als er meerdere clusters zijn, wordt het eenvoudiger om zowel je PR te testen als een nieuwe versie uit te rollen!
Deze organisatie van het updaten van componenten werkt voor ons succesvol, maar elk ander geschikt schema kan immers worden geïmplementeerd in dit geval is de Addon-operator een eenvoudig binair bestand.
Conclusie
Met de principes die in Addon-operator zijn geïmplementeerd, kunt u een transparant proces bouwen voor het maken, testen, installeren en updaten van add-ons in een cluster, vergelijkbaar met de ontwikkelingsprocessen van reguliere applicaties.
Add-ons voor Addon-operator in moduleformaat (roerkaart + haken) kunnen openbaar beschikbaar worden gemaakt. Wij, het bedrijf Flant, zijn van plan onze ontwikkelingen in de vorm van dergelijke aanvullingen tijdens de zomer te publiceren. Sluit je aan bij de ontwikkeling op GitHub (, ), probeer op basis daarvan je eigen toevoeging te maken и , wacht op nieuws over Habré en op onze !
PS
Lees ook op onze blog:
- «";
- «.
Bron: www.habr.com