Bis hierher haben Sie den Cluster mit Befehlen gefüllt: kubectl apply in Lektion W1.2, helm upgrade in Lektion W1.4. Das geht,
solange eine Person mit Zugang zum Cluster am Rechner sitzt. Was aber, wenn die Pipeline ausliefern soll? Dann braucht die Pipeline
Zugangsdaten zum Cluster, und jede Person, die die Pipeline ändern darf, kann damit alles im Cluster ändern. Und wer sagt Ihnen in einem
halben Jahr, warum im Cluster zwei Replikate laufen, obwohl im Chart drei stehen? Jemand hat es von Hand geändert, und niemand weiß mehr, wer.
GitOps dreht das um. Der gewünschte Zustand des Clusters steht in Git, und im Cluster läuft ein Programm, das Git beobachtet und den
Cluster angleicht. In dieser Lektion richten Sie das mit Flux auf AKS ein: ein Konfigurations-Repository kladde-config, zwei Kustomizations, die
voneinander abhängen, und ein HelmRelease für das Chart aus Lektion W1.4. Danach ändern Sie den Cluster nur noch über einen Pull Request und
nehmen die Änderung mit einem Revert zurück.
Die Container-Grundlagen, die Pipeline der Kladde und verwaltete Identitäten setzt die Lektion voraus; sie stehen in den Lektionen 3.7.5 und 3.3.1. Hier geht es nur darum, was GitOps auf Kubernetes anders macht.
Die Idee: Git ist die Quelle, der Cluster zieht
Beim Push baut die Pipeline ein Image und führt am Ende kubectl apply oder helm upgrade gegen den Cluster aus. Dazu muss sie sich am
Cluster anmelden können. Beim Pull läuft im Cluster selbst ein Controller. Er liest in einem festen Abstand ein Git-Repository und
gleicht den Cluster mit dessen Inhalt ab. Microsoft beschreibt das so: Die Controller laufen im Cluster und gleichen seinen Zustand laufend mit dem
Zustand ab, der im Git-Repository steht; Flux ermöglicht reine Pull-Auslieferung, und weder das Quell-Repository noch ein anderer Cluster
braucht Zugriff auf den Cluster.
| Push (Pipeline wendet an) | Pull (Flux im Cluster) | |
|---|---|---|
| Wer hat Zugang zum Cluster? | die Pipeline, mit gespeicherten Zugangsdaten oder einer Anmeldung | nur der Controller im Cluster |
| Wo steht der Zustand? | in der Pipeline und im Cluster, nie sicher gleich | in Git; der Cluster wird angeglichen |
| Handarbeit im Cluster | bleibt unbemerkt, bis jemand sie zufällig sieht | wird beim nächsten Abgleich überschrieben oder sichtbar |
| Ein Cluster ist weg | Pipeline neu laufen lassen, hoffentlich mit denselben Werten | neuen Cluster mit derselben Konfiguration verbinden |
| Rückgängig machen | alte Pipeline-Version suchen | git revert und Pull Request |
Microsoft nennt als Vorteile unter anderem: den Zustand der Anwendungen laufend sehen, Teams trennen (wer Anwendungen schreibt, muss Kubernetes-Auslieferung nicht selbst beherrschen) und einen Cluster nach einem Absturz mit demselben Soll-Zustand neu aufbauen können.
Ein Preis gehört dazu. Die Änderung ist nicht mehr sofort da: Flux gleicht in einem Abstand ab (Voreinstellung zehn Minuten, siehe unten), und eine Änderung, die an einer Voraussetzung scheitert, scheitert im Cluster und nicht in Ihrem Terminal. Sie sehen den Fehler am Zustand der Objekte, nicht an einem Exit-Code. Das lernen Sie in den Übungen.