🥇Er det enkelt og praktisk å forberede Kubernetes-klyngen? Vi kunngjør addon-operator

Er det enkelt og praktisk å sette opp et Kubernetes-kluster? Vi lanserer addon-operator

I kjølvannet av shell-operator vi presenterer hans eldre bror — addon-operator. Dette er et Open Source-prosjekt som brukes til å installere systemkomponenter i en Kubernetes-klynge, som samlet kan kalles tillegg.

Hvorfor trenger vi i det hele tatt noen tillegg?

Det er ingen hemmelighet at Kubernetes ikke er et klart produkt alt-i-ett, og for å bygge en 'moden' klynge vil det være behov for ulike tillegg. Addon-operatoren vil hjelpe med å installere, konfigurere og holde disse tilleggene oppdatert.

Behovet for ekstra komponenter i klyngen er tatt opp i foredraget kolleger driusha. Kort sagt, situasjonen med Kubernetes i dag er slik at for enkel installasjon for å 'leke' kan man klare seg med innebygde komponenter, for utvikling og testing kan man legge til Ingress, men for en fullverdig installasjon, hvor man kan si 'produksjonen er klar', må man legge til rundt ti forskjellige tillegg: noe for overvåking, noe for logger, ikke glem ingress og cert-manager, tildele grupper av noder, legge til nettverksregler, krydre med sysctl-innstillinger og pod autoscaler…

Er det enkelt og praktisk å sette opp et Kubernetes-kluster? Vi lanserer addon-operator

Hva er spesifisiteten ved å jobbe med dem?

Som praksis viser, er det ikke nok med en enkel installasjon. For komfortabelt arbeid med klyngen, må tilleggene oppdateres, deaktiveres (fjernes fra klyngen), og noe vil man kanskje teste før installasjon i produksjonsklyngen.

Så, kanskje Ansible er tilstrekkelig her? Kanskje. Men fullverdige tillegg lever vanligvis ikke uten konfigurasjoner. Disse konfigurasjonene kan variere avhengig av klyngealternativet (aws, gce, azure, bare-metal, do, …). Noen innstillinger kan ikke angis på forhånd - de må hentes fra klyngen. Og klyngen er ikke statisk: for noen innstillinger må man følge med på endringer. Her er Ansible ikke nok: man trenger et program som lever i klyngen, altså Kubernetes Operator.

De som har prøvd det i praksis shell-operator, vil si at oppgavene med å installere og oppdatere tillegg og holde øye med konfigurasjoner, ganske enkelt kan løses med hookene for shell-operator. Man kan skrive et skript som gjør en betinget kubectl apply og holder øye med for eksempel ConfigMap, hvor konfigurasjonene vil bli lagret. Omtrent dette er implementert i addon-operator.

Hvordan er dette organisert i addon-operator?

Når vi skapte en ny løsning, baserte vi oss på følgende prinsipper:

Installeringsverktøyet for tillegg må støtte malbasert og deklarativ konfigurasjon. Vi lager ikke magiske skript som installerer tillegg. Addon-operatøren bruker Helm for å installere tillegg. For installasjon må du opprette et chart og spesifisere verdier som skal brukes til konfigurasjon.
Innstillingene kan genereres ved installasjon, de kan hentes fra klyngen, eller motta oppdateringer, ved å overvåke ressursene til klyngen. Disse operasjonene kan implementeres med hjelp av hooks.
Innstillingene kan lagres i klyngen. For å lagre innstillinger i klyngen opprettes en ConfigMap/addon-operator, og Addon-operatøren overvåker endringer i denne ConfigMap. Addon-operatøren gir hooks tilgang til innstillingene gjennom enkle konvensjoner.
Tillegget avhenger av innstillingene. Hvis innstillingene endres, ruller Addon-operatøren ut Helm-chartet med nye verdier. Sammenkoblingen av Helm-chartet, verdiene for det og hooks har vi kalt et modul (se mer under).
Staging. Det finnes ingen magiske utgivelsesskript. Oppdateringsmekanismen er lik en vanlig applikasjon - samle tillegg og addon-operatøren i et bilde, tagge det og rulle det ut.
Resultatkontroll. Addon-operatøren kan gi metrikker for Prometheus.

