Hasta ahora, en todo el curso, ha habido un clúster. Los namespaces rutas-norte-dev, rutas-norte-pre y rutas-norte-pro convivían en él, separados por cuotas, políticas de red y RBAC. Es una arquitectura perfectamente defendible y es donde empieza casi todo el mundo.

Pero llega un momento en que deja de serlo. Puede ser una actualización del plano de control que afecta a los tres entornos a la vez; puede ser el auditor preguntando por qué el clúster que ejecuta rutas-norte-dev tiene acceso a la red donde viven los datos personales de producción; puede ser que la empresa abra operaciones en otra región y la latencia desde Portugal a eu-west-1 empiece a notarse en la conversión. En Rutas Norte fue lo primero: una actualización de EKS que salió mal en pre dejó también pro inaccesible durante diecinueve minutos.

Esta lección trata de qué cambia cuando la plataforma deja de caber en un clúster: por qué se llega ahí, qué topologías existen, cómo se trabaja a diario sin aplicar en el clúster equivocado, cómo Argo CD gobierna una flota, cómo se conectan clústeres entre sí, y el problema que no tiene solución fácil cuando hay que recuperarse de un desastre, que es el dato.

Advertencia de cumplimiento normativo. La distribución de clústeres entre regiones afecta directamente a la residencia de los datos personales de los clientes de Rutas Norte. Replicar postgres-reservas a otra región, almacenar copias de seguridad fuera de la región principal, o permitir que un clúster de una región consulte datos alojados en otra, son decisiones con implicaciones legales que deben ser revisadas y aprobadas por el responsable de cumplimiento normativo antes de implantarse. Los ejemplos de esta lección son ilustrativos.

1. Por qué una empresa acaba con varios clústeres
2. Topologías habituales y cuál elegir
3. El trabajo diario con varios contextos
4. Despliegue multi-clúster con Argo CD
5. Configuración y políticas comunes: el clúster como producto
6. Conectividad entre clústeres
7. Recuperación ante desastres
8. El plan de Rutas Norte
9. El coste, la complejidad y cuándo no hacerlo

No es una decisión que se tome una mañana. Se llega por acumulación de razones, y conviene reconocerlas para saber cuál te está empujando.

Los namespaces separan cargas, pero no separan el plano de control. Comparten servidor de API, etcd, planificador, CNI, controlador de Ingress y complementos. Todo lo que sea "de clúster" es compartido: CRDs, ClusterRole, webhooks de admisión, versiones de operadores.

En la práctica, esto significa que un desarrollador que despliega un CRD mal formado en dev, o un operador que consume memoria sin control, puede degradar producción. En Rutas Norte fue un webhook de validación mal configurado en dev el que, al no responder, bloqueó la creación de pods en todo el clúster durante ocho minutos, producción incluida.

Con un clúster, la pregunta "¿qué pasa si el clúster falla?" tiene una respuesta única y muy mala: todo cae. El plano de control gestionado de EKS es muy fiable, pero no es el único punto de fallo: un NetworkPolicy demasiado amplia, un agotamiento de IPs de la VPC, una versión de CNI defectuosa o un error humano con kubectl delete afectan a todo lo que hay dentro.

Rutas Norte opera principalmente en el norte peninsular, pero está estudiando expandirse al sur de Francia. Una petición desde Toulouse a eu-west-1 (Irlanda) suma unos 35-45 ms de ida y vuelta solo por la red. Sobre una compra de billete con seis llamadas encadenadas, eso son casi 300 ms de latencia añadida que el usuario percibe.

Este es el motivo que no admite discusión técnica: si la normativa aplicable, un contrato con un cliente corporativo o una decisión del responsable de cumplimiento exige que los datos personales de determinados clientes no salgan de un territorio, hace falta infraestructura en ese territorio. No hay configuración de namespace que resuelva eso.

Kubernetes publica una versión menor cada cuatro meses aproximadamente, y el soporte de cada una dura alrededor de catorce. Actualizar es obligatorio, y probar la actualización en el mismo clúster que produce es imposible por definición. Con varios clústeres se puede llevar dev a la versión nueva, dejar que rompa lo que tenga que romper, y actualizar producción semanas después con la lección aprendida.

