I kølvandet på præsenterer vi hans store bror — . Dette er et Open Source-projekt, der bruges til at installere systemkomponenter i en Kubernetes-klynge, som man kan kalde med det overordnede ord — tilføjelser.
Hvorfor kræves der overhovedet nogle tilføjelser?
Det er ingen hemmelighed, at Kubernetes ikke er et færdigt alt-i-ét produkt, og for at opbygge en 'fungerende' klynge kræves der forskellige tilføjelser. Addon-operatoren hjælper med at installere, konfigurere og holde disse tilføjelser opdaterede.
Behovet for yderligere komponenter i klyngen er beskrevet i kolleger . Kort sagt, situationen med Kubernetes er i øjeblikket sådan, at for en simpel installation til 'leg' kan man klare sig med komponenter fra kassen, til udviklere og testere kan man tilføje Ingress, men for en fuld installation, som man kan sige 'din produktion er klar', skal man tilføje et dusin forskellige tilføjelser: noget til overvågning, noget til logs, husk ingress og cert-manager, allokere node-grupper, tilføje netværkspolitikker, krydre med sysctl- og pod autoscaler-indstillinger...
Hvad er specifikationen for arbejdet med dem?
Som praksis viser, er det ikke nok bare at installere. For at arbejde komfortabelt med klyngen skal tilføjelserne opdateres, deaktiveres (fjernes fra klyngen), og noget skal testes før installationen i produktionsklyngen.
Så måske er Ansible nok her? Måske. Men fuldgyldige tilføjelser lever generelt ikke uden konfigurationer. Disse konfigurationer kan variere afhængigt af klyngevarianten (aws, gce, azure, bare-metal, do, ...). Nogle indstillinger kan ikke angives på forhånd — de skal hentes fra klyngen. Og klyngen er ikke statisk: for nogle indstillinger skal man følge ændringerne. Her er Ansible ikke nok: der er brug for et program, der lever i klyngen, altså en Kubernetes Operator.
De, der har prøvet at arbejde med , vil sige, at opgaverne med installation og opdatering af tilføjelser samt overvågning af konfigurationer fint kan løses med til shell-operatoren. Man kan skrive et script, der gør betinget kubectl apply og holder øje for eksempel med ConfigMap, hvor indstillingerne vil blive opbevaret. Det er omtrent det, der implementeres i addon-operatoren.
Hvordan er det organiseret i addon-operatoren?
Ved oprettelsen af en ny løsning tog vi udgangspunkt i følgende principper:
- Installationsprogrammet for tilføjelser skal understøtte skabelonbearbejdning 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 der oprettes et chart, og der skal udvælges værdier, der skal bruges til konfigurationen.
- Indstillinger kan genereres ved installationen, de kan hentes fra klyngen, eller modtage opdateringer, ved at overvåge klyngens ressourcer. Disse operationer kan implementeres ved hjælp af hooks.
- Indstillinger kan lagres i klyngen. For at gemme indstillinger i klyngen oprettes en ConfigMap/addon-operator, og Addon-operatoren overvåger ændringerne i denne ConfigMap. Addon-operatoren giver hooks adgang til indstillingerne ved hjælp af enkle konventioner.
- Tilføjelsen afhænger af indstillingerne. Hvis indstillingerne ændrer sig, vil Addon-operatoren udsende Helm-chartet med de nye værdier. Kombinationen af Helm-chartet, værdierne til det og hooks kalder vi et modul (læs mere nedenfor).
- Staging. Der er ingen magiske release-scripts. Opdateringsmekanismen svarer til et almindeligt program - samle tilføjelserne og addon-operatoren i et billede, tagge og udsende.
- Resultatkontrol. Addon-operatoren kan returnere målinger til Prometheus.
Hvad er en tilføjelse i addon-operatoren?
En tilføjelse kan betragtes som alt, der tilføjer nye funktioner til klyngen. For eksempel er installationen af Ingress et fremragende eksempel på en tilføjelse. Det kan være enhver operator eller controller med sin CRD: prometheus-operator, cert-manager, kube-controller-manager osv. Eller noget lille, men som forenkler driften - for eksempel en secret copier, der kopierer registry-hemmeligheder til nye navneområder, eller en sysctl tuner, der justerer sysctl-parametre på nye noder.
For at implementere tilføjelser giver Addon-operatoren flere koncepter:
- Helm-chart bruges til at installere forskellige software i klyngen - for eksempel Prometheus, Grafana, nginx-ingress. Hvis den påkrævede komponent har et Helm-chart, vil det være meget let at installere det med hjælp fra Addon-operatoren.
- Opbevaring af værdier. Helm-charts har normalt mange forskellige indstillinger, der kan ændre sig over tid. Addon-operatoren understøtter opbevaring af disse indstillinger og kan overvåge deres ændringer for at geninstallere Helm-chartet med nye værdier.
- Hooks — er eksekverbare filer, som Addon-operatoren kører ved hændelser og som får adgang til værdilageret. Et hook kan overvåge ændringer i klyngen og opdatere værdierne i værdilageret. Det vil sige, at med hooks kan der laves discovery for at indsamle værdier fra klyngen ved opstart eller efter en tidsplan, eller man kan foretage kontinuerlig discovery ved at indsamle værdier fra klyngen ved ændringer i klyngen.
- Module — er en samling af Helm-chart, værdilager og hooks. Moduler kan aktiveres og deaktiveres. Deaktivering af et modul betyder fjernelse af alle udgivelser af Helm-chartet. Moduler kan dynamisk inkludere sig selv, for eksempel hvis alle nødvendige moduler er aktiveret, eller hvis discovery i hooks har fundet de nødvendige parametre — dette gøres ved hjælp af et hjælpe-script til enabled.
- Globale hooks. Dette er hooks "i sig selv", de er ikke inkluderet i moduler og har adgang til det globale værdilager, hvis værdier er tilgængelige for alle hooks i modulerne.
Hvordan arbejder disse dele sammen? Lad os se på et billede fra dokumentationen:
Der er to scenarier:
- Den globale hook aktiveres af en hændelse — for eksempel ved ændring af en ressource i klyngen. Denne hook behandler ændringerne og skriver nye værdier i det globale værdilager. Addon-operatoren bemærker, at det globale værdilager er ændret, og aktiverer alle moduler. Hvert modul bestemmer ved hjælp af sine hooks, om det skal aktiveres, og opdaterer sit værdilager. Hvis modulet er aktiveret, aktiverer Addon-operatoren installationen af Helm-chartet. Helm-chartet har adgang til værdier fra modulens værdilager og fra det globale værdilager.
- Det andet scenario er enklere: modul-hooken aktiveres ved en hændelse og ændrer værdierne i modulens værdilager. Addon-operatoren bemærker dette og aktiverer Helm-chartet med de opdaterede værdier.
Et supplement kan implementeres som en enkelt hook, eller som et Helm-chart, eller endda som flere afhængige moduler — det afhænger af kompleksiteten af den komponent, der installeres i klyngen, og det ønskede niveau af tilpasningsmuligheder. For eksempel findes der i repositoryet () et supplement sysctl-tuner, som er implementeret både som et simpelt modul med en hook og et Helm-chart, samt ved brug af værdilager, hvilket giver mulighed for at tilføje indstillinger ved at redigere ConfigMap.
Levering af opdateringer
Et par ord om organiseringen af opdateringer til komponenter, som Addon-operator installerer.
For at køre Addon-operator i klyngen skal man samle et billede med tilføjelser i form af hook-filer og Helm-diagrammer, tilføje det binære fil addon-operator og alt, hvad der er nødvendigt for hooks: bash, kubectl, jq, python og så videre. Derefter kan dette billede udrulles i klyngen som en almindelig applikation, og det er sandsynligt, at du ønsker at organisere en eller anden form for tagging. Hvis der kun er få klynger, kan den samme tilgang som med applikationer være passende: ny udgivelse, ny version, gå gennem alle klynger og opdatere billedet hos Pod’erne. Men i tilfælde af udruldning til et betydeligt antal klynger, passer konceptet med selvopdatering fra en kanal os bedre.
Vi har det organiseret sådan:
- En kanal er i bund og grund en identifikator, som kan angives til enhver (f.eks. dev/stage/ea/stable).
- Kanalens navn er billedets tag. Når opdateringer skal sendes til kanalen, samles et nyt billede og tagges med kanalens navn.
- Når et nyt billede dukker op i registreringen, genstartes Addon-operatoren og kører med det nye billede.
Dette er ikke best practice, som beskrevet i . Det anbefales ikke at gøre sådan, men det handler om en almindelig applikation, der lever i en enkelt klynge. I tilfælde af Addon-operator er applikationen et antal Deployments, der er fordelt over klyngerne, og selvopdatering er en stor hjælp og forenkler livet.
Kanaler hjælper også i testning: hvis der er en hjælpende klynge, kan den indstilles til kanalen stage og køre opdateringer til den, før de udrulles til kanalerne ea og stable. Hvis der er opstået en fejl med klyngen på kanalen ea , kan den skiftes til stable, mens efterforskningen af problemet med denne klynge står på. Hvis klyngen er taget fra aktiv støtte, skifter den til sin "frosne" kanal — for eksempel, freeze-2019-03-20.
Udover opdateringer af hooks og Helm-diagrammer kan det være nødvendigt at opdatere en tredjepartskomponent. For eksempel, hvis du har bemærket en fejl i en hypotetisk node-exporter og endda har tænkt over, hvordan du kan patche den. Derefter åbnede du en PR og venter på en ny udgivelse for at gå igennem alle klynger og øge versionen af billedet. For ikke at vente i uforudsigelig tid kan du samle din egen node-exporter og skifte til den, indtil PR'en er godkendt.
Generelt set kan det også gøres uden Addon-operator, men med Addon-operator vil modulet til installation af node-exporter være synligt i et repository, Dockerfile til at bygge sin egen image kan holdes der, og det bliver lettere for alle deltagere at forstå, hvad der foregår... Og hvis der er flere klynger, bliver det lettere både at teste sin PR og at rulle en ny version ud!
Denne organisation af komponentopdateringer fungerer godt for os, men man kan også implementere enhver anden passende ordning — for i dette tilfælde er Addon-operator en simpel binær fil.
Konklusion
Principperne, der er implementeret i Addon-operator, muliggør en gennemsigtig proces for oprettelse, test, installation og opdatering af tilføjelser i klyngen, der ligner processerne til udvikling af almindelige applikationer.
Tilføjelser til Addon-operator i modulformat (Helm-diagram + hooks) kan gøres bredt tilgængelige. Vi, Flant Company, planlægger at udgive vores arbejde i form af sådanne tilføjelser i løbet af sommeren. Deltag i udviklingen på GitHub (, ), prøv at lave dit eget tilføjelse baseret på og , vent på nyheder på Habr og på vores !
P.S.
Læs også på vores blog:
- «»;
- «».
Kilde: habr.com
