Flux meldet, was es tut, über Kubernetes-Events, und der notification-controller verwandelt diese in Alerts und empfängt außerdem Webhooks. Diese Anleitung richtet zwei Dinge ein: ausgehende Alerts an ein Chat-Werkzeug, wenn etwas fehlschlägt oder gelingt, und einen eingehenden Webhook, der Flux direkt nach einem Push abgleichen lässt, statt auf die nächste Abfrage zu warten. Slack ist das Beispiel, aber dieselben Objekte funktionieren mit Microsoft Teams, PagerDuty, Discord, generischen Webhooks und anderen sowie mit Git-Anbietern wie GitHub und GitLab für den Commit-Status.

Alerts an Slack senden

Drei Objekte sind beteiligt: ein Secret mit der Webhook-Adresse, ein Provider, der beschreibt, wohin gesendet wird, und ein Alert, der beschreibt, was gesendet wird.

Erstelle das Secret (der Schlüssel muss address heißen):

kubectl create secret generic slack-url \
  --namespace=flux-system \
  --from-literal=address=https://hooks.slack.com/services/XXX/YYY/ZZZ

apps/notifications/provider.yaml:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
  name: slack
  namespace: flux-system
spec:
  type: slack
  channel: deployments
  secretRef:
    name: slack-url

apps/notifications/alert.yaml:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
  name: on-call
  namespace: flux-system
spec:
  providerRef:
    name: slack
  eventSeverity: error
  eventSources:
    - kind: GitRepository
      name: "*"
    - kind: Kustomization
      name: "*"
    - kind: HelmRelease
      name: "*"
      namespace: podinfo

Die wichtigen Teile:

• providerRef wählt das Ziel.
• eventSeverity ist info (alles, einschließlich erfolgreicher Anwendungen) oder error. Nutze error für einen ruhigen Bereitschaftskanal und info für ein Deployment-Log.
• eventSources listet auf, welche Objekte beobachtet werden. Ein Name von "*" passt auf alle Objekte dieser Art im Namespace, nutze also namespace:, um andere Namespaces zu beobachten.

Die API-Versionen der Benachrichtigungen ändern sich. v1beta2 wurde in Flux 2.9 entfernt, nutze also wie gezeigt v1beta3, wenn du Flux 2.9 betreibst; die v1-API ist für Flux 2.10 geplant. Prüfe, was dein Cluster unterstützt, mit:

kubectl get crd alerts.notification.toolkit.fluxcd.io \
  -o jsonpath='{.spec.versions[*].name}'; echo

Committe diese Dateien, und wenn in einer Kustomization etwas fehlschlägt, erscheint eine Nachricht im Kanal mit Objekt, Revision und Fehler. Teste es, indem du absichtlich einen Manifest-Pfad in Git kaputt machst.

Den Commit-Status an GitHub zurückmelden

Ein zweiter Provider kann das Ergebnis eines Deployments als Commit-Status posten, sodass ein Pull Request oder Commit zeigt, ob Flux ihn angewendet hat:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
  name: github-status
  namespace: flux-system
spec:
  type: github
  address: https://github.com/your-org/fleet-infra
  secretRef:
    name: github-token   # ein Secret mit einem "token"-Schlüssel

Kombiniere ihn mit einem Alert, der die Kustomization als Quelle auflistet. Das Token braucht die Berechtigung, Commit-Status zu schreiben.

Webhooks für sofortigen Sync empfangen

Standardmäßig fragt Flux Git im GitRepository-Intervall ab. Ein Receiver nimmt Webhooks von deinem Git-Host an und löst sofort einen Abgleich aus, sodass du das Abfrageintervall verlängern und trotzdem nahezu sofortige Deployments erhalten kannst.

Erstelle ein gemeinsames Secret-Token (der Schlüssel muss token heißen):

TOKEN=$(head -c 12 /dev/urandom | shasum | cut -d ' ' -f1)
echo $TOKEN
kubectl create secret generic webhook-token \
  --namespace=flux-system --from-literal=token=$TOKEN

Dann der Receiver, mit der stabilen v1-API:

apiVersion: notification.toolkit.fluxcd.io/v1
kind: Receiver
metadata:
  name: github-receiver
  namespace: flux-system
spec:
  type: github
  events:
    - ping
    - push
  secretRef:
    name: webhook-token
  resources:
    - apiVersion: source.toolkit.fluxcd.io/v1
      kind: GitRepository
      name: flux-system

Sobald er angewendet ist, frage Flux nach dem erzeugten Pfad:

flux get receivers

Der Pfad sieht aus wie /hook/<hash>. Der notification-controller stellt ihn über einen Service namens webhook-receiver in flux-system bereit, den du über einen Ingress oder LoadBalancer ins Internet veröffentlichst. Füge dann in den Einstellungen deines Repositorys einen Webhook mit dieser URL, dem Content-Type application/json, deinem Token als Secret und dem Event push hinzu. Ein Push löst nun einen Abgleich des GitRepository und von allem aus, was davon abhängt. Flux 2.9 unterstützt außerdem OIDC-gesicherte generische Receiver, die kein gemeinsames Secret brauchen, für Plattformen, die ein OIDC-Token vorlegen können.

Fehlersuche

• Es kommen keine Nachrichten an: Prüfe kubectl describe alert on-call -n flux-system und die Controller-Logs mit flux logs --level=error und verifiziere, dass der Schlüssel des Secrets address heißt.
• Der Webhook löst nichts aus: Sieh in das Zustellungsprotokoll deines Git-Hosts. Ein 404 bedeutet meist, dass der Pfad falsch ist, ein 401 oder 403, dass das Token nicht passt.
• Zu laut: Verengere eventSeverity und liste spezifische eventSources statt "*" auf.