Efter vi præsenterer hans ældre bror - . Dette er et Open Source-projekt, der bruges til at installere systemkomponenter i en Kubernetes-klynge, som kan kaldes tilføjelser.
Hvorfor nogen tilføjelser overhovedet?
Det er ingen hemmelighed, at Kubernetes ikke er et færdiglavet alt-i-et-produkt, og for at bygge en "voksen" klynge skal du have forskellige tilføjelser. Addon-operator hjælper dig med at installere, konfigurere og holde disse tilføjelser opdateret.
Behovet for yderligere komponenter i klyngen er oplyst i Kollegaer . Kort sagt, situationen med Kubernetes i øjeblikket er sådan, at du for en simpel "spil rundt" installation kan klare dig med komponenterne ud af kassen, for udviklere og test kan du tilføje Ingress, men for en fuld installation, ca. du kan sige "din produktion er klar", du skal tilføje med et dusin forskellige tilføjelser: noget til overvågning, noget til logning, glem ikke ingress og cert-manager, vælg grupper af noder, tilføje netværkspolitikker, sæson med sysctl og pod autoscaler indstillinger...
Hvad er det specifikke ved at arbejde med dem?
Som praksis viser, er sagen ikke begrænset til én installation. For at arbejde komfortabelt med klyngen skal tilføjelser opdateres, deaktiveres (fjernes fra klyngen), og du vil gerne teste nogle, før du installerer dem i produktionsklyngen.
Så måske er Ansible nok her? Måske. Men Generelt lever fuldgyldige tilføjelser ikke uden indstillinger. Disse indstillinger kan variere afhængigt af klyngevarianten (aws, gce, azure, bare-metal, do, ...). Nogle indstillinger kan ikke specificeres på forhånd; de skal hentes fra klyngen. Og klyngen er ikke statisk: for nogle indstillinger bliver du nødt til at overvåge ændringer. Og her mangler Ansible allerede: du skal bruge et program, der lever i en klynge, dvs. Kubernetes operatør.
Dem, der prøvede det på arbejdet , vil de sige, at opgaverne med at installere og opdatere tilføjelser og overvågningsindstillinger fuldstændigt kan løses vha. for shell-operatør. Du kan skrive et script, der vil gøre en betinget kubectl apply og overvåg for eksempel ConfigMap, hvor indstillingerne vil blive gemt. Dette er omtrent hvad der er implementeret i addon-operator.
Hvordan er dette organiseret i addon-operator?
Da vi lavede en ny løsning, gik vi ud fra følgende principper:
- Tilføjelsesinstallationsprogrammet skal understøtte skabelon og deklarativ konfiguration. Vi laver ikke magiske scripts, der installerer tilføjelser. Addon-operator bruger Helm til at installere tilføjelser. For at installere skal du oprette et diagram og vælge de værdier, der skal bruges til konfiguration.
- Indstillinger kan være generere ved installation, kan de være komme fra klyngeEller modtage opdateringer, overvågning af klyngressourcer. Disse operationer kan implementeres ved hjælp af kroge.
- Indstillinger kan være opbevares i en klynge. For at gemme indstillinger i klyngen oprettes en ConfigMap/addon-operator, og Addon-operatoren overvåger ændringer af denne ConfigMap. Addon-operator giver hooks adgang til indstillinger ved hjælp af simple konventioner.
- Tilføjelse afhænger af indstillinger. Hvis indstillingerne er ændret, så ruller Addon-operatøren ud Helm-diagrammet med nye værdier. Vi kaldte kombinationen af Helm-diagrammet, værdier for det og kroge for et modul (se nedenfor for flere detaljer).
- Iscenesættelse. Der er ingen magiske udgivelsesscripts. Opdateringsmekanismen ligner en almindelig applikation - saml tilføjelser og tilføjelsesoperatører i et billede, tag dem og rul dem ud.
- Resultatkontrol. Addon-operator kan levere metrics for Prometheus.
Hvad er padding i addon-operator?
En tilføjelse kan betragtes som alt, der tilføjer nye funktioner til klyngen. For eksempel er installation af Ingress et godt eksempel på en tilføjelse. Dette kan være enhver operatør eller controller med sin egen CRD: prometheus-operatør, cert-manager, kube-controller-manager osv. Eller noget lille, men nemmere at bruge - for eksempel hemmelig kopimaskine, som kopierer registreringshemmeligheder til nye navnerum, eller sysctl-tuner, som konfigurerer sysctl-parametre på nye noder.
For at implementere tilføjelser giver Addon-operator flere koncepter:
- Hjelm diagram bruges til at installere diverse software i klyngen - for eksempel Prometheus, Grafana, nginx-ingress. Hvis den nødvendige komponent har et Helm-diagram, vil det være meget enkelt at installere det ved hjælp af Addon-operator.
- Opbevaring af værdier. Hjelmdiagrammer har normalt mange forskellige indstillinger, der kan ændre sig over tid. Addon-operator understøtter lagring af disse indstillinger og kan overvåge deres ændringer for at geninstallere Helm-diagrammet med nye værdier.
- Kroge er eksekverbare filer, som Addon-operatøren kører på begivenheder, og som har adgang til værdilageret. Krogen kan overvåge ændringer i klyngen og opdatere værdierne i værdilageret. De der. Ved hjælp af kroge kan du foretage opdagelse for at indsamle værdier fra klyngen ved opstart eller i henhold til en tidsplan, eller du kan foretage kontinuerlig opdagelse, og indsamle værdier fra klyngen baseret på ændringer i klyngen.
- Modul er en kombination af et Helm-diagram, et værdilager og kroge. Moduler kan aktiveres eller deaktiveres. Deaktivering af et modul betyder at slette alle Helm-kortudgivelser. Moduler kan aktivere sig selv dynamisk, f.eks. hvis alle de moduler, de har brug for, er aktiveret, eller hvis opdagelsen har fundet de nødvendige parametre i krogene - dette gøres ved hjælp af et aux-aktiveret script.
- Globale kroge. Disse er kroge "på egen hånd", de er ikke inkluderet i moduler og har adgang til et globalt værdilager, hvis værdier er tilgængelige for alle kroge i moduler.
Hvordan fungerer disse dele sammen? Lad os se på billedet fra dokumentationen:
Der er to arbejdsscenarier:
- Den globale hook udløses af en hændelse - for eksempel når en ressource i klyngen ændres. Denne krog behandler ændringerne og skriver de nye værdier til den globale værdibutik. Addon-operatør bemærker, at det globale lager er ændret og starter alle moduler. Hvert modul, ved hjælp af dets kroge, bestemmer, om det skal aktiveres, og opdaterer dets værdilager. Hvis modulet er aktiveret, starter Addon-operatøren installationen af Helm-diagrammet. I dette tilfælde har Helm-kortet adgang til værdier fra modullageret og fra det globale lager.
- Det andet scenario er enklere: en modulhook udløses af en hændelse og ændrer værdier i modulets værdilager. Addon-operatør bemærker dette og lancerer Helm-diagrammet med opdaterede værdier.
Tilføjelsen kan implementeres som en enkelt krog, eller som et Helm-diagram, eller selv som flere afhængige moduler - dette afhænger af kompleksiteten af den komponent, der installeres i klyngen, og af det ønskede niveau af konfigurationsfleksibilitet. For eksempel i depotet () er der en sysctl-tuner-add-on, som er implementeret både som et simpelt modul med en krog og et Helm-diagram og ved hjælp af værdilageret, som gør det muligt at tilføje indstillinger ved at redigere ConfigMap.
Levering af opdateringer
Et par ord om organisering af komponentopdateringer, som Addon-operator installerer.
For at køre Addon-operator i en klynge skal du bruge opbygge et billede med tilføjelser i form af krog- og Helm-diagramfiler, tilføje en binær fil addon-operator og alt hvad du skal bruge til kroge: bash, kubectl, jq, python etc. Så kan dette billede rulles ud til klyngen som en almindelig applikation, og højst sandsynligt vil du gerne organisere et eller andet tagging-skema. Hvis der er få klynger, kan den samme tilgang som med applikationer være passende: ny udgivelse, ny version, gå til alle klynger og ret billedet af Pods. Men i tilfælde af en udrulning til et betydeligt antal klynger, var konceptet med selvopdatering fra en kanal mere egnet for os.
Sådan gør vi det:
- En kanal er i bund og grund en identifikator, der kan indstilles til hvad som helst (f.eks. dev/stage/ea/stable).
- Kanalnavnet er billedmærket. Når du skal udrulle opdateringer til en kanal, samles et nyt billede og tagges med kanalnavnet.
- Når et nyt billede vises i registreringsdatabasen, genstartes Addon-operator og startes med det nye billede.
Dette er ikke bedste praksis, som skrevet i . Det anbefales ikke at gøre dette, men vi taler om en almindelig applikation, der bor i samme klynge. I tilfælde af Addon-operatør er en applikation en masse implementeringer spredt på tværs af klynger, og selvopdatering hjælper meget og gør livet lettere.
Kanaler hjælper og i test: hvis der er en hjælpeklynge, kan du konfigurere den til kanalen stage og rulle opdateringer ind i den, før den rulles ud til kanaler ea и stable. Hvis med en klynge på kanalen ea der opstod en fejl, kan du skifte til stable, mens problemet med denne klynge bliver undersøgt. Hvis klyngen tages ud af aktiv understøttelse, skifter den til sin "frosne" kanal - f.eks. freeze-2019-03-20.
Ud over at opdatere kroge og Helm-diagrammer, har du muligvis brug for opdatering og tredjepartskomponent. For eksempel bemærkede du en fejl i den betingede node-eksporter og fandt endda ud af, hvordan du retter den. Dernæst åbnede du PR og venter på, at den nye udgivelse går gennem alle klyngerne og øger versionen af billedet. For ikke at vente på ubestemt tid, kan du bygge din node-eksportør og skifte til den, før du accepterer PR.
Generelt kan dette gøres uden Addon-operator, men med Addon-operator vil modulet til installation af node-exporter være synligt i ét lager, Dockerfilen til opbygning af dit billede kan opbevares lige der, det bliver nemmere for alle deltagere i processen for at forstå, hvad der sker... Og hvis der er flere klynger, så bliver det nemmere både at teste din PR og rulle en ny version ud!
Denne organisation af komponentopdatering fungerer med succes for os, men enhver anden passende ordning kan implementeres - trods alt i dette tilfælde er Addon-operator en simpel binær fil.
Konklusion
Principperne implementeret i Addon-operator giver dig mulighed for at opbygge en gennemsigtig proces til oprettelse, test, installation og opdatering af tilføjelser i en klynge, svarende til udviklingsprocesserne for almindelige applikationer.
Tilføjelser til Addon-operatør i modulformat (Hjelmdiagram + kroge) kan gøres offentligt tilgængelige. Vi, Flant-virksomheden, planlægger at offentliggøre vores udviklinger i form af sådanne tilføjelser i løbet af sommeren. Deltag i udvikling på GitHub (, ), prøv at lave din egen tilføjelse baseret på и , vent på nyheder om Habré og på vores !
PS
Læs også på vores blog:
- «";
- «'.
Kilde: www.habr.com