Na We stellen zijn oudere broer voor — . Dit is een Open Source-project dat wordt gebruikt voor de installatie in een Kubernetes-cluster van systeemcomponenten, die samen onder de algemene term — aanvullingen — kunnen worden genoemd.
Waarom zouden we überhaupt aanvullingen nodig hebben?
Het is geen geheim dat Kubernetes geen kant-en-klaar product is; voor het opbouwen van een 'volwassen' cluster zijn verschillende aanvullingen nodig. De addon-operator helpt bij het installeren, configureren en onderhouden van deze aanvullingen in de actuele staat.
De noodzaak van extra componenten in het cluster wordt onthuld in collega's . Kortom, de situatie met Kubernetes is op dit moment zodanig dat je voor een eenvoudige installatie om te 'spelen' kunt volstaan met de componenten uit de doos, voor ontwikkelaars en testen kun je Ingress toevoegen, maar voor een volledige installatie die je 'je productie is klaar' kunt noemen, is het nodig om een tiental verschillende aanvullingen toe te voegen: iets voor monitoring, iets voor logs, vergeet de ingress en cert-manager niet, wijs knooppuntgroepen toe, stel netwerkbeleid in, en voeg instellingen voor sysctl en pod autoscaler toe...
Wat is de specificiteit van het werken met hen?
Zoals de praktijk aantoont, beperkt het zich niet tot alleen installatie. Voor comfortabel werken met het cluster moeten aanvullingen worden bijgewerkt, uitgeschakeld (uit het cluster verwijderd), en sommige willen we testen voordat ze in het productiecluster worden geïnstalleerd.
Dus, is Ansible hier misschien voldoende? Misschien. Maar volledige aanvullingen leven in het algemeen niet zonder instellingen. Deze instellingen kunnen verschillen, afhankelijk van de clusteroptie (aws, gce, azure, bare-metal, do, ...). Sommige instellingen kunnen niet van tevoren worden opgegeven — ze moeten uit het cluster worden verkregen. En het cluster is niet statisch: voor sommige instellingen moet je de veranderingen in de gaten houden. En hier is Ansible al niet genoeg: je hebt een programma nodig dat in het cluster leeft, dat is, een Kubernetes Operator.
Degenen die het in de praktijk hebben geprobeerd , zullen zeggen dat de taken van installatie en update van aanvullingen en het toezicht houden op instellingen heel goed kunnen worden opgelost met behulp van voor de shell-operator. Je kunt een script schrijven dat een voorwaardelijke kubectl apply maakt en bijvoorbeeld de ConfigMap in de gaten houdt, waar de instellingen worden bewaard. Dit is ongeveer wat is gerealiseerd in de addon-operator.
Hoe is het georganiseerd in de addon-operator?
Bij het creëren van een nieuwe oplossing zijn we uitgegaan van de volgende principes:
- De installateur van aanvullingen moet ondersteuning bieden voor templating en declaratieve configuratieWe don't create magical scripts that install addons. The addon operator uses Helm to install addons. To install, you need to create a chart and define the values that will be used for configuration.
- Settings can be generated during installation, they can be obtained from the cluster, ofwel receive updates, by monitoring the cluster resources. These operations can be implemented using hooks.
- Settings can store in the cluster. To store settings in the cluster, a ConfigMap/addon-operator is created and the addon-operator monitors changes to this ConfigMap. The addon-operator gives hooks access to the settings through simple agreements.
- The addon depends on the settings. If the settings change, the addon-operator rolls out a Helm chart with new values. The combination of the Helm chart, values for it, and hooks is referred to as a module (see below for more details).
- Staging. There are no magical release scripts. The update mechanism is similar to that of a regular application — collect addons and the addon-operator into an image, tag it, and release it.
- Result control. The addon-operator can provide metrics for Prometheus.
What is an addon in the addon-operator?
An addon can be anything that adds new functionality to the cluster. For example, setting up Ingress is a great example of an addon. It could be any operator or controller with its own CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. Or something small, but simplifying operation — for instance, a secret copier that copies registry secrets to new namespaces, or a sysctl tuner that configures sysctl parameters on new nodes.
To implement addons, the addon-operator provides several concepts:
- Helm chart is used to install various software in the cluster — for instance, Prometheus, Grafana, nginx-ingress. If the required component has a Helm chart, installing it using the addon-operator will be very simple.
- Value storage. Helm charts usually have many different settings that may change over time. The addon-operator supports storing these settings and can monitor changes to reinstall the Helm chart with new values.
- Hooks — dit zijn uitvoerbare bestanden die door de Addon-operator worden gestart op gebeurtenissen, en die toegang krijgen tot de waardenopslag. De hook kan wijzigingen in het cluster volgen en de waarden in de waardenopslag bijwerken. Met hooks kan je discovery maken om waarden uit het cluster te verzamelen bij de start of volgens een schema, of je kunt continuous discovery hebben door waarden uit het cluster te verzamelen bij wijzigingen in het cluster.
- Module — dit is een combinatie van een Helm-chart, een waardenopslag en hooks. Modules kunnen in- en uitgeschakeld worden. Het uitschakelen van een module betekent het verwijderen van alle releases van het Helm-chart. Modules kunnen zichzelf dynamisch inschakelen, bijvoorbeeld als alle benodigde modules zijn ingeschakeld of als discovery in de hooks de vereiste parameters heeft gevonden — dit gebeurt met behulp van een ondersteunend enabled-script.
- Globale hooks. Dit zijn hooks "op zichzelf", ze zijn niet opgenomen in modules en hebben toegang tot de globale waardenopslag, waarvan de waarden beschikbaar zijn voor alle hooks in modules.
Hoe werken deze onderdelen samen? Laten we een afbeelding uit de documentatie bekijken:
Er zijn twee scenario's:
- De globale hook wordt gestart op een gebeurtenis — bijvoorbeeld bij het wijzigen van een resource in het cluster. Deze hook verwerkt de wijzigingen en schrijft nieuwe waarden naar de globale waardenopslag. De Addon-operator merkt op dat de globale opslag is gewijzigd en start alle modules. Elke module bepaalt met zijn hooks of deze moet inschakelen, en werkt zijn eigen waardenopslag bij. Als de module is ingeschakeld, start de Addon-operator de installatie van het Helm-chart. Het Helm-chart heeft toegang tot waarden uit zowel de moduleopslag als de globale opslag.
- Het tweede scenario is eenvoudiger: de modulaire hook wordt gestart op een gebeurtenis en wijzigt waarden in de waardenopslag van de module. De Addon-operator merkt dit op en start het Helm-chart met de bijgewerkte waarden.
Een toevoeging kan worden geïmplementeerd als één enkele hook of als één Helm-chart, of zelfs als verschillende afhankelijke modules — dit hangt af van de complexiteit van de component die in het cluster wordt geïnstalleerd en het gewenste niveau van configuratieflexibiliteit. Bijvoorbeeld, in de repository () is er een toevoeging sysctl-tuner, die zowel als een eenvoudige module met een hook en Helm-chart is geïmplementeerd, als met gebruik van waardenopslag, wat de mogelijkheid biedt om instellingen toe te voegen door ConfigMap te bewerken.
Levering van updates
Enkele woorden over het organiseren van updates van componenten die door de Addon-operator worden geïnstalleerd.
Om de Addon-operator in een cluster te starten, moet je een afbeelding met aanvullingen samenstellen in de vorm van hook-bestanden en Helm-diagrammen, het binaire bestand toevoegen addon-operator en alles wat nodig is voor de hooks: bash, kubectl, jq, python enzovoort. Vervolgens kan deze afbeelding in het cluster worden uitgerold als een gewone applicatie en je wilt waarschijnlijk een of andere tagging-schema organiseren. Als er maar een paar clusters zijn, kan dezelfde aanpak worden toegepast als bij applicaties: nieuwe release, nieuwe versie, door alle clusters gaan en het image van de Pods aanpassen. Echter, in het geval van uitrol naar een significante hoeveelheid clusters, is het concept van zelf-updating vanuit het kanaal meer geschikt voor ons.
Zo hebben we het geregeld:
- Een kanaal is in feite een identificatie die je vrij kunt toekennen (bijvoorbeeld, dev/stage/ea/stable).
- De naam van het kanaal is het tag van de afbeelding. Wanneer het tijd is om updates naar het kanaal uit te rollen, wordt er een nieuwe afbeelding samengesteld en getagd met de naam van het kanaal.
- Wanneer er een nieuwe afbeelding in de registry verschijnt, wordt de Addon-operator opnieuw gestart en met de nieuwe afbeelding uitgevoerd.
Dit is geen best practice, zoals beschreven in . Dit wordt niet aanbevolen, maar het gaat om een gewone applicatie die in één cluster draait. In het geval van de Addon-operator is de applicatie een verzameling Deployments verspreid over clusters, en zelf-updating helpt enorm en vergemakkelijkt het leven.
Kanalen helpen ook bij testen: als er een ondersteunend cluster is, kan het op een kanaal worden ingesteld stage en updates naar dit cluster worden uitgerold voordat ze naar de kanalen worden uitgerold. ea en stable. Als er een fout optrad met het cluster op het kanaal, kan het worden omgeschakeld naar ea , terwijl het probleem met dit cluster wordt onderzocht. Als het cluster uit actieve ondersteuning is gehaald, schakelt het over naar zijn "bevroren" kanaal — bijvoorbeeld, stablefreeze-2019-03-20 Naast het bijwerken van hooks en Helm-diagrammen kan het nodig zijn.
ook een externe component bij te werken . Bijvoorbeeld, je merkte een fout op in de hypothetische node-exporter en je hebt zelfs bedacht hoe je deze kunt patchen. Vervolgens heb je een PR geopend en wacht je op de nieuwe release om door alle clusters te gaan en de versie van de afbeelding te verhogen. Om niet op een onbepaalde tijd te wachten, kun je je eigen node-exporter samenstellen en naar die versie overschakelen totdat de PR is goedgekeurd.. Bijvoorbeeld, je hebt een fout opgemerkt in de conditionele node-exporter en zelfs bedacht hoe je het kunt patchen. Je hebt vervolgens een PR geopend en wacht op een nieuwe release om door alle clusters te gaan en de versie van het image te verhogen. Om niet onbepaalde tijd te wachten, kun je je eigen node-exporter bouwen en daarop overschakelen totdat de PR is goedgekeurd.
In principe kan dit ook zonder de Addon-operator, maar met de Addon-operator wordt de module voor de installatie van de node-exporter zichtbaar in één repository, kan het Dockerfile voor het bouwen van je eigen image ook daar worden gehouden, en wordt het voor alle betrokkenen gemakkelijker om te begrijpen wat er gaande is... En als er meerdere clusters zijn, wordt het ook eenvoudiger om je PR te testen en een nieuwe versie uit te rollen!
Deze organisatie van componentupdates werkt succesvol bij ons, maar het is ook mogelijk om een andere geschikte aanpak te implementeren — immers, in dit geval is de Addon-operator een eenvoudig binaire bestand..
Conclusie
De principes die in de Addon-operator zijn geïmplementeerd, maken het mogelijk om een transparant proces voor het maken, testen, installeren en bijwerken van extensies in de cluster op te zetten, vergelijkbaar met de processen van de ontwikkeling van gewone applicaties.
Extensies voor de Addon-operator in de vorm van modules (Helm-chart + hooks) kunnen openbaar worden gedeeld. Wij, het bedrijf Flant, zijn van plan om gedurende de zomer onze ontwikkelingen in de vorm van dergelijke extensies te delen. Sluit je aan bij de ontwikkeling op GitHub (, ), probeer je eigen extensie te maken op basis van en , houd ons op de hoogte via Habra en op ons !
P.S.
Lees ook op onze blog:
- «»;
- «».
Bron: habr.com
