Efter vi presenterar hans äldre bror - . Detta är ett Open Source-projekt som används för att installera systemkomponenter i ett Kubernetes-kluster, som kan kallas tillägg.
Varför några tillägg överhuvudtaget?
Det är ingen hemlighet att Kubernetes inte är en färdig allt-i-ett-produkt, och för att bygga ett "vuxet" kluster behöver du olika tillägg. Addon-operator hjälper dig att installera, konfigurera och hålla dessa tillägg uppdaterade.
Behovet av ytterligare komponenter i klustret beskrivs i kollegor . Kort sagt, situationen med Kubernetes för tillfället är sådan att för en enkel "lek runt" installation kan du klara dig med komponenterna ur lådan, för utvecklare och testning kan du lägga till Ingress, men för en fullständig installation, ungefär vilken du kan säga "din produktion är klar", du måste lägga till med ett dussin olika tillägg: något för övervakning, något för loggning, glöm inte ingress och cert-manager, välj grupper av noder, lägg till nätverkspolicyer, säsong med sysctl och pod autoscaler-inställningar...
Vad är det för detaljer med att arbeta med dem?
Som praxis visar är frågan inte begränsad till en installation. För att fungera bekvämt med klustret måste tillägg uppdateras, inaktiveras (ta bort från klustret), och du vill testa några innan du installerar dem i produktionsklustret.
Så, det kanske räcker med Ansible här? Kanske. Men I allmänhet lever inte fullfjädrade tillägg utan inställningar. Dessa inställningar kan skilja sig beroende på klustervariant (aws, gce, azure, bare-metal, do, ...). Vissa inställningar kan inte anges i förväg, de måste hämtas från klustret. Och klustret är inte statiskt: för vissa inställningar måste du övervaka ändringar. Och här saknas redan Ansible: du behöver ett program som lever i ett kluster, d.v.s. Kubernetes-operatör.
De som provade det på jobbet , kommer de att säga att uppgifterna med att installera och uppdatera tillägg och övervakningsinställningar helt kan lösas med för skal-operatör. Du kan skriva ett manus som gör en villkorlig kubectl apply och övervaka till exempel ConfigMap, där inställningarna kommer att lagras. Detta är ungefär vad som är implementerat i addon-operator.
Hur är detta organiserat i addon-operator?
När vi skapade en ny lösning utgick vi från följande principer:
- Tilläggsinstallationsprogrammet måste stödja mallar och deklarativ konfiguration. Vi gör inte magiska skript som installerar tillägg. Addon-operator använder Helm för att installera tillägg. För att installera måste du skapa ett diagram och välja de värden som kommer att användas för konfigurationen.
- Inställningar kan vara generera vid installation, de kan vara få från klustretEller få uppdateringar, övervakning av klusterresurser. Dessa operationer kan implementeras med hjälp av krokar.
- Inställningar kan vara lagra i ett kluster. För att lagra inställningar i klustret skapas en ConfigMap/addon-operator och Addon-operatorn övervakar ändringar av denna ConfigMap. Addon-operator ger krokar tillgång till inställningar med enkla konventioner.
- Tillägg beror på inställningar. Om inställningarna har ändrats, rullar Addon-operatören ut styrdiagrammet med nya värden. Vi kallade kombinationen av Helm-diagrammet, värden för det och krokar för en modul (se nedan för mer information).
- Iscensättning. Det finns inga magiska utgivningsskript. Uppdateringsmekanismen liknar en vanlig applikation - samla tillägg och tilläggsoperatörer i en bild, tagga dem och rulla ut dem.
- Resultatkontroll. Addon-operator kan tillhandahålla mätvärden för Prometheus.
Vad är padding i addon-operator?
Ett tillägg kan betraktas som allt som lägger till nya funktioner till klustret. Till exempel är att installera Ingress ett bra exempel på ett tillägg. Detta kan vara vilken operatör eller kontroll som helst med sin egen CRD: prometheus-operatör, cert-manager, kube-controller-manager, etc. Eller något litet, men lättare att använda - till exempel hemlig kopiator, som kopierar registerhemligheter till nya namnområden, eller sysctl-tuner, som konfigurerar sysctl-parametrar på nya noder.
För att implementera tillägg tillhandahåller Addon-operator flera koncept:
- Rordiagram används för att installera olika programvaror i klustret - till exempel Prometheus, Grafana, nginx-ingress. Om den nödvändiga komponenten har ett Helm-diagram kommer det att vara mycket enkelt att installera den med Addon-operator.
- Värdelagring. Roderdiagram har vanligtvis många olika inställningar som kan ändras över tiden. Addon-operatören stöder lagring av dessa inställningar och kan övervaka deras ändringar för att installera om Helm-diagrammet med nya värden.
- Krokar är körbara filer som Addon-operatören kör på händelser och som kommer åt värdelagret. Kroken kan övervaka förändringar i klustret och uppdatera värdena i värdelagret. De där. Med hjälp av krokar kan du göra upptäckt för att samla in värden från klustret vid start eller enligt ett schema, eller så kan du göra kontinuerlig upptäckt, samla in värden från klustret baserat på förändringar i klustret.
- Modul är en kombination av ett Helm-diagram, en värdebutik och krokar. Moduler kan aktiveras eller inaktiveras. Att inaktivera en modul innebär att ta bort alla Helm chart-utgåvor. Moduler kan aktivera sig själva dynamiskt, till exempel om alla moduler de behöver är aktiverade eller om upptäckten har hittat de nödvändiga parametrarna i krokarna - detta görs med hjälp av ett aux-aktiverat skript.
- Globala krokar. Dessa är krokar "på egen hand", de ingår inte i moduler och har tillgång till ett globalt värdelager, vars värden är tillgängliga för alla krokar i moduler.
Hur fungerar dessa delar tillsammans? Låt oss titta på bilden från dokumentationen:
Det finns två arbetsscenarier:
- Den globala kroken triggas av en händelse - till exempel när en resurs i klustret ändras. Denna krok bearbetar ändringarna och skriver de nya värdena till den globala värdebutiken. Addon-operatören märker att den globala lagringen har ändrats och startar alla moduler. Varje modul, med hjälp av sina krokar, avgör om den behöver aktiveras och uppdaterar dess värdelager. Om modulen är aktiverad startar Addon-operatören installationen av Helm-diagrammet. I det här fallet har Helm-diagrammet tillgång till värden från modullagringen och från den globala lagringen.
- Det andra scenariot är enklare: en modulhook triggas av en händelse och ändrar värden i modulens värdelager. Addon-operatören märker detta och startar Helm-diagrammet med uppdaterade värden.
Tillägget kan implementeras som en enda krok, eller som ett Helm-diagram, eller även som flera beroende moduler - detta beror på komplexiteten hos den komponent som installeras i klustret och på den önskade nivån av konfigurationsflexibilitet. Till exempel, i förvaret () det finns ett sysctl-tuner-tillägg, som är implementerat både som en enkel modul med en krok och ett Helm-diagram, och genom att använda värdearkivet, vilket gör det möjligt att lägga till inställningar genom att redigera ConfigMap.
Leverans av uppdateringar
Några ord om att organisera komponentuppdateringar som Addon-operator installerar.
För att köra Addon-operator i ett kluster behöver du bygga en bild med tillägg i form av krok- och Helm-diagramfiler, lägg till en binär fil addon-operator och allt du behöver för krokar: bash, kubectl, jq, python etc. Sedan kan den här bilden rullas ut till klustret som en vanlig applikation, och troligen kommer du att vilja organisera ett eller annat taggningsschema. Om det finns få kluster kan samma tillvägagångssätt som med applikationer vara lämpligt: ny release, ny version, gå till alla kluster och korrigera bilden av Pods. Men i fallet med en utrullning till ett betydande antal kluster var konceptet med självuppdatering från en kanal mer lämpligt för oss.
Så här gör vi:
- En kanal är i huvudsak en identifierare som kan ställas in på vad som helst (till exempel dev/stage/ea/stable).
- Kanalnamnet är bildtaggen. När du behöver lansera uppdateringar till en kanal, sätts en ny bild ihop och taggas med kanalnamnet.
- När en ny bild dyker upp i registret, startas Addon-operator om och startas med den nya bilden.
Detta är inte bästa praxis, som skrivet i . Det rekommenderas inte att göra detta, men vi pratar om en vanlig applikation som bor i samma kluster. När det gäller Addon-operator, är en applikation en mängd distributioner utspridda över kluster, och självuppdatering hjälper mycket och gör livet enklare.
Kanaler hjälper och i testning: om det finns ett extra kluster kan du konfigurera det till kanalen stage och rulla in uppdateringar i den innan den rullas ut till kanaler ea и stable. Om med ett kluster på kanalen ea ett fel inträffade kan du byta till stable, medan problemet med detta kluster undersöks. Om klustret tas ur aktivt stöd växlar det till sin "frysta" kanal - t.ex. freeze-2019-03-20.
Förutom att uppdatera krokar och roderdiagram kan du behöva uppdatering och tredjepartskomponent. Till exempel, du märkte en bugg i den villkorliga nod-exportern och kom till och med på hur du korrigerar den. Därefter öppnade du PR och väntar på att den nya versionen ska gå igenom alla kluster och öka versionen av bilden. För att inte vänta på obestämd tid kan du bygga din nod-exporter och byta till den innan du accepterar PR.
I allmänhet kan detta göras utan Addon-operator, men med Addon-operator kommer modulen för att installera node-exporter att synas i ett arkiv, Dockerfilen för att bygga din bild kan förvaras där, det blir lättare för alla deltagare i processen för att förstå vad som händer... Och om det finns flera kluster, då blir det lättare att både testa sin PR och rulla ut en ny version!
Denna organisation av komponentuppdatering fungerar framgångsrikt för oss, men vilket annat lämpligt schema som helst kan implementeras - trots allt i detta fall är Addon-operator en enkel binär fil.
Slutsats
Principerna implementerade i Addon-operator låter dig bygga en transparent process för att skapa, testa, installera och uppdatera tillägg i ett kluster, liknande utvecklingsprocesserna för vanliga applikationer.
Tillägg för Addon-operatör i modulformat (Helmdiagram + krokar) kan göras allmänt tillgängliga. Vi, företaget Flant, planerar att publicera vår utveckling i form av sådana tillägg under sommaren. Gå med i utvecklingen på GitHub (, ), försök att göra ditt eget tillägg baserat på и , vänta på nyheter om Habré och på vår !
PS
Läs även på vår blogg:
- «";
- «".
Källa: will.com