Läs på engelska

Dela via

Arbetsbelastningshantering i en miljö med flera kluster med GitOps

  • Artikel

Att utveckla moderna molnbaserade program omfattar ofta att skapa, distribuera, konfigurera och främja arbetsbelastningar i en grupp Kubernetes-kluster. Med den ökande mångfalden av Kubernetes-klustertyper och de olika programmen och tjänsterna kan processen bli komplex och oberäknad. Företagsorganisationer kan bli mer framgångsrika i dessa insatser genom att ha en väldefinierad struktur som organiserar människor och deras aktiviteter och med hjälp av automatiserade verktyg.

Den här artikeln beskriver ett typiskt affärsscenario där du beskriver de berörda personas och stora utmaningar som organisationer ofta står inför när de hanterar molnbaserade arbetsbelastningar i en miljö med flera kluster. Det föreslår också ett arkitekturmönster som kan göra den här komplexa processen enklare, observerbar och mer skalbar.

Scenarioöversikt

Den här artikeln beskriver en organisation som utvecklar molnbaserade program. Alla program behöver en beräkningsresurs att arbeta med. I den molnbaserade världen är den här beräkningsresursen ett Kubernetes-kluster. En organisation kan ha ett enda kluster eller, vanligare, flera kluster. Därför måste organisationen bestämma vilka program som ska fungera med vilka kluster. Med andra ord måste de schemalägga programmen mellan kluster. Resultatet av det här beslutet, eller schemaläggningen, är en modell av det önskade tillståndet för klustren i deras miljö. Med det på plats måste de på något sätt leverera program till de tilldelade klustren så att de kan omvandla önskat tillstånd till verkligheten, eller med andra ord stämma av det.

Varje program genomgår en livscykel för programvaruutveckling som främjar den till produktionsmiljön. Ett program skapas, distribueras till Dev-miljön, testas och befordras till fasmiljö, testas och levereras slutligen till produktion. För ett molnbaserat program kräver och riktar programmet in sig på olika Kubernetes-klusterresurser under hela livscykeln. Dessutom kräver program normalt att kluster tillhandahåller vissa plattformstjänster, till exempel Prometheus och Fluentbit, och infrastrukturkonfigurationer, till exempel nätverksprinciper.

Beroende på programmet kan det finnas en stor mångfald av klustertyper som programmet distribueras till. Samma program med olika konfigurationer kan finnas i ett hanterat kluster i molnet, i ett anslutet kluster i en lokal miljö, i en grupp kluster på halvanslutna gränsenheter på fabrikslinjer eller militära drönare och i ett luftgapat kluster på ett rymdskepp. En annan komplexitet är att kluster i tidiga livscykelfaser som Dev och QA normalt hanteras av utvecklaren, medan avstämning till faktiska produktionskluster kan hanteras av organisationens kunder. I det senare fallet kan utvecklaren endast ansvara för att främja och schemalägga programmet mellan olika ringar.

Utmaningar i stor skala

I en liten organisation med ett enda program och bara några få åtgärder kan de flesta av dessa processer hanteras manuellt med en handfull skript och pipelines. Men för företagsorganisationer som arbetar i större skala kan det vara en verklig utmaning. Dessa organisationer producerar ofta hundratals program som riktar sig mot hundratals klustertyper, som backas upp av tusentals fysiska kluster. I dessa fall är det inte möjligt att hantera sådana åtgärder manuellt med skript.

Följande funktioner krävs för att utföra den här typen av arbetsbelastningshantering i stor skala i en miljö med flera kluster:

  • Avgränsning av problem med schemaläggning och avstämning
  • Befordran av tillståndet för flera kluster via en kedja av miljöer
  • Sofistikerad, utökningsbar och utbytbar schemaläggare
  • Flexibilitet att använda olika avstämare för olika klustertyper beroende på deras natur och anslutning
  • Plattformskonfigurationshantering i stor skala

Scenariopersonas

Innan vi beskriver scenariot ska vi klargöra vilka personer som är inblandade, vilka ansvarsområden de har och hur de interagerar med varandra.

Plattformsteam