Relacionado, pero distinto: hasta las actualizaciones que salen bien tienen ventanas de riesgo. Los nodos se reemplazan, los complementos se reinician, el CNI se actualiza. Con un solo clúster, cada actualización es un evento de producción. Con dos, es un evento de producción una vez cada dos actualizaciones, porque la primera se ha ensayado.

La deriva merece énfasis: el problema de tener varios clústeres no es tenerlos, es mantenerlos iguales. Un parche aplicado a mano en uno y no en otro genera una diferencia que nadie recuerda hasta que causa un incidente meses después. Todo lo del apartado 5 existe para combatir eso.

Empieza por uno. Un solo clúster con namespaces bien separados, cuotas, políticas de red y RBAC resuelve el 80 % de los casos y cuesta una fracción.

El primer desdoblamiento debe ser producción frente al resto. Es el que aporta más por unidad de complejidad: aísla el plano de control de lo crítico, permite ensayar actualizaciones y satisface a cualquier auditoría razonable.

El segundo, si llega, viene impuesto por la geografía o la normativa, no por preferencias de arquitectura.

El clúster de gestión, a partir del tercero. Con dos clústeres, Argo CD puede vivir en el de producción gestionando ambos. Con cuatro, hace falta un sitio neutral.

Aquí es donde se producen los accidentes. Un kubectl delete deploy ejecutado creyendo estar en dev cuando se está en pro es un incidente real y frecuente.

Son dos utilidades pequeñas que ahorran mucho tiempo. Instalarlas es lo primero que hace cualquiera que trabaje con más de un clúster.

Cinco capas, de la más blanda a la más dura. Las tres primeras son avisos; las dos últimas son barreras reales.

Capa 1: el prompt muestra el contexto. Es imprescindible. Sin esto, todo lo demás es opcional.

Fondo rojo cuando estás en producción. Parece trivial y es la medida que más accidentes evita.

Capa 2: contexto por sesión, no global. El problema de use-context es que cambia el estado de todas las terminales abiertas. Una solución mejor es aislar el kubeconfig por terminal:

Así, la terminal de producción es la de producción y punto: no hay forma de que un use-context de otra ventana la cambie.

Capa 3: confirmación explícita para verbos destructivos.

Capa 4: contextos de solo lectura por defecto. Esta es la primera barrera real, porque no depende de la disciplina de nadie. El usuario joan-pro del kubeconfig asume el rol rutasnorte-pro-lectura, mapeado a un ClusterRole de solo lectura:

Escribir en producción exige asumir explícitamente otro rol, con una sesión temporal y un motivo registrado. Es una fricción deliberada de treinta segundos que convierte cada escritura en un acto consciente.

Capa 5: no escribir nunca a mano en producción. El objetivo último. Con GitOps (10-05), el único que aplica cambios en pro es Argo CD. Las personas leen, diagnostican y proponen cambios en Git. La escritura manual queda reservada para incidentes, con el procedimiento de asunción de rol y su registro de auditoría.

Argo CD gestiona clústeres remotos desde una única instalación. Cada clúster se registra como un destino y las Application apuntan al que corresponda.

Las etiquetas son la parte importante: son lo que permite escribir "despliega esto en todos los clústeres de producción" sin enumerarlos.

argocd cluster add crea una ServiceAccount en el clúster destino con los permisos necesarios y guarda sus credenciales como un Secret en el clúster de Argo CD. Ese Secret es una credencial de alto valor: quien lo lea puede desplegar en producción. Debe estar protegido por RBAC estricto y, preferiblemente, cifrado en reposo con una clave gestionada externamente.

Un ApplicationSet genera Application automáticamente a partir de una plantilla y un generador. El generador de clústeres crea una por cada clúster que cumpla un selector.

Esto despliega los complementos comunes (Kyverno, cert-manager, ingress-nginx, node-exporter) en todos los clústeres etiquetados, con las diferencias por entorno resueltas por Kustomize.

Para las aplicaciones de negocio, el generador de matriz combina clústeres con aplicaciones:

Con dos clústeres de producción y seis componentes, esto genera doce Application sin escribir doce ficheros. Añadir una región es registrar un clúster con la etiqueta correcta; añadir un componente es crear un directorio.

La estructura del repositorio soporta dos dimensiones: entorno y clúster.

