Flux rapporte ce qu’il fait via des événements Kubernetes, et le notification controller les transforme en alertes et reçoit aussi des webhooks. Ce guide met en place deux choses : des alertes sortantes vers un outil de chat quand quelque chose échoue ou réussit, et un webhook entrant qui fait réconcilier Flux juste après un push au lieu d’attendre la prochaine interrogation. Slack sert d’exemple, mais les mêmes objets fonctionnent avec Microsoft Teams, PagerDuty, Discord, des webhooks génériques et d’autres, ainsi qu’avec des fournisseurs Git comme GitHub et GitLab pour le statut des commits.

Envoyer des alertes vers Slack

Trois objets sont impliqués : un Secret avec l’adresse du webhook, un Provider décrivant où envoyer, et une Alert décrivant quoi envoyer.

Créez le Secret (la clé doit être address) :

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

Les éléments qui comptent :

• providerRef choisit la destination.
• eventSeverity vaut info (tout, y compris les applications réussies) ou error. Utilisez error pour un canal d’astreinte silencieux et info pour un journal de déploiement.
• eventSources liste les objets à surveiller. Un nom "*" correspond à tous les objets de ce type dans le namespace, utilisez donc namespace: pour surveiller d’autres namespaces.

Les versions d’API de notification évoluent. v1beta2 a été retirée dans Flux 2.9, utilisez donc v1beta3 comme indiqué si vous exécutez Flux 2.9, et l’API v1 est prévue pour Flux 2.10. Vérifiez ce que prend en charge votre cluster avec :

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

Committez ces fichiers, et quand quelque chose échoue dans une Kustomization, un message apparaît dans le canal avec l’objet, la révision et l’erreur. Testez-le en cassant volontairement un chemin de manifeste dans Git.

Renvoyer le statut des commits à GitHub

Un second Provider peut publier le résultat d’un déploiement comme statut de commit, pour qu’une pull request ou un commit indique si Flux l’a appliqué :

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   # un Secret avec une clé "token"

Associez-le à une Alert qui liste la Kustomization comme source. Le jeton doit avoir la permission d’écrire des statuts de commit.

Recevoir des webhooks pour une synchro instantanée

Par défaut, Flux interroge Git selon l’intervalle du GitRepository. Un Receiver accepte les webhooks de votre hébergeur Git et déclenche immédiatement une réconciliation, ce qui vous permet d’allonger l’intervalle d’interrogation tout en obtenant des déploiements quasi instantanés.

Créez un jeton secret partagé (la clé doit être token) :

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

Puis le Receiver, avec l’API stable v1 :

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

Une fois appliqué, demandez à Flux le chemin qu’il a généré :

flux get receivers

Le chemin ressemble à /hook/<hash>. Le notification controller l’expose via un Service nommé webhook-receiver dans flux-system, que vous publiez sur Internet via un Ingress ou un LoadBalancer. Ensuite, dans les paramètres de votre dépôt, ajoutez un webhook avec cette URL, le type de contenu application/json, votre jeton comme secret, et l’événement push. Un push déclenche maintenant une réconciliation du GitRepository et de tout ce qui en dépend. Flux 2.9 prend aussi en charge des Receivers génériques sécurisés par OIDC qui n’ont pas besoin de secret partagé, pour les plateformes capables de présenter un jeton OIDC.

Dépannage

• Aucun message n’arrive : vérifiez kubectl describe alert on-call -n flux-system et les logs du contrôleur avec flux logs --level=error, et vérifiez que la clé du Secret s’appelle address.
• Le webhook ne se déclenche pas : consultez le journal des livraisons dans votre hébergeur Git. Un 404 signifie généralement que le chemin est erroné, et un 401 ou 403 que le jeton ne correspond pas.
• Trop bruyant : resserrez eventSeverity et listez des eventSources précises au lieu de "*".