Att förbereda en Kubernetes-kluster är enkelt och bekvämt? Vi presenterar addon-operatorn

I takt med shell-operator introducerar vi hans äldre bror — addon-operator. Detta är ett Open Source-projekt som används för att installera systemkomponenter i Kubernetes-klustret, som vi kan kalla med ett gemensamt ord — tillägg.

Varför överhuvudtaget några tillägg?

Det är ingen hemlighet att Kubernetes inte är en färdig produkt allt-i-ett, och för att bygga en 'vuxen' kluster behövs olika tillägg. Addon-operator hjälper till att installera, konfigurera och hålla dessa tillägg uppdaterade.

Behovet av ytterligare komponenter i klustret redovisas i rapporten från kollegan driusha. Kort sagt, situationen med Kubernetes just nu är sådan att för enkel installation för att 'leka' kan man klara sig med de inbyggda komponenterna, för utvecklare och testning kan man lägga till Ingress, men för en fullständig installation, som kan sägas 'er produktion är klar', behöver man lägga till ett dussin olika tillägg: något för övervakning, något för loggar, att inte glömma ingress och cert-manager, att avsätta grupper av noder, lägga till nätverkspolicyer, krydda med sysctl-inställningar och pod autoscaler...

Vad är specifikationen för att arbeta med dem?

Som erfarenhet visar, är det inte bara en installation som krävs. För att arbeta bekvämt med klustret måste tillägg uppdateras, inaktiveras (ta bort från klustret), och något vill man testa innan installationen i produktionsklustret.

Så, kanske räcker det med Ansible? Kanske. Men fullständiga tillägg lever vanligtvis inte utan inställningar. Dessa inställningar kan variera beroende på klusteralternativet (aws, gce, azure, bare-metal, do, …). Vissa inställningar kan inte anges i förväg — de behöver hämtas från klustret. Och klustret är inte statiskt: för vissa inställningar måste man övervaka förändringar. Och här räcker inte Ansible: man behöver ett program som lever i klustret, dvs. Kubernetes Operator.

De som har provat att arbeta med shell-operator, kommer att säga att uppgifterna för att installera och uppdatera tillägg och följa inställningarna helt klart kan lösas med hjälp av hooks för shell-operator. Man kan skriva ett skript som gör ett hypotetiskt kubectl apply och övervaka, till exempel, ConfigMap där inställningar kommer att lagras. Ungefär så här är det genomfört i addon-operator.

Hur är detta organiserat i addon-operator?

När vi skapade denna nya lösning utgick vi från följande principer:

• Tilläggsinstallatören ska stödja mallning och deklarativ konfiguration. Vi använder inte magiska skript för att installera tillägg. Addon-operator använder Helm för att installera tillägg. För installation behövs en chart och ange de värden som ska användas för konfiguration.
• Inställningar kan genereras vid installation, de kan hämtas från klustret, eller få uppdateringar, genom att följa klustrets resurser. Dessa operationer kan implementeras med hjälp av hooks.
• Inställningar kan lagras i klustret. För att lagra inställningarna i klustret skapas en ConfigMap/addon-operator, och Addon-operator övervakar ändringar i denna ConfigMap. Addon-operator ger hooks åtkomst till inställningarna genom enkla överenskommelser.
• Tillägget beror på inställningarna. Om inställningarna ändras, rullar Addon-operator ut Helm-chartet med nya värden. Kombinationen av Helm-charten, värdena för den och hooks kallar vi för en modul (se mer nedan).
• Staging. Det finns inga magiska release-skript. Uppdateringsmekanismen är lik den för en vanlig applikation — samla tillägg och addon-operator i en bild, tagga och rulla ut.
• Resultatkontroll. Addon-operator kan ge metrics till Prometheus.

Vad är ett tillägg i addon-operator?

Ett tillägg kan ses som allt som lägger till nya funktioner i klustret. Till exempel, installation av Ingress — ett utmärkt exempel på ett tillägg. Det kan vara vilken operator eller controller som helst med sin egen CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. Eller något litet men som förenklar drift — exempelvis en secret copier som kopierar registry-hemligheter till nya namnrymder, eller en sysctl tuner som justerar sysctl-parametrar på nya noder.

För att implementera tillägg tillhandahåller Addon-operator flera koncept:

• Helm-chart används för att installera olika mjukvaror i klustret — till exempel Prometheus, Grafana, nginx-ingress. Om en komponent har ett Helm-chart, blir det mycket enkelt att installera det med Addon-operator.
• Värdeslager. Helm-charts har vanligtvis många olika inställningar som kan förändras över tid. Addon-operator stöder lagring av dessa inställningar och kan övervaka deras ändringar för att reinstallera Helm-charten med nya värden.
• Hooks — är exekverbara filer som Addon-operator kör vid händelser och ger åtkomst till värdeförrådet. Hook kan övervaka ändringar i klustret och uppdatera värdena i värdeförrådet. Det vill säga, med hjälp av hooks kan man göra discovery för att samla värden från klustret vid uppstart eller enligt schema, eller så kan man göra continous discovery, och samla värden från klustret vid ändringar i klustret.
• Modul — är en kombination av Helm-chart, värdeförråd och hooks. Moduler kan aktiveras och deaktiveras. Att deaktivera en modul innebär att ta bort alla versioner av Helm-charten. Moduler kan dynamiskt aktivera sig själva, till exempel om alla nödvändiga moduler är aktiverade eller om discovery i hooks har hittat nödvändiga parametrar — detta görs med hjälp av ett hjälpskript med namnet enabled.
• Globala hooks. Detta är hooks 'på egen hand', de ingår inte i moduler och har åtkomst till det globala värdeförrådet, vars värden är tillgängliga för alla hooks i moduler.

