Kubernetes es de código abierto y gestionar tu propio clúster es una opción legítima. Lo que merece examinarse en detalle es qué le exige un clúster de producción a quien lo gestiona de forma continuada, usando como fuente la documentación y la release policy del propio proyecto Kubernetes, no afirmaciones de marketing.
Cada versión de Kubernetes tiene fecha de caducidad
El proyecto Kubernetes mantiene ramas de publicación para las tres versiones minor más recientes. Cada versión minor recibe aproximadamente catorce meses de soporte con parches: doce meses de soporte estándar y después un periodo de mantenimiento de dos meses, tras el cual la serie llega al fin de su ciclo de vida y deja de recibir correcciones.
A septiembre de 2026, las versiones minor mantenidas activamente son la 1.37, la 1.36 y la 1.35. La versión 1.34 está en su última ventana de mantenimiento y llega al fin de su ciclo de vida el 27 de octubre de 2026. La versión 1.33 ya llegó al fin de su ciclo de vida el 28 de junio de 2026.
Quedarse atrás sale caro, porque las actualizaciones no pueden saltarse versiones minor. La version-skew policy exige que kube-apiserver avance una versión minor cada vez, incluso en clústeres de una sola instancia. Un clúster que sigue en la 1.33 necesita, por tanto, cuatro actualizaciones consecutivas del control plane (1.34, 1.35, 1.36 y 1.37) para ponerse al día, y cada una requiere su propia preparación, por ejemplo comprobar que tus admission webhooks pueden gestionar las versiones de API que les envía el nuevo servidor.
Los nodos añaden trabajo propio. Las actualizaciones in situ de versiones minor de kubelet no son compatibles: cada nodo debe vaciarse (drain) primero. Un kubelet puede ir por detrás del API server hasta tres versiones minor, pero la documentación advierte de que un clúster con kubelets de forma persistente tres versiones por detrás debe actualizarlos antes de que el control plane pueda avanzar siquiera.
La alta disponibilidad es un diseño del que eres responsable
Un único nodo de control plane es un punto único de fallo. La guía de alta disponibilidad de kubeadm describe dos topologías. En la topología stacked predeterminada, cada nodo de control plane ejecuta también un miembro de etcd, de modo que perder un nodo supone perder tanto una instancia de control plane como un miembro de etcd; la documentación indica ejecutar al menos tres nodos de control plane stacked. La alternativa, etcd externo, separa ambos componentes pero requiere un mínimo de tres hosts de control plane más tres hosts de etcd.
etcd necesita un quórum, es decir, la mayoría de sus miembros, para aceptar cambios. Un clúster de tres miembros tolera el fallo de un miembro y uno de cinco miembros tolera dos, mientras que añadir un cuarto miembro no aporta ninguna tolerancia a fallos adicional. La documentación de Kubernetes recomienda un número impar de miembros y, para producción, un clúster de cinco miembros.
etcd también es sensible al entorno en el que se ejecuta:
- Disco y red. El rendimiento de etcd depende de la E/S de disco y de red. La falta de recursos puede provocar timeouts de heartbeat y dejar el clúster sin líder, y un clúster sin líder no puede cambiar de estado, lo que significa que no se pueden planificar nuevos pods.
- Recursos dedicados. La documentación aconseja ejecutar etcd en máquinas dedicadas o en entornos aislados para que sus requisitos de recursos estén garantizados, y las propias FAQ de etcd recomiendan encarecidamente los SSD.
- El acceso equivale a root. El acceso a etcd equivale a permisos de root en el clúster, por lo que lo ideal es que solo el API server pueda alcanzarlo, protegido con certificados TLS x509.
Un backup solo cuenta una vez que has restaurado a partir de él
La documentación de Kubernetes es directa: si tu clúster usa etcd como backing store, asegúrate de tener un plan de backup de esos datos. En la práctica significa snapshots programados con etcdctl, guardados en un lugar que no comparta dominio de fallo con el clúster, y un procedimiento de restauración con etcdutl que alguien haya ensayado de verdad.
Los snapshots también requieren un manejo cuidadoso, porque contienen todo lo que el API server conoce. Por defecto, el API server almacena los recursos en etcd en texto plano, sin cifrado en reposo, a menos que lo configures. El snapshot de un clúster sin cifrar puede, por tanto, llevarse consigo tus Secrets.
Los certificados caducan según un calendario
Los certificados de cliente generados por kubeadm caducan al cabo de un año. kubeadm los renueva automáticamente cuando ejecutas una actualización del control plane, así que un clúster actualizado al menos una vez al año está cubierto, y uno que pasa más de un año sin actualizarse, no. Puedes comprobar la caducidad con kubeadm certs check-expiration y renovar manualmente con kubeadm certs renew all, comando que en un control plane replicado hay que ejecutar en cada nodo de control plane.
Los complementos son proyectos distintos con ciclos de vida distintos
Un clúster es más que su control plane. Redes, ingress o Gateway API, controladores de almacenamiento, gestión de certificados, métricas y monitorización son proyectos independientes, cada uno con su propio ciclo de publicación, sus versiones y sus fechas de fin de ciclo de vida. En un clúster autoalojado, hacer el seguimiento de todos ellos es cosa tuya.
En noviembre de 2025, el proyecto Kubernetes anunció la retirada de Ingress NGINX, uno de los ingress controllers más utilizados. El mantenimiento best-effort terminó en marzo de 2026: ya no hay más versiones, correcciones de errores ni actualizaciones de seguridad. Los despliegues existentes siguen funcionando y los artefactos siguen disponibles, pero cualquier vulnerabilidad que se descubra después no se parcheará. En enero de 2026, los comités Kubernetes Steering y Security Response lo describieron como infraestructura crítica para aproximadamente la mitad de los entornos cloud native y instaron a migrar a Gateway API o a otro controlador.
La propia guía de migración del proyecto añade una advertencia: Ingress NGINX tiene comportamientos implícitos y una traducción que parece correcta aún puede causar interrupciones. Nada de esto es un defecto de Kubernetes. Es la vida normal de un gran ecosistema de código abierto, y exactamente el trabajo que un clúster autoalojado traslada a tu equipo.
Comparación directa
| Categoría | Autoalojado | Kube-DC Managed Cluster |
|---|---|---|
| Ciclo de vida de las versiones | Tú haces el seguimiento de las fechas de publicación y de fin de ciclo de vida y actualizas una versión minor cada vez, con unos catorce meses de soporte por versión minor | Actualizaciones escalonadas y controladas por el tenant: el control plane y los worker pools avanzan por separado, por fases. Tú sigues eligiendo la versión de destino y el momento |
| Control plane | Tres o más nodos de control plane que diseñar, proteger y parchear por tu cuenta | Los control planes alojados funcionan como pods gestionados en la plataforma: obtienes tu propia API de Kubernetes y una PKI por clúster sin operar los masters |
| etcd | El dimensionamiento del quórum, los discos dedicados, el TLS, la desfragmentación y la supervisión corren de tu cuenta | Un datastore dedicado o compartido gestionado por la plataforma, con autoescalado vertical de control plane y etcd activado por defecto |
| Backups | Tú diseñas la programación de snapshots, el almacenamiento y los simulacros de restauración | Snapshots de etcd programados, configurados por clúster, con cifrado envelope opcional, y restauración: de autoservicio para datastores de una sola réplica, asistida para los de varias réplicas. Los snapshots se almacenan en el almacenamiento S3 del proyecto en la plataforma, así que conserva tu propia copia fuera de la plataforma si la necesitas fuera del dominio de fallo del almacenamiento de la plataforma |
| Certificados | Certificados kubeadm de un año, renovados en la actualización o por ti | PKI por clúster y certificados TLS de etcd aprovisionados automáticamente con el clúster |
| Nodos worker | Eres tú quien aprovisiona, crea la imagen, parchea y sustituye los nodos | Worker pools dimensionados por pool (CPU, memoria, disco, imagen), con límites de autoescalado por pool |
| Metrics API | Eres tú quien instala y mantiene metrics-server | Preinstalado y funcionando en nuestra prueba de extremo a extremo de agosto de 2026 |
| Tiempo hasta el primer clúster | De horas a días de configuración, más mantenimiento continuo | Creado desde un proyecto en el portal o con un único manifest; la documentación de la plataforma describe un aprovisionamiento en minutos |
| Guardias | Tu equipo | Soporte 24/7 por correo y tickets con un objetivo de resolución de 4 horas (MTTR), incluido en el precio |
| Qué sigue siendo tuyo | Todo, desde el hardware hasta las cargas de trabajo | Tus cargas de trabajo, el control de acceso y los complementos que instalas dentro de tu clúster: es un clúster de Kubernetes completo, administrado por el tenant |
Cuándo el autoalojamiento es la opción correcta
Si tu equipo ya ejecuta etcd en producción, sigue las notas de versión de Kubernetes y de los complementos, ensaya las restauraciones y dispone de cobertura de guardias, el autoalojamiento es una extensión razonable de la práctica existente. También es la opción adecuada cuando necesitas un control que un servicio gestionado no puede dar, como una configuración personalizada del control plane o un entorno totalmente aislado. Para un equipo sin esa capacidad ya establecida, cada sección anterior se convierte en trabajo nuevo y continuo.
Fuentes
- Kubernetes releases and patch support policy
- Kubernetes patch releases: support period
- Kubernetes version skew policy
- kubeadm: options for highly available topology
- Operating etcd clusters for Kubernetes
- etcd FAQ: cluster size and failure tolerance
- Encrypting confidential data at rest
- Certificate management with kubeadm
- Ingress NGINX retirement: what you need to know
- Ingress NGINX: statement from the Steering and Security Response Committees
- Kube-DC platform datasheet
Descubre la plataforma
Cloud Acropolis Kube-DC te ofrece tus propios clústeres de Kubernetes administrados por el tenant (control planes alojados, worker pools y actualizaciones escalonadas) sobre vCPU dedicadas, almacenamiento NVMe respaldado por Ceph, una IPv4 pública dedicada y almacenamiento de objetos compatible con S3. Lo pides y lo gestionas todo en un portal de autoservicio, con soporte 24/7 por correo y tickets y un objetivo de resolución de 4 horas incluidos. Todos los paquetes incluyen clústeres de Kubernetes anidados y la GPU compartida está disponible como opción.
Descubre Kube-DC Kubernetes