Plattformsteamet ansvarar för att hantera de kluster som är värdar för program som produceras av programteam.

Viktiga ansvarsområden för plattformsteamet är:

  • Definiera mellanlagringsmiljöer (Dev, QA, UAT, Prod).
  • Definiera klustertyper och deras distribution mellan miljöer.
  • Etablera nya kluster.
  • Hantera infrastrukturkonfigurationer i klustren.
  • Underhålla plattformstjänster som används av program.
  • Schemalägg program och plattformstjänster i klustren.

Programteam

Programteamet ansvarar för programutvecklingslivscykeln (SDLC) för sina program. De tillhandahåller Kubernetes-manifest som beskriver hur du distribuerar programmet till olika mål. De ansvarar för att äga CI/CD-pipelines som skapar containeravbildningar och Kubernetes-manifest och främjar distributionsartefakter i olika miljösteg.

Vanligtvis har programteamet ingen kunskap om de kluster som de distribuerar till. De känner inte till strukturen i miljön för flera kluster, globala konfigurationer eller uppgifter som utförs av andra team. Programteamet förstår främst hur lyckade deras programdistribution är, vilket definieras av att pipelinestegen har slutförts.

Viktiga ansvarsområden för programteamet är:

  • Utveckla, skapa, distribuera, testa, marknadsföra, släppa och stödja deras program.
  • Underhålla och bidra till käll- och manifestlagringsplatser för sina program.
  • Definiera och konfigurera programdistributionsmål.
  • Kommunicera med plattformsteamet och begär önskade beräkningsresurser för lyckade SDLC-åtgärder.

Flöde på hög nivå

Det här diagrammet visar hur plattforms- och programteamets personer interagerar med varandra när de utför sina regelbundna aktiviteter.

Diagram som visar hur personas interagerar med varandra.

Det primära begreppet för hela den här processen är separation av problem. Det finns arbetsbelastningar, till exempel program och plattformstjänster, och det finns en plattform där dessa arbetsbelastningar körs. Programteamet tar hand om arbetsbelastningarna (vad), medan plattformsteamet fokuserar på plattformen (där).

Programteamet kör SDLC-åtgärder i sina program och främjar ändringar i olika miljöer. De vet inte vilka kluster deras program distribueras på i varje miljö. I stället fungerar programteamet med begreppet distributionsmål, som helt enkelt är en namngiven abstraktion i en miljö. Distributionsmål kan till exempel vara integrering på Dev, funktionella tester och prestandatester på qa, tidiga användare, externa användare på Prod och så vidare.

Programteamet definierar distributionsmål för varje distributionsmiljö, och de vet hur de ska konfigurera sitt program och hur man genererar manifest för varje distributionsmål. Den här processen är automatiserad och finns i programmets lagringsplatser. Det resulterar i genererade manifest för varje distributionsmål som lagras i en manifestlagring, till exempel en Git-lagringsplats, Helm-lagringsplats eller OCI-lagring.

Plattformsteamet har begränsad kunskap om programmen, så de är inte involverade i programkonfigurations- och distributionsprocessen. Plattformsteamet ansvarar för plattformskluster, grupperade i klustertyper. De beskriver klustertyper med konfigurationsvärden som DNS-namn, slutpunkter för externa tjänster och så vidare. Plattformsteamet tilldelar eller schemalägger programdistributionsmål till olika klustertyper. Med det på plats bestäms programbeteendet på ett fysiskt kluster av kombinationen av konfigurationsvärdena för distributionsmål och konfigurationsvärden för klustertyp.

Plattformsteamet använder en separat plattformslagringsplats som innehåller manifest för varje klustertyp. Dessa manifest definierar de arbetsbelastningar som ska köras på varje klustertyp och vilka plattformskonfigurationsvärden som ska tillämpas. Kluster kan hämta den informationen från plattformslagringsplatsen med önskad avstämning och sedan tillämpa manifesten.

Kluster rapporterar sitt efterlevnadstillstånd med plattforms- och programlagringsplatserna till Distributionsobservabilitetshubben. Plattforms- och programteamen kan fråga den här informationen för att analysera historisk arbetsbelastningsdistribution mellan kluster. Den här informationen kan användas i instrumentpaneler, aviseringar och i distributionspipelines för att implementera progressiv distribution.

