Etter vi presenterer hans eldre bror - . Dette er et åpen kildekode-prosjekt som brukes til å installere systemkomponenter i en Kubernetes-klynge, som kan kalles tillegg.
Hvorfor noen tillegg i det hele tatt?
Det er ingen hemmelighet at Kubernetes ikke er et ferdig alt-i-ett-produkt, og for å bygge en "voksen" klynge trenger du forskjellige tillegg. Addon-operator vil hjelpe deg med å installere, konfigurere og holde disse tilleggene oppdatert.
Behovet for tilleggskomponenter i klyngen er opplyst i kolleger . Kort sagt, situasjonen med Kubernetes for øyeblikket er slik at for en enkel "lek rundt" installasjon kan du klare deg med komponentene ut av esken, for utviklere og testing kan du legge til Ingress, men for en full installasjon, ca. du kan si "produksjonen din er klar", du må legge til med et dusin forskjellige tillegg: noe for overvåking, noe for logging, ikke glem ingress og cert-manager, velg grupper av noder, legg til nettverkspolicyer, sesong med sysctl og pod autoscaler-innstillinger...
Hva er spesifikke ved å jobbe med dem?
Som praksis viser, er saken ikke begrenset til én installasjon. For å fungere komfortabelt med klyngen, må tilleggsprogrammer oppdateres, deaktiveres (fjernes fra klyngen), og du vil prøve noen før du installerer dem i produksjonsklyngen.
Så, kanskje Ansible vil være nok her? Kan være. Men Generelt lever ikke fullverdige tillegg uten innstillinger. Disse innstillingene kan variere avhengig av klyngevarianten (aws, gce, azure, bare-metal, do, ...). Noen innstillinger kan ikke spesifiseres på forhånd, de må hentes fra klyngen. Og klyngen er ikke statisk: for noen innstillinger må du overvåke endringer. Og her mangler Ansible allerede: du trenger et program som lever i en klynge, dvs. Kubernetes-operatør.
De som prøvde det på jobb , vil de si at oppgavene med å installere og oppdatere tillegg og overvåkingsinnstillinger kan løses fullstendig ved å bruke for shell-operatør. Du kan skrive et skript som vil gjøre en betinget kubectl apply og overvåk for eksempel ConfigMap, hvor innstillingene vil bli lagret. Dette er omtrent det som er implementert i addon-operator.
Hvordan er dette organisert i addon-operator?
Da vi laget en ny løsning, gikk vi ut fra følgende prinsipper:
- Tilleggsinstallasjonsprogrammet må støtte maling og deklarativ konfigurasjon. Vi lager ikke magiske skript som installerer tillegg. Addon-operator bruker Helm for å installere tillegg. For å installere, må du lage et diagram og velge verdiene som skal brukes for konfigurasjon.
- Innstillinger kan være generere ved installasjon, de kan få fra klyngenEller motta oppdateringer, overvåking av klyngeressurser. Disse operasjonene kan implementeres ved hjelp av kroker.
- Innstillinger kan være lagre i en klynge. For å lagre innstillinger i klyngen opprettes en ConfigMap/addon-operatør og Addon-operatøren overvåker endringer i denne ConfigMap. Addon-operator gir kroker tilgang til innstillinger ved hjelp av enkle konvensjoner.
- Tillegg avhenger av innstillinger. Hvis innstillingene har endret seg, ruller Addon-operatøren ut rordiagrammet med nye verdier. Vi kalte kombinasjonen av Helm-diagrammet, verdier for det og kroker for en modul (se nedenfor for flere detaljer).
- Iscenesettelse. Det er ingen magiske utgivelsesskript. Oppdateringsmekanismen ligner på en vanlig applikasjon - samle tilleggsprogrammer og tilleggsoperatører i et bilde, tag dem og rull dem ut.
- Resultatkontroll. Addon-operatør kan gi beregninger for Prometheus.
Hva er padding i addon-operator?
Et tillegg kan betraktes som alt som legger til nye funksjoner til klyngen. Installering av Ingress er for eksempel et godt eksempel på et tillegg. Dette kan være en hvilken som helst operatør eller kontroller med sin egen CRD: prometheus-operatør, cert-manager, kube-controller-manager, etc. Eller noe lite, men enklere å bruke - for eksempel hemmelig kopimaskin, som kopierer registerhemmeligheter til nye navneområder, eller sysctl-tuner, som konfigurerer sysctl-parametere på nye noder.
For å implementere tillegg tilbyr Addon-operator flere konsepter:
- Hjelmdiagram brukes til å installere diverse programvare i klyngen - for eksempel Prometheus, Grafana, nginx-ingress. Hvis den nødvendige komponenten har et Helm-diagram, vil det være veldig enkelt å installere det ved hjelp av Addon-operator.
- Verdier lagring. Hjelmdiagrammer har vanligvis mange forskjellige innstillinger som kan endres over tid. Addon-operatør støtter lagring av disse innstillingene og kan overvåke endringene deres for å reinstallere Helm-diagrammet med nye verdier.
- Kroker er kjørbare filer som Addon-operatøren kjører på hendelser og som har tilgang til verdilageret. Kroken kan overvåke endringer i klyngen og oppdatere verdiene i verdilageret. De. Ved å bruke kroker kan du gjøre funn for å samle verdier fra klyngen ved oppstart eller i henhold til en tidsplan, eller du kan gjøre kontinuerlig oppdagelse, samle verdier fra klyngen basert på endringer i klyngen.
- Modul er en kombinasjon av et Helm-diagram, en verdibutikk og kroker. Moduler kan aktiveres eller deaktiveres. Deaktivering av en modul betyr å slette alle Helm-kartutgivelser. Moduler kan aktivere seg selv dynamisk, for eksempel hvis alle modulene den trenger er aktivert eller hvis oppdagelsen har funnet de nødvendige parametrene i krokene - dette gjøres ved å bruke et ekstra aktivert skript.
- Globale kroker. Dette er kroker "på egen hånd", de er ikke inkludert i moduler og har tilgang til en global verdibutikk, hvis verdier er tilgjengelige for alle kroker i moduler.
Hvordan fungerer disse delene sammen? La oss se på bildet fra dokumentasjonen:
Det er to arbeidsscenarier:
- Den globale kroken utløses av en hendelse - for eksempel når en ressurs i klyngen endres. Denne kroken behandler endringene og skriver de nye verdiene til den globale verdibutikken. Addon-operatør merker at den globale lagringen har endret seg og starter alle moduler. Hver modul, ved hjelp av krokene, bestemmer om den må aktiveres og oppdaterer verdilageret. Hvis modulen er aktivert, starter Addon-operatøren installasjonen av Helm-diagrammet. I dette tilfellet har Helm-diagrammet tilgang til verdier fra modullageret og fra det globale lageret.
- Det andre scenariet er enklere: en modulkrok utløses av en hendelse og endrer verdier i modulens verdilager. Addon-operatør legger merke til dette og lanserer Helm-diagrammet med oppdaterte verdier.
Tillegget kan implementeres som én enkelt krok, eller som ett Helm-diagram, eller selv som flere avhengige moduler - dette avhenger av kompleksiteten til komponenten som installeres i klyngen og av ønsket nivå av konfigurasjonsfleksibilitet. For eksempel, i depotet () det er et sysctl-tuner-tillegg, som er implementert både som en enkel modul med en krok og et Helm-diagram, og ved å bruke verdilageret, som gjør det mulig å legge til innstillinger ved å redigere ConfigMap.
Levering av oppdateringer
Noen få ord om organisering av komponentoppdateringer som Addon-operatør installerer.
For å kjøre Addon-operator i en klynge trenger du bygge et bilde med tillegg i form av krok- og Helm-kartfiler, legg til en binær fil addon-operator og alt du trenger for kroker: bash, kubectl, jq, python etc. Deretter kan dette bildet rulles ut til klyngen som en vanlig applikasjon, og mest sannsynlig vil du organisere et eller annet merkeskjema. Hvis det er få klynger, kan samme tilnærming som med applikasjoner være passende: ny utgivelse, ny versjon, gå til alle klynger og korriger bildet av Pods. Men i tilfelle en utrulling til et betydelig antall klynger, var konseptet med selvoppdatering fra en kanal mer egnet for oss.
Slik gjør vi det:
- En kanal er i hovedsak en identifikator som kan settes til hva som helst (for eksempel dev/stage/ea/stable).
- Kanalnavnet er bildekoden. Når du trenger å rulle ut oppdateringer til en kanal, settes et nytt bilde sammen og merkes med kanalnavnet.
- Når et nytt bilde vises i registeret, startes Addon-operator på nytt og startes med det nye bildet.
Dette er ikke beste praksis, som skrevet i . Det anbefales ikke å gjøre dette, men vi snakker om en vanlig applikasjon som bor i samme klynge. Når det gjelder Addon-operator, er en applikasjon mange distribusjoner spredt på tvers av klynger, og selvoppdatering hjelper mye og gjør livet enklere.
Kanaler hjelper og i testing: hvis det er en hjelpeklynge, kan du konfigurere den til kanalen stage og rull oppdateringer inn i den før du ruller den ut til kanaler ea и stable. Hvis med en klynge på kanalen ea det oppstod en feil, kan du bytte den til stable, mens problemet med denne klyngen blir undersøkt. Hvis klyngen tas ut av aktiv støtte, bytter den til sin "frosne" kanal - f.eks. freeze-2019-03-20.
I tillegg til å oppdatere kroker og Helm-diagrammer, kan det hende du trenger oppdatering og tredjepartskomponent. For eksempel la du merke til en feil i den betingede node-eksportøren og fant til og med ut hvordan du lapper den. Deretter åpnet du PR og venter på at den nye utgivelsen skal gå gjennom alle klyngene og øke versjonen av bildet. For ikke å vente på ubestemt tid, kan du bygge node-eksportøren din og bytte til den før du godtar PR.
Generelt kan dette gjøres uten Addon-operator, men med Addon-operator vil modulen for å installere node-exporter være synlig i ett depot, Dockerfilen for å bygge bildet ditt kan holdes akkurat der, det blir enklere for alle deltakere i prosessen for å forstå hva som skjer... Og hvis det er flere klynger, så blir det lettere å både teste PR og rulle ut en ny versjon!
Denne organiseringen av komponentoppdatering fungerer vellykket for oss, men enhver annen passende ordning kan implementeres - tross alt i dette tilfellet er Addon-operator en enkel binær fil.
Konklusjon
Prinsippene implementert i Addon-operator lar deg bygge en transparent prosess for å lage, teste, installere og oppdatere tillegg i en klynge, lik utviklingsprosessene til vanlige applikasjoner.
Tillegg for Addon-operatør i modulformat (Helmdiagram + kroker) kan gjøres offentlig tilgjengelig. Vi, Flant-selskapet, planlegger å publisere utviklingen vår i form av slike tillegg i løpet av sommeren. Bli med i utvikling på GitHub (, ), prøv å lage ditt eget tillegg basert på и , vent på nyheter om Habré og på vår !
PS
Les også på bloggen vår:
- «";
- «'.
Kilde: www.habr.com