Regla importante: lo que es igual entre clústeres vive en base; lo que difiere, y solo eso, en el overlay. Cada línea de un overlay es una diferencia que alguien tendrá que entender dentro de seis meses. Si un overlay crece mucho, casi siempre significa que la base está mal factorizada.

Con varios clústeres, la pregunta deja de ser "¿cómo despliego mi aplicación?" y pasa a ser "¿cómo garantizo que los N clústeres cumplen las mismas reglas?".

La idea de clúster como producto consiste en que el equipo de plataforma no entrega "acceso a un clúster", sino un producto con contrato: un clúster recién creado ya viene con observabilidad, políticas de seguridad, RBAC, cuotas, controlador de Ingress, gestión de certificados y copias configuradas. Nadie tiene que montar nada, y por tanto nadie lo monta distinto.

Aunque todo se despliegue por GitOps, la deriva aparece: versiones de complementos instalados por Terraform, parches de emergencia, diferencias en la versión del propio Kubernetes. Conviene un informe periódico.

Y la comprobación que importa de verdad, hecha desde Argo CD:

Dos clústeres son dos redes de pods distintas. Un pod de eu-west-3 no puede resolver api-reservas.rutas-norte-pro.svc.cluster.local del clúster de eu-west-1, ni alcanzar sus IPs. Hay tres niveles de solución, con complejidad muy distinta.

Lo más simple y lo que resuelve la mayoría de los casos. El tráfico de usuarios se dirige a la región adecuada mediante DNS, y cada región es autosuficiente.

• Política de latencia: cada usuario va a la región más rápida para él.
• Política de conmutación: si la comprobación de salud de una región falla, el DNS deja de resolverla.
• Límite importante: el DNS tiene TTL. Con TTL de 60 segundos, la conmutación tarda entre uno y varios minutos, porque hay resolutores que ignoran los TTL cortos. No hay conmutación instantánea por DNS.

Cuando un servicio de un clúster necesita llamar a otro de otro clúster (por ejemplo, la réplica de PostgreSQL siguiendo al primario), hace falta conectividad de red real: emparejamiento de VPC o pasarela de tránsito, rangos CIDR que no se solapen, y reglas de cortafuegos explícitas.

El requisito de los rangos merece atención: si los dos clústeres usan 10.244.0.0/16 para pods, el enrutamiento entre ellos es imposible. Hay que planificar el direccionamiento antes de crear el segundo clúster, y es un error que se paga con una reconstrucción.

Istio, Linkerd o Cilium Cluster Mesh permiten que un Service de un clúster sea alcanzable desde otro de forma transparente, con mTLS, reparto de carga entre regiones, conmutación por localidad y observabilidad unificada.

Qué resuelven de verdad:

• Descubrimiento transparente: api-reservas.rutas-norte-pro.svc funciona desde cualquier clúster de la malla.
• Conmutación por localidad: se prefiere la instancia local y se desborda a la remota solo si la local no está sana.
• mTLS entre clústeres sin tocar la aplicación.
• Una sola vista de la topología del tráfico.

Qué cuestan:

• Un sidecar por pod (o eBPF, según la implementación), con su consumo de CPU y memoria.
• Un plano de control más que operar y actualizar.
• Una capa entera de nuevos modos de fallo, con una curva de aprendizaje considerable.
• Depuración notablemente más difícil: el tráfico ya no va donde parece.

El criterio honesto: una malla multi-clúster se justifica cuando hay muchos servicios llamándose entre regiones. Si la comunicación entre clústeres se reduce a la replicación de la base de datos y a un par de llamadas, el emparejamiento de VPC y unos Services de tipo ExternalName resuelven lo mismo por una fracción del coste.

Rutas Norte no usa malla de servicio. Con dos clústeres, seis componentes y una única conversación entre regiones (la replicación de PostgreSQL), no está justificada. Se revisará si aparece una tercera región.

Aquí es donde el multi-clúster deja de ser una cuestión de arquitectura y pasa a ser una cuestión de supervivencia del negocio.

El argumento a favor del activo-activo no es el tiempo de recuperación, es que el camino de recuperación se ejerce todos los días. Un secundario pasivo que nunca ha servido tráfico real es una hipótesis, igual que la copia que nunca se restauró de 11-02.

El argumento en contra es doble: cuesta el doble, y sobre todo obliga a resolver las escrituras concurrentes en dos regiones, que es un problema de diseño de aplicación, no de infraestructura.