Hva er et tillegg i addon-operatøren?

Et tillegg kan betraktes som alt som legger til nye funksjoner i klyngen. For eksempel er installasjon av Ingress et utmerket eksempel på et tillegg. Dette kan være hvilken som helst operator eller kontroller med sin egen CRD: prometheus-operator, cert-manager, kube-controller-manager, osv. Eller noe lite, men som forenkler driften - som en secret copier som kopierer registry-hemmeligheter til nye navnerom, eller en sysctl tuner som konfigurerer sysctl-innstillinger på nye noder.

For å implementere tillegg gir Addon-operatøren flere konsepter:

Helm-diagram brukes for å installere forskjellig programvare i klyngen - for eksempel Prometheus, Grafana, nginx-ingress. Hvis den nødvendige komponenten har et Helm-chart, vil det være veldig enkelt å installere det med Addon-operatøren.
Lager for verdier. Helm-charts har vanligvis mange forskjellige innstillinger som kan endres over tid. Addon-operatøren støtter lagring av disse innstillingene og kan overvåke endringene for å reinstallere Helm-chartet med nye verdier.
Hooks — er utfyllingsfiler som Addon-operatøren kjører ved hendelser og som får tilgang til lagringen av verdier. En hook kan overvåke endringer i klyngen og oppdatere verdiene i lagringen av verdier. Det vil si at ved hjelp av hooks kan man gjøre discovery for å samle verdier fra klyngen ved oppstart eller etter en tidsplan, eller man kan gjøre kontinuerlig discovery ved å samle verdier fra klyngen på endringer i klyngen.
Modul — er en sammenslutning av Helm-diagram, lagring av verdier og hooks. Moduler kan slås av og på. Avslutning av en modul innebærer å slette alle utgivelsene av Helm-diagrammet. Moduler kan dynamisk inkludere seg selv, for eksempel hvis alle nødvendige moduler er aktivert eller hvis discovery i hooks har funnet de nødvendige parameterne — dette gjøres ved hjelp av en hjelpeskript for enabled.
Globale hooks. Det er hooks "for seg selv", de er ikke inkludert i moduler og har tilgang til den globale lagringen av verdier, verdiene fra dette er tilgjengelig for alle hooks i modulene.

Hvordan fungerer disse delene sammen? La oss se på bildet fra dokumentasjonen:

Er det enkelt og praktisk å sette opp et Kubernetes-kluster? Vi lanserer addon-operator

Det er to arbeidscenarioer:

Den globale hooken kjøres ved en hendelse — for eksempel når en ressurs i klyngen endres. Denne hooken behandler endringer og skriver nye verdier til den globale lagringen av verdier. Addon-operatøren merker at den globale lagringen har endret seg og starter alle modulene. Hver modul bestemmer med sine hooks om den skal aktiveres, og oppdaterer sin egen lagring av verdier. Hvis modulen er aktivert, starter Addon-operatøren installasjonen av Helm-diagrammet. Helm-diagrammet har da tilgang til verdiene fra lagringen av modulen og fra den globale lagringen.
Det andre scenarioet er enklere: den modulære hooken kjøres ved en hendelse og endrer verdier i lagringen av verdiene for modulen. Addon-operatøren merker dette og starter Helm-diagrammet med oppdaterte verdier.

Tillegget kan implementeres som én enkelt hook eller som ett Helm-diagram, eller til og med som flere avhengige moduler — dette avhenger av kompleksiteten av komponenten som installeres i klyngen og ønsket fleksibilitetsnivå i innstillingene. For eksempel, i depotet (/examples) finnes det et tillegg som heter sysctl-tuner, som er implementert både som et enkelt modul med hook og Helm-diagram, og med bruk av lagring av verdier, noe som gir mulighet til å legge til innstillinger gjennom redigering av ConfigMap.

