Flux escala a muchos clústeres ejecutando un conjunto de controladores en cada clúster, todos siguiendo el mismo repositorio de Git en rutas distintas. No hay un hub central en el que registrar clústeres. Esta guía muestra cómo estructurar un único repositorio para staging y producción, hacer bootstrap de cada clúster, ordenar la infraestructura antes que las aplicaciones y cuándo usar en su lugar una configuración de clúster remoto.

Un repositorio, una ruta por clúster

Flux sigue una regla simple: cada clúster se somete a bootstrap contra su propia carpeta bajo clusters/. Un repositorio que sirve a dos clústeres se ve así:

fleet-infra/
├── clusters/
│   ├── staging/
│   │   ├── flux-system/        # creado por bootstrap
│   │   ├── infrastructure.yaml
│   │   └── apps.yaml
│   └── production/
│       ├── flux-system/
│       ├── infrastructure.yaml
│       └── apps.yaml
├── infrastructure/
│   ├── base/                   # compartido: ingress, cert-manager, monitorización
│   ├── staging/
│   └── production/
└── apps/
    ├── base/
    ├── staging/
    └── production/

Las definiciones compartidas viven en carpetas base/, y cada carpeta de entorno contiene el overlay de Kustomize con lo que difiere (consulta la guía de overlays).

Haz bootstrap de cada clúster

Cambia el contexto de kubectl a cada clúster por turnos y haz bootstrap contra el mismo repositorio con una ruta distinta:

kubectl config use-context staging
flux bootstrap github --owner=<user> --repository=fleet-infra \
  --branch=main --path=clusters/staging --personal

kubectl config use-context production
flux bootstrap github --owner=<user> --repository=fleet-infra \
  --branch=main --path=clusters/production --personal

Cada clúster ahora tiene su propia instalación de Flux y su propia carpeta flux-system en Git. Añadir un tercer clúster más adelante es un comando de bootstrap más con una ruta nueva.

Apunta cada clúster a sus propios overlays

clusters/production/apps.yaml aplica el overlay de producción:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m
  dependsOn:
    - name: infrastructure
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./apps/production
  prune: true
  wait: true

clusters/staging/apps.yaml es idéntico salvo por path: ./apps/staging. La Kustomization infrastructure apunta a ./infrastructure/<env> del mismo modo, y tiene wait: true para que las aplicaciones solo arranquen cuando el ingress controller, el gestor de certificados y componentes similares estén listos. El campo dependsOn es lo que impone ese orden.

Verifica entre clústeres

Flux no tiene un dashboard central, así que comprueba cada clúster desde su propio contexto:

flux get kustomizations --context staging
flux get kustomizations --context production

Ambos deberían mostrar Ready. Compara lo que Git dice que está desplegado con lo que informa cada clúster usando flux tree y flux get all -A. Para visibilidad de toda la flota, los equipos suelen recopilar las métricas de Prometheus de Flux en Grafana.

Promueve de staging a producción

Como ambos clústeres leen el mismo repositorio, promover es un commit. Un flujo común es:

1. Cambia apps/staging y deja que Flux lo aplique al clúster de staging.
2. Prueba y verifica.
3. Haz el mismo cambio en apps/production en un pull request revisado, o etiqueta una release que siga el GitRepository de producción (consulta la guía de overlays).

Alternativa: un clúster de control, muchos clústeres remotos

En lugar de ejecutar Flux en cada clúster, puedes ejecutarlo en un solo lugar y hacer que sus Kustomizations y HelmReleases se apliquen a otros clústeres. Define spec.kubeConfig en el recurso con un Secret que contenga el kubeconfig del clúster remoto:

spec:
  kubeConfig:
    secretRef:
      name: production-kubeconfig

Esto centraliza el control, pero también pone las credenciales de cada clúster en el clúster de control. Eso difiere del modelo habitual de Flux, donde las credenciales nunca salen de cada clúster y un clúster comprometido no puede alcanzar a los demás. Prefiere una instalación de Flux por clúster a menos que tengas una razón clara para centralizar, como clústeres edge ligeros. Si optas por esto, usa workload identity de la nube en lugar de kubeconfigs de larga duración donde tu plataforma lo soporte, y mira el Flux Operator para gestionar flotas a escala.

Buenos hábitos

• Mantén la carpeta flux-system de cada clúster fuera de los overlays compartidos. Bootstrap es su dueño.
• Usa dependsOn para que la infraestructura, los CRD y los controladores se instalen antes que las aplicaciones que los necesitan.
• Da a cada clúster su propia clave SOPS (consulta la guía de secretos) para que staging no pueda descifrar los secretos de producción.
• Actualiza Flux un clúster a la vez, empezando por uno que no sea de producción, volviendo a ejecutar flux bootstrap con una CLI más nueva.