Los mismos conceptos de 11-02, ahora a escala de región:

Los manifiestos se replican con git push. La aplicación arranca en cualquier sitio en minutos. El dato es otra cosa.

Replicación asíncrona de PostgreSQL entre regiones. Es lo que hace Rutas Norte: una réplica en eu-west-3 que sigue al primario de eu-west-1 por replicación en flujo. El retraso típico entre Irlanda y París es de 25-40 ms de red, lo que en la práctica significa un retraso de replicación de menos de un segundo con carga normal, y de unos segundos durante el puente de mayo.

La consecuencia: si la región principal desaparece de golpe, se pierden las transacciones confirmadas que aún no habían llegado a la réplica. Con RPO de 15 minutos hay margen de sobra, pero conviene decirlo con claridad: activo-pasivo con replicación asíncrona no es RPO cero. Puede haber reservas confirmadas al cliente que no existan tras la conmutación, y el negocio tiene que saber qué hacer con eso.

Replicación síncrona daría RPO cero, pero cada confirmación de transacción esperaría la ida y vuelta a la otra región: 35 ms añadidos a cada escritura. En el puente de mayo, eso es inasumible.

Y el problema aún peor: la vuelta. Cuando la región principal se recupera, su base de datos tiene un estado divergente del de la que ha estado sirviendo. No se puede simplemente volver: hay que reconstruir la antigua principal como réplica de la nueva y luego conmutar ordenadamente. Ese procedimiento tiene que estar escrito antes de necesitarlo.

La separación resolvió el problema que la motivó: las actualizaciones de EKS se ensayan en nopro, y un webhook mal configurado por desarrollo ya no puede afectar a la venta de billetes.

Tras el análisis de riesgo, la dirección aprobó una región secundaria en eu-west-3 (París) en modo activo-pasivo, con estas decisiones:

El punto de Argo CD merece atención. Es un error clásico: poner la herramienta que despliega dentro del clúster que puede desaparecer. Rutas Norte lo resuelve con una segunda instancia en eu-west-3 apuntando al mismo repositorio, con syncPolicy.automated desactivada en condiciones normales; se activa como parte del procedimiento de conmutación.

Un procedimiento escrito y nunca ejecutado es una redacción, no un plan. Rutas Norte hace un simulacro anual completo en octubre, fuera de temporada alta:

Resultados del simulacro de octubre de 2025, el primero: RTO real de 71 minutos frente al objetivo de 30. Los hallazgos fueron reveladores y ninguno se habría descubierto sin ejecutarlo:

• El certificado TLS de eu-west-3 había caducado: cert-manager no podía completar el reto ACME porque el DNS no apuntaba a esa región. Se corrigió usando el reto DNS-01 en lugar de HTTP-01.
• Los ExternalSecrets de eu-west-3 apuntaban a un almacén que no estaba replicado a esa región.
• Nadie recordaba dónde estaba escrito el procedimiento de conmutación del DNS.
• La réplica de PostgreSQL llevaba once días sin replicar por una regla de cortafuegos añadida en un cambio no relacionado. Nadie lo sabía porque no había alerta sobre el retraso de replicación entre regiones.

Ese último hallazgo, por sí solo, justificó el simulacro entero: en un desastre real se habrían perdido once días de reservas.

Es una inversión seria. La pregunta que la justifica no es técnica: ¿cuánto cuesta a Rutas Norte una hora caída durante el puente de mayo? Si son 40.000 € de ventas perdidas más el daño reputacional, la inversión se paga con evitar un solo incidente regional. Si el negocio puede absorber medio día caído sin consecuencias graves, no.

• Cuando un solo clúster todavía funciona. Si los namespaces, cuotas y políticas de red cubren tus necesidades de aislamiento, añadir clústeres solo añade deriva.
• Cuando no hay GitOps. Con despliegues manuales, N clústeres significan N oportunidades de divergir. GitOps es requisito previo, no complemento.
• Cuando no hay observabilidad centralizada. Diagnosticar un incidente saltando entre paneles de tres clústeres es inviable. Los logs y las métricas de toda la flota deben verse en un sitio.
• Cuando el equipo no da abasto con uno. Multiplicar la infraestructura no multiplica la capacidad del equipo, la divide.
• Cuando la razón es "por si acaso". Sin un escenario concreto que resolver, la complejidad se paga sin recibir nada.
• Cuando el dato no se puede replicar. Si la aplicación no tolera coherencia eventual y no hay presupuesto para rediseñarla, un segundo clúster da una falsa sensación de seguridad.