Levering av oppdateringer

Noen ord om organisering av oppdateringer av komponentene som installeres av Addon-operator.

For å starte Addon-operator i klyngen, må man bygge et bilde med tillegg i form av hook-filer og Helm-diagrammer, legge til binærfilen addon-operator og alt som trengs for hookene: bash, kubectl, jq, python osv. Deretter kan dette bildet distribueres til klyngen som en vanlig applikasjon, og det er sannsynlig at du vil organisere en eller annen merkestruktur. Hvis det er få klynger, kan den samme tilnærmingen som med applikasjoner fungere: ny utgave, ny versjon, gå gjennom alle klyngene og oppdatere image på Pod'ene. Imidlertid, når det gjelder å distribueres til et betydelig antall klynger, passer konsepter for selvoppdatering fra kanalen bedre.

Vi har dette strukturert slik:

Kanalen er i hovedsak en identifikator som kan settes til hva som helst (for eksempel dev/stage/ea/stable).
Kanalnavnet er taggen for bildet. Når det er behov for å rulle ut oppdateringer til kanalen, bygges et nytt bilde og tagges med kanalnavnet.
Når det kommer et nytt bilde i registry, restartes Addon-operator og startes med det nye bildet.

Dette er ikke en best practice, som beskrevet i Kubernetes-dokumentasjonen. Det anbefales ikke å gjøre dette, men det dreier seg om en vanlig applikasjon som lever i én klynge. I tilfelle av Addon-operator er applikasjonen et antall Deployments spredt over klyngene, og selvoppdatering er svært nyttig og forenkler livet.

Kanalene hjelper også i testing: hvis det finnes en hjelpeklynge, kan man konfigurere den til en kanal stage og rulle ut oppdateringer til den før de rulles ut til kanalene. ea og stable. Hvis det oppstår en feil med klyngen i kanalen, kan den bli byttet til ea , mens undersøkelsen av problemet med denne klyngen pågår. Hvis klyngen er fjernet fra aktiv støtte, bytter den til sin 'fryst' kanal – for eksempel, stablefreeze-2019-03-20 I tillegg til oppdateringer av hookene og Helm-diagrammene kan det være nødvendig å.

oppdatere en tredjeparts komponent . For eksempel, hvis du har oppdaget en feil i den hypotetiske node-exporteren og til og med har funnet en løsning for å patch den. Deretter åpnet du en PR og venter på en ny utgave for å gå gjennom alle klyngene og oppgradere bildet. For ikke å vente ubegripelig lenge, kan man bygge sin egen node-exporter og bytte til den før PR-en blir godkjent..

Generelt kan dette gjøres uten Addon-operator, men med Addon-operator blir modulen for å installere node-exporter synlig i ett repository, Dockerfile for å bygge sitt eget bilde kan holdes der, og alle involverte får en lettere forståelse av hva som skjer... Og hvis det er flere klynger, blir det enklere både å teste sin PR og å rulle ut en ny versjon!

Denne organisasjonen for oppdatering av komponenter fungerer godt hos oss, men det er mulig å implementere enhver annen passende ordning — for i dette tilfellet er Addon-operator en enkel binærfil..

Konklusjon

Prinsippene som er implementert i Addon-operator, gjør det mulig å etablere en transparent prosess for oppretting, testing, installasjon og oppdatering av tillegg i klyngen, sammenlignbart med prosessene for utvikling av vanlige applikasjoner.

Tillegg for Addon-operator i modulformat (Helm-chart + hooks) kan legges ut for allmennheten. Vi, selskapet Flant, planlegger å publisere våre utviklinger i form av slike tillegg i løpet av sommeren. Bli med i utviklingen på GitHub (shell-operator, addon-operator), prøv å lage ditt eget tillegg basert på eksempler og dokumentasjonen, følg med på nyheter på Habré og på vår YouTube-kanal!