Fluxs Standardeinstellungen unterscheiden sich von Werkzeugen, die auf einen manuellen Sync warten. Eine Flux-Kustomization wendet nach Zeitplan an und korrigiert bei jedem Lauf Drift. Du steuerst, wie oft, was gelöscht wird, wann auf Health gewartet wird und wann pausiert wird. Diese Anleitung geht jeden Schalter anhand der Kustomization webapp aus der vorherigen Anleitung durch.

Intervalle: wie oft Flux nachsieht und anwendet

Zwei Intervalle steuern das Timing, und sie sind unabhängig voneinander:

• Das GitRepository-Intervall bestimmt, wie oft Git nach neuen Commits abgefragt wird.
• Das Kustomization-interval bestimmt, wie oft die Manifeste erneut angewendet und Drift korrigiert wird, auch wenn sich Git nicht geändert hat.

spec:
  interval: 10m
  retryInterval: 2m

retryInterval ist die Wartezeit vor einem erneuten Versuch nach einem fehlgeschlagenen Abgleich. Um sofort zu reagieren statt zu warten, löse beim Testen einen Abgleich von Hand aus:

flux reconcile kustomization webapp --with-source

--with-source aktualisiert zuerst die Git-Quelle und wendet dann an. Konfiguriere für die Produktion einen Webhook, damit Git-Pushes einen Abgleich ohne häufiges Polling auslösen (siehe die Anleitung zu Benachrichtigungen).

Pruning hinzufügen

Standardmäßig erstellt und aktualisiert Flux Ressourcen, löscht aber nichts. Wenn du ein Manifest in Git umbenennst oder entfernst, bleibt das alte Objekt im Cluster. Aktiviere das Löschen per Opt-in:

spec:
  prune: true

Zum Ausprobieren benenne das Deployment in apps/webapp/deployment.yaml von webapp in webapp-v2 um, committe und gleiche ab. Flux erstellt das neue Deployment und entfernt das alte. Flux verfolgt die angewendeten Objekte über ein Inventar und löscht daher nur Dinge, die es selbst erstellt hat. Pruning löscht echte Objekte, aktiviere es daher bewusst und sei vorsichtig bei Ressourcen, die Zustand halten.

Um ein einzelnes Objekt vor dem Pruning zu schützen, annotiere es im Manifest:

metadata:
  annotations:
    kustomize.toolkit.fluxcd.io/prune: disabled

Drift-Korrektur

Jedes Mal, wenn die Kustomization abgleicht, wendet sie den Soll-Zustand aus Git erneut an, sodass manuelle Änderungen zurückgesetzt werden. Teste es:

kubectl scale deployment webapp-v2 -n webapp --replicas=5
flux reconcile kustomization webapp
kubectl get pods -n webapp

Flux setzt das Deployment auf die zwei in Git deklarierten Replikas zurück. Es gibt keinen separaten „Self-Heal“-Schalter. Dieses Verhalten ist der Standard, und es hält Git zur einzigen Quelle der Wahrheit.

Wenn du eine temporäre Änderung von Hand machen musst, zum Beispiel beim Debuggen, pausiere zuerst Flux (nächster Abschnitt). Soll ein Objekt außerhalb von Flux verwaltet werden, annotiere es in Git:

metadata:
  annotations:
    kustomize.toolkit.fluxcd.io/reconcile: disabled

Neuere Flux-Releases (2.9) fügen außerdem Ignorier-Regeln für Server-Side-Apply-Felder hinzu, mit denen du Flux anweisen kannst, bestimmte Felder in Ruhe zu lassen, etwa eine von einem Autoscaler verwaltete Replikazahl. Die genaue Syntax für deine Version findest du in der Kustomization-Referenz.

Auf Health warten und Deployments ordnen

Standardmäßig meldet Flux Erfolg, sobald der API-Server die Manifeste akzeptiert. wait: true lässt es warten, bis die Ressourcen bereit sind, und timeout begrenzt das Warten:

spec:
  wait: true
  timeout: 2m

Nutze dependsOn, damit eine Kustomization auf eine andere wartet, zum Beispiel um einen Ingress-Controller vor den Anwendungen zu installieren, die ihn brauchen:

spec:
  dependsOn:
    - name: infrastructure

Die Abhängigkeit muss Ready sein, bevor diese Kustomization mit dem Abgleich beginnt.

Suspendieren und fortsetzen

Um den Abgleich zu pausieren, ohne etwas zu löschen:

flux suspend kustomization webapp
# manuelle Änderungen machen, debuggen, dann:
flux resume kustomization webapp

Während der Suspendierung ignoriert Flux das Objekt, und manuelle Änderungen bleiben bestehen. Das Fortsetzen löst einen Abgleich aus, der den Cluster wieder mit Git in Einklang bringt, vergiss also nicht, fortzusetzen. Suspendieren ist das Flux-Äquivalent dazu, die Automatisierung für eine Umgebung auszuschalten.

Sicher zurückrollen

Flux hat keinen rollback-Befehl für Kustomizations, weil Git die Historie ist. Um eine fehlerhafte Änderung rückgängig zu machen:

git revert <bad-commit>
git push
flux reconcile kustomization webapp --with-source

Flux bringt den Cluster auf den zurückgenommenen Stand, und Git bewahrt eine ehrliche Aufzeichnung dessen, was passiert ist. Für Notfälle, in denen der Cluster zuerst aufhören soll, sich zu bewegen: suspendiere die Kustomization, behebe das Problem, pushe den Revert und setze dann fort.

Helm-Releases sind anders: Der helm-controller kann ein fehlgeschlagenes Upgrade automatisch zurückrollen, was die Helm-Anleitung behandelt.

Die Produktion bewusst halten

Weil die Automatisierung standardmäßig an ist, erfolgt die Absicherung der Produktion in Git und nicht über einen „Manueller Sync“-Knopf. Gängige Muster:

• Schütze den Produktions-Branch und verlange Freigabe per Pull Request.
• Richte die GitRepository der Produktion auf einen Tag oder einen Semver-Bereich (ref.tag oder ref.semver), sodass sich die Produktion nur ändert, wenn du ein Release schneidest.
• Nutze flux suspend während Change-Freezes.