Lösningsarkitekturen

Nu ska vi ta en titt på lösningsarkitekturen på hög nivå och förstå dess primära komponenter.

Diagram som visar lösningsarkitektur.

Kontrollplan

Plattformsteamet modellerar miljön för flera kluster i kontrollplanet. Den är utformad för att vara människoorienterad och lätt att förstå, uppdatera och granska. Kontrollplanet fungerar med abstraktioner som klustertyper, miljöer, arbetsbelastningar, schemaläggningsprinciper, konfigurationer och mallar. Dessa abstraktioner hanteras av en automatiserad process som tilldelar distributionsmål och konfigurationsvärden till klustertyperna och sedan sparar resultatet på plattformens GitOps-lagringsplats. Även om det kan finnas tusentals fysiska kluster fungerar plattformslagringsplatsen på en högre nivå och grupperar klustren i klustertyper.

Huvudkravet för kontrollplanets lagring är att tillhandahålla en tillförlitlig och säker transaktionsbearbetningsfunktion i stället för att drabbas av komplexa frågor mot en stor mängd data. Olika tekniker kan användas för att lagra kontrollplansdata.

Den här arkitekturdesignen föreslår en Git-lagringsplats med en uppsättning pipelines för att lagra och främja plattformsabstraktioner mellan miljöer. Den här designen ger några fördelar:

  • Alla fördelar med GitOps-principer, till exempel versionskontroll, ändringsgodkännanden, automatisering, pull-baserad avstämning.
  • Git-lagringsplatser som GitHub tillhandahåller färdiga funktioner för förgrening, säkerhet och PR-granskning.
  • Enkel implementering av kampanjflöden med GitHub Actions-arbetsflöden eller liknande orkestratorer.
  • Du behöver inte underhålla och exponera en separat kontrollplanstjänst.

Befordran och schemaläggning

Kontrollplanets lagringsplats innehåller två typer av data:

  • Data som befordras mellan miljöer, till exempel en lista över registrerade arbetsbelastningar och olika mallar.
  • Miljöspecifika konfigurationer, till exempel inkluderade miljöklustertyper, konfigurationsvärden och schemaläggningsprinciper. Dessa data höjs inte upp eftersom de är specifika för varje miljö.

De data som ska höjas upp lagras i grenen main . Miljöspecifika data lagras i motsvarande miljögrenar, till exempel dev, qaoch prod. Att transformera data från kontrollplanet till GitOps-lagringsplatsen är en kombination av kampanj- och schemaläggningsflödena. Marknadsföringsflödet flyttar ändringen över miljöerna vågrätt. schemaläggningsflödet schemalägger och genererar manifest lodrätt för varje miljö.

Diagram som visar befordransflöde.

En incheckning till grenen main startar befordransflödet som utlöser schemaläggningsflödet för varje miljö en i taget. Schemaläggningsflödet tar basmanifesten från main, tillämpar konfigurationsvärden från en som motsvarar den här miljögrenen och skapar en PR med de resulterande manifesten på plattformens GitOps-lagringsplats. När distributionen i den här miljön har slutförts och slutförts fortsätter kampanjflödet och utför samma procedur i nästa miljö. I varje miljö höjer flödet upp samma inchecknings-ID för grenen main och ser till att innehållet från main går till nästa miljö först efter en lyckad distribution till den tidigare miljön.

En incheckning till miljögrenen på kontrollplanets lagringsplats startar schemaläggningsflödet för den här miljön. Du kanske till exempel har konfigurerat cosmo-db-slutpunkten i QA-miljön. Du vill bara uppdatera QA-grenen på plattformens GitOps-lagringsplats utan att röra något annat. Schemaläggningen main tar innehållet, som motsvarar det senaste inchecknings-ID:t som har befordrats till den här miljön, tillämpar konfigurationer och höjer upp de resulterande manifesten till gitops-grenen för plattformen.

Arbetsbelastningstilldelning