Antes de plantearse el segundo clúster, conviene tener resuelto lo anterior, porque casi todo mejora la fiabilidad más por menos dinero:

1. Copias probadas y restauración cronometrada (11-02).
2. GitOps con todo en Git (10-05).
3. Observabilidad y alertas con runbooks (07-04, 11-06).
4. Alta disponibilidad dentro del clúster: multi-zona, PDB, topologySpread (09-05).
5. Despliegues seguros con canario (11-04).
6. Y entonces sí, el segundo clúster.

Un equipo que salta al paso 6 sin los cinco anteriores acaba con dos clústeres frágiles en lugar de uno.

• Crear el segundo clúster con el mismo rango CIDR que el primero. Impide el enrutamiento entre ellos y obliga a reconstruir. Planifica el direccionamiento de toda la flota antes de crear el segundo.
• Poner Argo CD solo dentro del clúster de producción. Cuando ese clúster desaparece, desaparece la capacidad de desplegar en cualquier sitio. Instancia secundaria o clúster de gestión aparte.
• Suponer que el DNS conmuta al instante. Los TTL cortos no siempre se respetan; cuenta con uno a tres minutos como mínimo.
• Un secundario a cero réplicas. Un camino frío no se sabe si funciona. Capacidad mínima permanente y tráfico real, aunque sea poco.
• No alertar sobre el retraso de replicación entre regiones. Es exactamente el fallo que Rutas Norte descubrió en el simulacro: once días sin replicar y nadie lo sabía.
• Duplicar el overlay entero al añadir una región. Solo lo que difiere va en el overlay; si crece mucho, la base está mal factorizada.
• Instalar una malla de servicio multi-clúster por defecto. Es una de las piezas más complejas del ecosistema. Solo se justifica con mucha comunicación entre regiones.
• Consejo: pon el contexto en el prompt hoy mismo, con fondo rojo para producción. Es la medida de mayor retorno por minuto invertido de toda la lección.
• Consejo: haz que los contextos de producción sean de solo lectura por defecto. Escribir debe exigir un acto deliberado y registrado.
• Consejo: escribe el procedimiento de conmutación y el de vuelta. La vuelta es más difícil que la ida y casi nadie la documenta.

Una empresa tiene un clúster con dev, pre y pro en namespaces separados, GitOps con Argo CD, copias probadas mensualmente y observabilidad centralizada. Ha sufrido dos incidentes en seis meses: uno por un operador instalado por desarrollo que consumió toda la memoria de un nodo compartido, y otro por una actualización de la versión del clúster que dejó pro degradado durante 25 minutos. El equipo de plataforma son dos personas. Recomienda una topología, justifícala y di explícitamente qué NO recomiendas y por qué.

Rutas Norte añade el clúster rutasnorte-pro-w3 con las etiquetas entorno=pro, region=eu-west-3 y rol=secundario. Escribe un ApplicationSet que despliegue api-reservas en todos los clústeres con entorno=pro, usando el overlay overlays/pro-{{region}}, y que en los clústeres con rol=secundario arranque con menos réplicas. Indica además qué debe cumplirse en el repositorio para que funcione.

En el simulacro anual, un equipo obtiene: paso 3 (promoción de PostgreSQL) 4 min, paso 4 (Argo CD y escalado) 22 min, paso 5 (verificación) 6 min, paso 6 (DNS) 14 min. RTO total 46 min frente a un objetivo de 30. Identifica los dos pasos problemáticos, propón una causa probable para cada uno y una acción correctora concreta.

Solución 1. Recomendación: topología por entorno, dos clústeres — uno para pro y otro para dev+pre. Justificación: los dos incidentes sufridos son exactamente los que esta topología resuelve; el primero es contención de recursos y del plano de control entre entornos, el segundo es la imposibilidad de ensayar la actualización antes de aplicarla a producción. Además, los requisitos previos están cubiertos: hay GitOps, copias probadas y observabilidad centralizada, así que la deriva es manejable. El coste incremental para dos personas es asumible porque la mayor parte de la operación ya está automatizada.

