Ponerlo a correr era la parte fácil. Mantenerlo corriendo es el trabajo.
Day-two es donde Kubernetes se come a los equipos en silencio: upgrades que rompen algo sin documentar, pérdida de nodos con un runbook obsoleto y config que solo una persona puede explicar. Zeus hace upgrades, scale y teardown operables desde la misma consola en la que provisionas.
El conocimiento tribal no es una estrategia de DR.
La persona que montó el clúster lo entiende. El resto adivina. La config deriva de lo que se supone que es. Los upgrades se aplazan porque nadie confía en que no rompan algo. El node group que corre el servicio de pagos tiene un taint que nadie recuerda haber añadido.
Zeus no hace Kubernetes más simple — hace la complejidad entendible y las operaciones repetibles. Provisionar, escalar, actualizar y destruir clústeres sigue el mismo flujo guiado sin importar quién lo haga o en qué cloud corra.
Las cuatro operaciones que cada clúster necesita.
Aprovisionamiento
Un wizard de cinco pasos — proveedor, basics, network plan, add-ons, review — funciona igual para EKS, GKE, k3s y Proxmox. Míralo construir en vivo. Sin módulos Terraform que mantener, sin scripts específicos de proveedor que debuggear.
Escalar node groups
Managed node groups estilo EKS en cada tipo de clúster, incluido k3s en bare metal. Añade nodos, cambia tipos de instancia, activa spot, define labels y taints, escala en vivo — sin tocar el clúster directamente.
Upgrades que no apuestan con producción
Un banner de EOL aparece antes de que acabe el soporte. Los preflight checks sacan bloqueadores — APIs deprecadas, add-ons incompatibles — antes de que nada se mueva. Un flujo escalonado (plano de control → add-ons → node groups) con rollback significa que un bump de versión no es un fin de semana de ansiedad.
Teardown limpio
El destroy barre recursos etiquetados con una checklist keep/delete: volúmenes EBS, claves KMS, security groups, load balancers. Nada se queda. Sin recursos huérfanos acumulando cargos en silencio meses después.
Un bump de versión de Kubernetes no debería ser una apuesta.
La mayoría de outages por upgrades ocurren por las mismas razones: APIs deprecadas que no se detectaron, add-ons que no soportan la nueva versión, node groups actualizados antes de que el plano de control estuviera estable. Zeus te lleva por cada paso en orden.
Aviso de EOL
Zeus trackea las ventanas de soporte de Kubernetes y saca un banner cuando tu versión se acerca al end-of-life — antes de que te veas forzado a actualizar con prisa.
Preflight checks
Antes de que nada se mueva, Zeus comprueba uso de APIs deprecadas, add-ons incompatibles y bloqueadores conocidos específicos de tu salto de versión.
Flujo escalonado
Primero upgrades del plano de control, luego add-ons, luego node groups — en el orden que espera Kubernetes. Cada paso confirma antes de seguir.
Rollback
Si algo va mal, el camino de rollback es explícito y guiado — no un procedimiento manual que inventas bajo presión.
De qué dejas de tener que enterarte sobre la marcha.
Pods, logs y métricas en vivo en cada clúster.
Explorar →Mismas operaciones en cada proveedor.
Explorar →Equipos que corren Kubernetes sin una persona de infra dedicada.
Explorar →Deja de descubrir que tu runbook no funciona durante un outage real.
Mira cómo Zeus gestiona aprovisionamiento, upgrades y operaciones en una demo en vivo.