På plattformens GitOps-lagringsplats representeras varje arbetsbelastningstilldelning till en klustertyp av en mapp som innehåller följande objekt:

  • Ett dedikerat namnområde för den här arbetsbelastningen i den här miljön i ett kluster av den här typen.
  • Plattformsprinciper som begränsar arbetsbelastningsbehörigheter.
  • Konsoliderad plattformskonfiguration mappar med de värden som arbetsbelastningen kan använda.
  • Stämma av resurser som pekar på en lagring av arbetsbelastningsmanifest där de faktiska arbetsbelastningsmanifesten eller Helm-diagram lagras. Till exempel Flux GitRepository och Flux Kustomization, ArgoCD Application, Zarf-beskrivningar och så vidare.

Klustertyper och avstämningar

Varje klustertyp kan använda en annan avstämare (till exempel Flux, ArgoCD, Zarf, Rancher Fleet och så vidare) för att leverera manifest från Lagring av arbetsbelastningsmanifest. Klustertypsdefinition refererar till en avstämning som definierar en samling manifestmallar. Schemaläggaren använder dessa mallar för att skapa avstämningsresurser, till exempel Flux GitRepository och Flux Kustomization, ArgoCD Application, Zarf-beskrivningar och så vidare. Samma arbetsbelastning kan schemaläggas till klustertyperna, som hanteras av olika avstämare, till exempel Flux och ArgoCD. Schemaläggaren genererar Flux GitRepository och Flux Kustomization för ett kluster och ArgoCD-program för ett annat kluster, men båda pekar på samma arbetsbelastningsmanifestlagring som innehåller arbetsbelastningsmanifesten.

Plattformstjänster

Plattformstjänster är arbetsbelastningar (till exempel Prometheus, NGINX, Fluentbit och så vidare) som underhålls av plattformsteamet. Precis som alla arbetsbelastningar har de sina källlagringsplatser och manifestlagring. Källlagringsplatserna kan innehålla pekare till externa Helm-diagram. CI/CD-pipelines hämtar diagrammen med containrar och utför nödvändiga säkerhetsgenomsökningar innan de skickas till manifestlagringen, varifrån de är avstämda till klustren.

Distributionsobservabilitetshubben

Distributionsobservabilitetshubben är en central lagringsplats som är enkel att köra frågor mot med komplexa frågor mot en stor mängd data. Den innehåller distributionsdata med historisk information om arbetsbelastningsversioner och deras distributionstillstånd i kluster. Kluster registrerar sig i lagringen och uppdaterar sin efterlevnadsstatus med GitOps-lagringsplatserna. Kluster fungerar endast på git-incheckningsnivå. Information på hög nivå, till exempel programversioner, miljöer och klustertypsdata, överförs till den centrala lagringen från GitOps-lagringsplatserna. Den här informationen på hög nivå korreleras i den centrala lagringen med de incheckningskompatibilitetsdata som skickas från klustren.

Koncept för plattformskonfiguration

Avgränsning av problem

Programbeteendet på ett distributionsmål bestäms av konfigurationsvärden. Konfigurationsvärdena är dock inte desamma. Dessa värden tillhandahålls av olika personer vid olika tidpunkter i programmets livscykel och har olika omfång. I allmänhet finns det program- och plattformskonfigurationer.

Programkonfigurationer

Programkonfigurationer som tillhandahålls av programutvecklarna abstraheras bort från distributionsmålinformationen. Normalt är programutvecklare inte medvetna om värdspecifik information, till exempel vilka värdar programmet ska distribueras till eller hur många värdar det finns. Men programutvecklarna känner till en kedja av miljöer och ringar som programmet befordras genom på väg till produktion.

Ett program kan distribueras flera gånger i varje miljö för att spela upp olika roller. Till exempel kan samma program fungera som en dispatcher och som en exporter. Programutvecklarna kanske vill konfigurera programmet på olika sätt för olika användningsfall. Om programmet till exempel körs som en dispatcher i en QA-miljö bör det konfigureras på det här sättet oavsett den faktiska värden. Konfigurationsvärdena för den här typen tillhandahålls vid utvecklingstillfället när programutvecklarna skapar distributionsbeskrivningar/manifest för olika miljöer/ringar och programroller.

