Flux informa de lo que hace mediante eventos de Kubernetes, y el notification controller los convierte en alertas y también recibe webhooks. Esta guía configura dos cosas: alertas salientes a una herramienta de chat cuando algo falla o tiene éxito, y un webhook entrante que hace que Flux reconcilie justo después de un push en lugar de esperar a la siguiente consulta. Slack es el ejemplo, pero los mismos objetos funcionan con Microsoft Teams, PagerDuty, Discord, webhooks genéricos y otros, y con proveedores de Git como GitHub y GitLab para el estado de commits.

Envía alertas a Slack

Intervienen tres objetos: un Secret con la dirección del webhook, un Provider que describe adónde enviar y una Alert que describe qué enviar.

Crea el Secret (la clave debe ser 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

Las partes importantes:

• providerRef elige el destino.
• eventSeverity es info (todo, incluidas las aplicaciones exitosas) o error. Usa error para un canal de guardia tranquilo e info para un registro de despliegues.
• eventSources lista qué objetos vigilar. Un nombre de "*" coincide con todos los objetos de ese tipo del namespace, así que usa namespace: para vigilar otros namespaces.

Las versiones de la API de notificaciones están cambiando. v1beta2 se eliminó en Flux 2.9, así que usa v1beta3 como se muestra si ejecutas Flux 2.9, y la API v1 está planificada para Flux 2.10. Comprueba qué soporta tu clúster con:

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

Haz commit de estos archivos y, cuando algo falle en una Kustomization, aparece un mensaje en el canal con el objeto, la revisión y el error. Pruébalo rompiendo a propósito una ruta de manifiesto en Git.

Informa del estado del commit a GitHub

Un segundo Provider puede publicar el resultado de un despliegue como estado de commit, para que un pull request o commit muestre si Flux lo aplicó:

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 con una clave "token"

Combínalo con una Alert que liste la Kustomization como su source. El token necesita permiso para escribir estados de commit.

Recibe webhooks para una sincronización instantánea

Por defecto Flux consulta Git según el intervalo del GitRepository. Un Receiver acepta webhooks de tu host de Git y desencadena una reconciliación de inmediato, de modo que puedes alargar el intervalo de consulta y aun así obtener despliegues casi instantáneos.

Crea un token secreto compartido (la clave debe ser 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

Luego el Receiver, usando la API estable 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

Una vez aplicado, pídele a Flux la ruta que generó:

flux get receivers

La ruta tiene la forma /hook/<hash>. El notification controller la expone mediante un Service llamado webhook-receiver en flux-system, que publicas en internet mediante un Ingress o LoadBalancer. Luego, en los ajustes de tu repositorio, añade un webhook con esa URL, tipo de contenido application/json, tu token como secreto y el evento push. Un push ahora desencadena una reconciliación del GitRepository y de todo lo que depende de él. Flux 2.9 también soporta Receivers genéricos protegidos con OIDC que no necesitan un secreto compartido, para plataformas que pueden presentar un token OIDC.

Solución de problemas

• No llegan mensajes: comprueba kubectl describe alert on-call -n flux-system y los logs del controlador con flux logs --level=error, y verifica que la clave del Secret se llame address.
• El webhook no se dispara: mira el registro de entregas en tu host de Git. Un 404 suele significar que la ruta es incorrecta, y un 401 o 403 significa que el token no coincide.
• Demasiado ruido: ajusta eventSeverity y lista eventSources concretos en lugar de "*".