Önskat läge ligger i ett repo, och en agent i klustret ser till att verkligheten följer med. Argo CD och Flux är de två vanliga motorerna.
Varför ADOPT
Det avgörande är inte att deployen sker från git, det är att klustret slutar vara
ett ställe där ändringar kan uppstå utan spår. Den som vill veta vad som körs
läser ett repo i stället för att fråga någon som kör kubectl. Det ger rollback
som en revert, och det ger revisionen ett svar utan att någon behöver gräva i
loggar.
Effekten på beroenden är den jag bryr mig om: teamet kan deploya utan att någon med klusteråtkomst är inblandad. Behörigheten flyttar från människor till en maskin med ett smalt mandat.
Vad det kostar
Secrets blir omedelbart en egen fråga, och svaret (sealed secrets, en extern secret store, en operator) är alltid krångligare än att bara lägga en fil i repot. Räkna med en veckas arbete bara där.
Repostrukturen är den andra fällan. Ett repo för allt ger en flaskhals i reviewen, ett repo per tjänst ger drift i konventionerna. Välj medvetet, och skriv ner regeln, annars väljer den första personen åt alla andra.
När det är fel val
När applikationen inte kör i Kubernetes. GitOps-mönstret går att sträcka till annat, men verktygen är byggda för klustret, och sträckningen kostar mer än den ger. Deklarativ infrastruktur i en vanlig pipeline räcker då.