Plattformskonfigurationer

Förutom konfigurationer för utvecklingstid behöver ett program ofta plattformsspecifika konfigurationsvärden som slutpunkter, taggar eller hemligheter. Dessa värden kan vara olika på varje värd där programmet distribueras. De distributionsbeskrivningar/manifest som skapats av programutvecklarna refererar till de konfigurationsobjekt som innehåller dessa värden, till exempel konfigurationskartor eller hemligheter. Programutvecklare förväntar sig att dessa konfigurationsobjekt finns på värden och är tillgängliga för programmet att använda. Vanligtvis tillhandahålls dessa objekt och deras värden av ett plattformsteam. Beroende på organisationen kan plattformsteamets persona säkerhetskopieras av olika avdelningar/personer, till exempel IT Global, Site IT, Utrustningsägare och så vidare.

Programutvecklarnas och plattformsteamets problem är helt åtskilda. Programutvecklarna fokuserar på programmet. de äger och konfigurerar den. På samma sätt äger och konfigurerar plattformsteamet plattformen. Det viktigaste är att plattformsteamet inte konfigurerar program, de konfigurerar miljöer för program. I princip tillhandahåller de miljövariabelvärden som programmen ska använda.

Plattformskonfigurationer består ofta av vanliga konfigurationer som är irrelevanta för de program som använder dem och programspecifika konfigurationer som kan vara unika för varje program.

Diagram som visar program- och plattformskonfigurationer.

Konfigurationsschema

Även om plattformsteamet kan ha begränsad kunskap om programmen och hur de fungerar, vet de vilken plattformskonfiguration som krävs för att finnas på målvärden. Den här informationen tillhandahålls av programutvecklarna. De anger vilka konfigurationsvärden deras program behöver, deras typer och begränsningar. Ett sätt att definiera det här kontraktet är att använda ett JSON-schema. Till exempel:

JSON 
{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "patch-to-core Platform Config Schema",
    "description": "Schema for platform config",
    "type": "object",
    "properties": {
      "ENVIRONMENT": {
      "type": "string",
      "description": "Environment Name"
      },
      "TimeWindowShift": {
      "type": "integer",
      "description": "Time Window Shift"
      },
      "QueryIntervalSec": {
      "type": "integer",
      "description": "Query Interval Sec"
      },
      "module": {
      "type": "object",
      "description": "module",
      "properties": {
        "drop-threshold": { "type": "number" }
      },
      "required": ["drop-threshold"]      
      }
    },
      "required": [
        "ENVIRONMENT",
        "module"
      ]              
    }

Den här metoden är välkänd i utvecklarcommunityn, eftersom JSON-schemat används av Helm för att definiera de möjliga värden som ska anges för ett Helm-diagram.

Ett formellt kontrakt möjliggör också automatisering. Plattformsteamet använder kontrollplanet för att ange konfigurationsvärdena. Kontrollplanet analyserar vilka program som ska distribueras på en värd. Den använder konfigurationsscheman för att ge råd om vilka värden som ska tillhandahållas av plattformsteamet. Kontrollplanet består av konfigurationsvärden för varje programinstans och validerar dem mot schemat för att se om alla värden finns på plats.

Kontrollplanet kan utföra validering i flera steg vid olika tidpunkter. Kontrollplanet validerar till exempel ett konfigurationsvärde när det tillhandahålls av plattformsteamet för att kontrollera dess typ, format och grundläggande begränsningar. Den slutgiltiga och viktigaste valideringen utförs när kontrollplanet består av alla tillgängliga konfigurationsvärden för programmet i konfigurationsögonblicksbilden. I det här läget är det bara möjligt att kontrollera förekomsten av nödvändiga konfigurationsvärden och kontrollera integritetsbegränsningar som omfattar flera värden som kommer från olika källor.

Konfigurationsdiagrammodell