Lo que no se recomienda: (a) un clúster por unidad de negocio, porque con dos personas de plataforma la proliferación es inasumible y no hay ningún problema que lo motive; (b) una segunda región, porque ninguno de los incidentes fue regional y el coste (infraestructura más replicación del dato) no está justificado por la evidencia disponible; (c) un clúster de gestión dedicado, innecesario con solo dos clústeres, donde Argo CD puede vivir en el de producción gestionando ambos.

Solución 2.

Requisitos en el repositorio: (a) deben existir los directorios overlays/pro-eu-west-1 y overlays/pro-eu-west-3; (b) deben existir los componentes capacidad-reducida y capacidad-completa; (c) todos los clústeres destino deben estar registrados en Argo CD con las etiquetas entorno, region y rol; (d) el AppProject rutas-norte debe tener ambos servidores en su lista de destinos permitidos, o Argo CD rechazará las Application generadas. Nota adicional: como el HPA gobierna las réplicas, el componente debería ajustar minReplicas/maxReplicas del HPA, no el campo replicas del Deployment.

Solución 3. Pasos problemáticos: el 4 (22 min sobre unos 5 esperados) y el 6 (14 min sobre 2).

Paso 4: causa probable, la región secundaria no tenía capacidad de nodos disponible y hubo que esperar a que el autoescalador aprovisionara nodos nuevos, incluyendo la descarga de imágenes que no estaban en caché en esos nodos. Acción correctora: mantener capacidad mínima permanente y precalentar las imágenes (por ejemplo, con un DaemonSet que las descargue, o reservando nodos con las imágenes ya presentes). Alternativa complementaria: sobreaprovisionar con pods de baja prioridad que Karpenter desaloje al escalar (09-03).

Paso 6: catorce minutos para un cambio de DNS indica que no estaba automatizado; probablemente alguien editó registros a mano en una consola web bajo presión, o hubo que buscar las credenciales. Acción correctora: guionizar el cambio con el fichero de cambio ya escrito y versionado en el repositorio, ejecutable con un solo comando, y probarlo fuera del simulacro. Comprobar además que el TTL de los registros es de 60 segundos y no el valor por defecto, que suele ser mucho mayor.

Hemos visto por qué una empresa acaba con varios clústeres —aislamiento del plano de control, radio de impacto, latencia por regiones, residencia del dato, versiones distintas y el simple hecho de que un clúster también se actualiza— y qué cuesta eso realmente. Recorrimos las topologías habituales con la recomendación de empezar por uno y desdoblar primero producción frente al resto; las cinco capas de defensa para no aplicar nunca en el clúster equivocado, de las que la más rentable es poner el contexto en el prompt y la más efectiva es que producción sea de solo lectura por defecto; el gobierno de la flota con el generador de clústeres de ApplicationSet combinado con las superposiciones de Kustomize; la idea de clúster como producto para combatir la deriva; los tres niveles de conectividad entre clústeres y el criterio honesto sobre cuándo una malla de servicio se justifica; y la recuperación ante desastres, donde lo difícil nunca son los manifiestos sino el dato, con su replicación asíncrona, su RPO no nulo y el procedimiento de vuelta que casi nadie escribe.

El plan de Rutas Norte, con dos clústeres hoy y una región secundaria aprobada, ilustra lo esencial: la decisión no se toma por elegancia arquitectónica, sino comparando el coste de la redundancia con el coste de una hora caída en el puente de mayo. Y el simulacro de octubre, con su RTO real de 71 minutos y sus once días de replicación rota que nadie había detectado, deja la lección más importante: un procedimiento no ejecutado no es un plan.

Ya tenemos la plataforma desplegada, con estado, con canalización, con despliegues seguros y con una flota gobernada. Falta lo que ningún tutorial cuenta y lo que ocupa realmente el día a día: mantenerla viva. En la última lección del módulo, Operación en Producción: Incidencias, Runbooks y Costes, veremos cómo se gestiona una incidencia, cómo se escribe un runbook útil, cómo el presupuesto de error decide qué hace el equipo el mes que viene, cómo se planifica la capacidad del puente de mayo y por qué la factura de Kubernetes se dispara y qué hacer al respecto.