Un clúster central guarda los kubeconfigs del resto y empuja el estado deseado a cada uno. Funciona mientras los clústeres sean tres y estén en la misma red. A escala de un banco, una aseguradora o una flota edge, el patrón se rompe en tres puntos a la vez.
Dónde se rompe hub-and-spoke
Blast radius. El hub guarda un kubeconfig de admin de cada spoke. Comprometer cualquier componente del clúster de control compromete toda la flota, no «un incidente en un entorno». La rotación de tokens ayuda poco: mientras el token siga vivo, el hub tiene acceso total a prod.
Modelo de red. El hub necesita acceso inbound directo al API server de cada spoke. En AWS eso son security groups y peerings entre regiones; en infraestructura edge, donde el spoke vive detrás de NAT, no funciona sin VPN o túnel.
Compliance. Los sectores regulados prohíben el tráfico inbound hacia clústeres de producción desde cualquier red externa — y el hub es externo en esta imagen. Un requisito del auditor, no una limitación de arquitectura; hub-and-spoke no esquiva esa barrera.
A eso se suma un techo operativo: un único pod application-controller toca límites de CPU y memoria con 5000+ Applications. ArgoCD v3 (principios de 2026) trae horizontal scaling del controller; antes hay que shardear con ARGOCD_CONTROLLER_REPLICAS y round-robin por cluster ID. Con cincuenta spokes y cientos de Applications cada uno, el control plane se convierte en cuello de botella sin sharding.
Per-cluster local
Cada clúster corre su propio ArgoCD que mira solo su subset del repositorio gitops. El blast radius de una intrusión es un único clúster. El modelo de red es trivial: ArgoCD ↔ K8s API siempre es local, vía https://kubernetes.default.svc. El sharding no hace falta porque 5000 Applications nunca caen en el mismo controller — están físicamente repartidas entre clústeres.
El precio es no tener un panel único y N instancias que actualizar de forma sincronizada. La UI de ArgoCD muestra solo el clúster local; el ingeniero on-call con tres prods mantiene tres pestañas abiertas. El matrix-generator de ApplicationSet funciona en local, pero solo con exactamente dos generators hijo — el resto ya no se soporta. El clúster local hay que re-registrarlo con un cluster Secret explícito y nombre único, porque el entry por defecto in-cluster rompe el matching de {{name}}.
Per-cluster local gana donde compliance prohíbe la centralización, la red del spoke no es de confianza y la flota no necesita una consola de auditoría central en primer lugar.
Pull-mode: la tercera opción
Sveltos Addon Controller en pull-mode (desde v1.0.0, endurecido en v1.4.0) invierte la dirección: el spoke inicia una conexión outbound al hub y se trae su estado deseado. El hub deja de guardar tokens de admin de los spokes — guarda SA tokens con los que el spoke lee su propia configuración en el hub en modo read-only. Comprometer el hub pasa a ser comprometer un API read-only, no acceso de admin a la flota.
Use cases — sectores regulados (banca, healthcare), edge e IoT (sistemas POS, plantas industriales, barcos con conectividad intermitente), entornos air-gapped (solo outbound), multi-cloud con un único modelo GitOps sobre AWS/GCP/Azure/on-prem. ArgoCD core avanza en la misma dirección con argocd-agent (KubeCon EU 2025) y Akuity Platform, pero a principios de 2026 Sveltos pull-mode es la implementación de producción más madura.
Cuándo elegir cada uno
Per-cluster local — air-gapped, edge, spokes con compliance restrictivo, sin conectividad de red entre clústeres. Un buen default para un equipo que no necesita un dashboard único.
Hub-and-spoke — gobernanza centralizada, flota de hasta una docena de clústeres en la misma red, equipo que se beneficia de una UI compartida. Planifica el sharding del controller con antelación si avanzas hacia 1000+ Applications.
Pull-mode — todo lo que rompe hub-and-spoke por compliance o por modelo de red y donde per-cluster local no encaja porque necesitas un control plane central.
Un híbrido es viable: ArgoCD hub-and-spoke para app delivery en el segmento de confianza, Sveltos pull-mode para el segmento con compliance restrictivo. No como arquitectura inicial, sino como resultado de la evolución cuando parte de la flota se va al edge o a un perímetro regulado.
Caso aparte es el managed ArgoCD sobre EKS Capabilities. AWS lleva la instalación, los upgrades y la HA; el precio es que Argo vive fuera del clúster, https://kubernetes.default.svc como destination no funciona y EKS se registra como remote target. Identity Center es obligatorio. Hub-and-spoke con zero ops sobre el propio hub, pero con los mismos límites de compliance que un hub self-hosted.