Kontrollplanet består av ögonblicksbilder av konfigurationsvärden för programinstanserna på distributionsmål. Den hämtar värdena från olika konfigurationscontainrar. Relationen mellan dessa containrar kan representera en hierarki eller ett diagram. Kontrollplanet följer vissa regler för att identifiera vilka konfigurationsvärden från vilka containrar som ska hydratiseras i ögonblicksbilden av programkonfigurationen. Det är plattformsteamets ansvar att definiera konfigurationscontainrarna och upprätta regler för hydrering. Programutvecklare känner inte till den här strukturen. De är medvetna om konfigurationsvärden som ska anges, och det är inte deras problem var värdena kommer ifrån.

Metod för etikettmatchning

Ett enkelt och flexibelt sätt att implementera konfigurationssammansättning är metoden för etikettmatchning.

Diagram som visar modell för etikettmatchning av konfigurationssammansättning.

I det här diagrammet grupperar konfigurationsvärden för konfigurationscontainrar på olika nivåer, till exempel plats, linje, miljö och region. Beroende på organisationen kan värdena i dessa containrar tillhandahållas av olika personer, till exempel IT Global, Site IT, Utrustningsägare eller bara plattformsteamet. Varje container är markerad med en uppsättning etiketter som definierar var värden från den här containern ska användas. Förutom konfigurationscontainrarna finns det abstraktioner som representerar ett program och en värd där programmet ska distribueras. Båda är markerade med etiketterna också. Kombinationen av programmets och värdens etiketter består av instansens etiketter. Den här uppsättningen bestämmer värdena för konfigurationscontainrar som ska hämtas till ögonblicksbilden av programkonfigurationen. Den här ögonblicksbilden levereras till värden och matas till programinstansen. Kontrollplanet itererar över containrarna och utvärderar om containerns etiketter matchar instansens etiketter. I så fall inkluderas containerns värden i den slutliga ögonblicksbilden. annars hoppas containern över. Kontrollplanet kan konfigureras med olika strategier för att åsidosätta och slå samman för komplexa objekt och matriser.

En av de största fördelarna med den här metoden är skalbarhet. Strukturen för konfigurationscontainrar abstraheras bort från programinstansen, som inte riktigt vet var värdena kommer ifrån. På så sätt kan plattformsteamet enkelt manipulera konfigurationscontainrarna, introducera nya nivåer och konfigurationsgrupper utan att konfigurera om hundratals programinstanser.

Mallanvändning

Kontrollplanet består av konfigurationsögonblicksbilder för varje programinstans på varje värd. De olika programmen, värdarna, de underliggande teknikerna och hur program distribueras kan vara mycket breda. Dessutom kan samma program distribueras helt annorlunda på vägen från utvecklingsmiljöer till produktionsmiljöer. Kontrollplanets problem är att hantera konfigurationer, inte att distribuera. Den bör vara agnostisk från den underliggande program-/värdtekniken och generera konfigurationsögonblicksbilder i ett lämpligt format för varje fall (till exempel en Kubernetes-konfigurationskarta, egenskapsfil, Symphony-katalog eller annat format).

Ett alternativ är att tilldela olika mallar till olika värdtyper. Dessa mallar används av kontrollplanet när det genererar konfigurationsögonblicksbilder för de program som ska distribueras på värden. Det skulle vara bra att tillämpa en standardmetod för mallning, som är välkänd i utvecklarcommunityn. Följande mallar kan till exempel definieras med Go-mallar, som används i stor utsträckning i hela branschen:

YAML 
# Standard Kubernetes config map
apiVersion: v1
kind: ConfigMap
metadata:
  name: platform-config
  namespace: {{ .Namespace}}
data:
{{ toYaml .ConfigData | indent 2}}
YAML 
# Symphony catalog object
apiVersion: federation.symphony/v1
kind: Catalog
metadata:
  name: platform-config
  namespace: {{ .Namespace}}
spec:  
  type: config
  name: platform-config
  properties:
{{ toYaml .ConfigData | indent 4}}
YAML 
# JSON file
{{ toJson .ConfigData}}

Sedan tilldelar vi dessa mallar som värd för A, B respektive C. Förutsatt att ett program med samma konfigurationsvärden håller på att distribueras till alla tre värdarna genererar kontrollplanet tre olika konfigurationsögonblicksbilder för varje instans:

YAML 
# Standard Kubernetes config map
apiVersion: v1
kind: ConfigMap
metadata:
  name: platform-config
  namespace: line1
data:
  FACTORY_NAME: Atlantida
  LINE_NAME_LOWER: line1
  LINE_NAME_UPPER: LINE1
  QueryIntervalSec: "911"
YAML 
# Symphony catalog object
apiVersion: federation.symphony/v1
kind: Catalog
metadata:
  name: platform-config
  namespace: line1
spec:  
  type: config
  name: platform-config
  properties:
    FACTORY_NAME: Atlantida
    LINE_NAME_LOWER: line1
    LINE_NAME_UPPER: LINE1
    QueryIntervalSec: "911"
JSON 
{
 "FACTORY_NAME" : "Atlantida",
 "LINE_NAME_LOWER" : "line1",
 "LINE_NAME_UPPER": "LINE1",
 "QueryIntervalSec": "911"
}

Konfigurationslagring

Kontrollplanet fungerar med konfigurationscontainrar som grupperar konfigurationsvärden på olika nivåer i en hierarki eller ett diagram. Dessa containrar bör lagras någonstans. Den mest uppenbara metoden är att använda en databas. Det kan vara etcd, relationell, hierarkisk eller en grafdatabas, vilket ger den mest flexibla och robusta upplevelsen. Databasen ger möjlighet att noggrant spåra och hantera konfigurationsvärden på nivån för varje enskild konfigurationscontainer.

Förutom de viktigaste funktionerna, till exempel lagring och möjligheten att köra frågor mot och manipulera konfigurationsobjekten effektivt, bör det finnas funktioner som rör ändringsspårning, godkännanden, kampanjer, återställningar, versionsjäxor och så vidare. Kontrollplanet kan implementera allt det ovanpå en databas och kapsla in allt i en monolitisk hanterad tjänst.

Du kan också delegera den här funktionen till Git för att följa konceptet "konfiguration som kod". Kalypso, som är en Kubernetes-operator, behandlar till exempel konfigurationscontainrar som anpassade Kubernetes-resurser, som i huvudsak lagras i etcd-databasen. Även om kontrollplanet inte dikterar det är det vanligt att komma från konfigurationsvärden på en Git-lagringsplats och tillämpa alla fördelar som det ger direkt. Sedan levereras konfigurationsvärdena en Kubernetes etcd-lagring med en GitOps-operator där kontrollplanet kan arbeta med dem för att utföra kompositionerna.

Hierarki för Git-lagringsplatser

Det är inte nödvändigt att ha en enda Git-lagringsplats med konfigurationsvärden för hela organisationen. En sådan lagringsplats kan bli en flaskhals i stor skala, med tanke på de olika "plattformsteamets" personas, deras ansvarsområden och deras åtkomstnivåer. I stället kan du använda GitOps-operatorreferenser, till exempel Flux GitRepository och Flux Kustomization, för att skapa en lagringsplatshierarki och eliminera friktionspunkterna:

Diagram som visar en Git-lagringsplatshierarki.

Konfigurationsversioner

När programutvecklare introducerar en ändring i programmet skapar de en ny programversion. På samma sätt leder ett nytt plattformskonfigurationsvärde till en ny version av konfigurationsögonblicksbilden. Versionshantering möjliggör spårning av ändringar, explicita distributioner och återställningar.

En viktig punkt är att ögonblicksbilder av programkonfigurationen är versionshanterade oberoende av varandra. En enda konfigurationsvärdeändring på global nivå eller platsnivå skapar inte nödvändigtvis nya versioner av alla ögonblicksbilder av programkonfigurationen. det påverkar endast de ögonblicksbilder där det här värdet är hydratiserat. Ett enkelt och effektivt sätt att spåra det är att använda en hash av ögonblicksbildinnehållet som dess version. På så sätt finns det en ny version om innehållet i ögonblicksbilden har ändrats på grund av att något har ändrats i de globala konfigurationerna. Den här nya versionen är ett ämne som ska tillämpas manuellt eller automatiskt. I vilket fall som helst är detta en spårningsbar händelse som kan återställas om det behövs.

Nästa steg