Hur fungerar dessa delar tillsammans? Låt oss titta på en bild från dokumentationen:

Det finns två scenarier:

1. Det globala hooket körs vid en händelse — till exempel vid ändring av resurser i klustret. Detta hook hanterar ändringar och skriver nya värden i det globala värdeförrådet. Addon-operator märker att det globala förrådet har ändrats och kör alla moduler. Varje modul bestämmer via sina hooks om den behöver aktiveras och uppdaterar sitt värdeförråd. Om modulen är aktiverad, kör Addon-operator installerar Helm-charten. Helm-charten har åtkomst till värden från modulens förråd och det globala förrådet.
2. Det andra scenariot är enklare: modulens hook körs vid en händelse och ändrar värden i modulens värdeförråd. Addon-operator märker detta och kör Helm-charten med uppdaterade värden.

Ett tillägg kan implementeras i form av en enda hook eller som en enda Helm-chart, eller även som flera beroende moduler — detta beror på komplexiteten hos den komponent som ska installeras i klustret och den önskade nivån av flexibilitet i inställningarna. Till exempel, i förrådet (/examples) finns tillägget sysctl-tuner, som implementeras både som en enkel modul med hook och Helm-chart, samt med användning av ett värdeförråd, vilket gör det möjligt att lägga till inställningar genom att redigera ConfigMap.

Leverans av uppdateringar

Några ord om organisationen av uppdateringar av komponenter som Addon-operator installerar.

För att köra Addon-operator i klustret måste man samla en bild med tillägg i form av hook-filer och Helm-diagram, lägga till binärfilen addon-operator och allt som behövs för hookar: bash, kubectl, jq, python och så vidare. Därefter kan denna bild distribueras i klustret som en vanlig applikation och du kommer troligtvis att vilja organisera någon typ av taggningsschema. Om det finns få kluster kan samma tillvägagångssätt som med applikationer fungera: ny version, nya uppdateringar, gå igenom alla kluster och justera bildnamnet i Pod:arna. Men i fallet med distribution till ett betydande antal kluster passar konceptet självuppdatering från kanalen oss bättre.

Så här är det ordnat:

• En kanal är i princip en identifierare som kan ställas in på valfritt sätt (till exempel dev/stage/ea/stable).
• Kanalnamnet är taggen för bilden. När uppdateringar behöver distribueras till kanalen, samlas en ny bild och taggas med kanalens namn.
• När en ny bild dyker upp i registret, startar Addon-operator om och körs med den nya bilden.

Detta är inte en bästa praxis, vilket beskrivs i dokumentationen för Kubernetes. Så här rekommenderas det inte att göras, men det handlar om en vanlig applikation som lever i ett kluster.I fallet med Addon-operator är applikationen en serie distributioner spridda över kluster, och självuppdatering underlättar verkligen livet.

Kanalernas funktioner hjälper också vid testning: om det finns ett hjälpkkluster kan det ställas in på kanalen stage och distribuera uppdateringar till det innan de går till kanalerna ea och stable. Om det uppstår ett fel med klustret på kanalen ea kan det bytas till stable, medan problemet med detta kluster undersöks. Om klustret tas ur aktivt stöd, byts det till sin 'frysta' kanal — till exempel, freeze-2019-03-20.

Förutom uppdateringar av hookar och Helm-diagram kan det också behövas uppdatera en tredjeparts komponent. Till exempel, om du upptäckte ett fel i den hypotetiska node-exporter och även kommit på hur man kan patcha det. Sedan öppnade du en PR och väntar på en ny version, så att du kan gå igenom alla kluster och öka bildversionen. För att inte behöva vänta en osäker tid kan du samla din egen node-exporter och byta till den tills PR:n har godkänts.

I allmänhet kan detta göras utan Addon-operator, men med Addon-operator blir modulen för att installera node-exporter synlig i ett och samma katalog, Dockerfile för att bygga din egen bild kan hållas här, och alla deltagare i processen får en enklare förståelse för vad som händer… Om det finns flera kluster blir det lättare att både testa din PR och att rulla ut en ny version!

Denna organisation för att uppdatera komponenter fungerar framgångsrikt för oss, men man kan också implementera vilken annan lämplig mekanism som helst — för i detta fall är Addon-operator en enkel binärfil.

Slutsats

Principerna implementerade i Addon-operator gör det möjligt att bygga en transparent process för skapande, testning, installation och uppdatering av tillägg i klustret, liknande processerna för utveckling av vanliga applikationer.

Tillägg för Addon-operator i modulformat (Helm-chart + hooks) kan publiceras för allmänheten. Vi, företaget Flant, planerar att under sommaren göra våra bidrag tillgängliga i form av sådana tillägg. Delta i utvecklingen på GitHub (shell-operator, addon-operator), försök göra ditt eget tillägg baserat på exempel och dokumentationen, håll utkik efter nyheter på Habré och på vår YouTube-kanal!

P.S.

Läs även i vår blogg:

• «Utökar och kompletterar Kubernetes (översikt och videoföreläsning)»;
• «Presenterar shell-operator: att skapa operatörer för Kubernetes har blivit ännu enklare».

Källa: habr.com