Categoría: PaaS y contenedores
Kubernetes gestionado en vuestro proveedor: EKS, GKE, AKS, Hetzner o servidores propios
Vuestro clúster de Kubernetes, en el proveedor que ya usáis, con alguien que lo actualiza a tiempo, sabe restaurarlo y vigila lo que cuesta.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
En resumen
Kubernetes gestionado, en nuestro caso, es la administración de vuestro clúster de Kubernetes en vuestra propia cuenta: EKS, GKE, AKS, DOKS, OVH, Hetzner o servidores propios. Nos ocupamos de las actualizaciones de versión y de nodos, los add-ons, el ingress y los certificados, el autoescalado, el despliegue por GitOps, la observabilidad, las copias con Velero y su restauración probada, los costes y la seguridad.
¿De qué nos encargamos en vuestro clúster?
Un clúster de Kubernetes no se termina el día que se crea. Cada pocos meses hay versión nueva, los add-ons caducan, los certificados se renuevan y el gasto crece sin que nadie lo decida. Esto es lo que mantenemos:
Versiones y nodos
Actualizamos el plano de control, renovamos los grupos de nodos y retiramos las API que desaparecen antes de que rompan un despliegue.
Add-ons
CNI, CSI, CoreDNS, metrics-server, cert-manager y el controlador de ingress, en versiones compatibles con el clúster.
Ingress y certificados
Entrada de tráfico, certificados que se renuevan solos y registros DNS gestionados desde el clúster.
Autoescalado
HPA para los pods y Cluster Autoscaler o Karpenter para los nodos, con peticiones de recursos realistas.
GitOps
Argo CD o Flux: cada cambio entra por el repositorio y se puede revertir.
Observabilidad
Prometheus, Grafana y registros centralizados, con alertas que llevan su runbook.
Copias
Velero con los recursos y los volúmenes fuera del clúster, y una restauración que hemos probado.
Costes
Ajuste de tamaño de nodos y cargas, limpieza de recursos huérfanos y revisión del tráfico de salida.
Seguridad
RBAC, políticas de red y admisión de pods, que detallamos en el bastionado de Kubernetes.
¿Plano de control gestionado o clúster propio?
La primera decisión es quién mantiene la API y etcd. En EKS, GKE, AKS, DOKS y OVH lo hace el proveedor; con k3s, Talos o kubeadm en Hetzner o en vuestros servidores, lo hacemos nosotros. Si os interesa Hetzner en concreto, lo explicamos en Kubernetes en Hetzner. Ninguna opción es mejor en abstracto:
| Criterio | Plano de control gestionado (EKS, GKE, AKS, DOKS, OVH) | Autogestionado (k3s, Talos, kubeadm en Hetzner o en servidores propios) |
|---|---|---|
| Quién mantiene la API y etcd | El proveedor | Nosotros, con copias de etcd y alta disponibilidad |
| Coste de infraestructura | Más alto, sobre todo en tráfico y servicios añadidos | Más bajo, con más trabajo de operación |
| Integración con la nube | Profunda: identidades, balanceadores, volúmenes | La que dan el CCM y el CSI del proveedor, o ninguna en servidores propios |
| Ritmo de versiones | Lo marca el calendario de soporte del proveedor | Lo marcáis vosotros, sin dejarlo caducar |
| Cuándo lo recomendamos | Ya estáis en esa nube, o necesitáis sus servicios gestionados | Cargas estables, coste ajustado o datos que deben quedarse en vuestras máquinas |
¿Qué problemas nos encontramos al heredar un clúster?
- Versiones a la deriva: el plano de control en una versión, los nodos dos por detrás y los add-ons sin tocar desde que se instalaron.
- Actualizaciones aplazadas: nadie se atreve a actualizar porque la última vez algo se rompió, y el clúster se acerca al fin de soporte.
- Gasto que crece solo: nodos grandes medio vacíos, entornos de prueba encendidos de noche y volúmenes de pods que ya no existen.
- Sin runbooks: las alertas suenan, pero no hay escrito qué hacer, y solo una persona sabe cómo se montó.
- Copias sin probar: Velero instalado, pero nadie ha restaurado nunca un espacio de nombres completo.
- Cambios a mano: lo que hay en el clúster ya no coincide con el repositorio.
¿Cómo hacemos una actualización de versión?
Kubernetes solo admite una diferencia limitada de versiones entre la API y los kubelets de los nodos, y el plano de control se sube de una versión menor en una versión menor. Por eso trabajamos siempre con el mismo procedimiento:
Revisión
Buscamos las API obsoletas que usan vuestros manifiestos y charts, y comprobamos qué versión de cada add-on admite la versión destino.
Ensayo
Actualizamos primero un clúster de pruebas o de preproducción con las mismas cargas.
Plano de control
Subimos una versión menor, y solo una, en la ventana acordada con vosotros.
Nodos
Renovamos los grupos de nodos vaciándolos de uno en uno, respetando los presupuestos de interrupción de cada aplicación.
Comprobación
Revisamos alertas, despliegues y certificados, y dejamos anotado qué cambió y qué queda para la siguiente.
¿Cómo sabemos que las copias sirven?
Una copia de Kubernetes que no se ha restaurado nunca es una suposición. Configuramos Velero para guardar los recursos y los volúmenes en un almacenamiento de objetos de otra cuenta o de otro proveedor, y cada cierto tiempo restauramos un espacio de nombres completo en un clúster aparte para comprobar que las aplicaciones arrancan con sus datos. Las bases de datos con muchos datos las preferimos con su propio sistema de copias, como contamos en PostgreSQL gestionado.
¿Y si queremos cambiar de proveedor?
Mover un clúster entre EKS, GKE, AKS u otro proveedor es sobre todo un trabajo de inventario. Lo que hay que traducir son las piezas propias de cada nube: clases de almacenamiento, anotaciones de los balanceadores, identidades de las cargas, secretos y bases de datos gestionadas. Con el clúster en GitOps, el nuevo se levanta en paralelo desde el mismo repositorio, los datos se mueven con Velero o con replicación y el tráfico cambia servicio a servicio. Antes de empezar comparamos costes con vuestras facturas reales en migraciones y costes cloud.
¿Cómo es el soporte día a día?
Cada mes recibís un informe con versiones, incidencias, gasto y la última restauración de prueba. Si buscáis algo más amplio que el clúster, lo integramos en el SRE como servicio.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Hetzner
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| AWS | EKS con grupos de nodos gestionados o Karpenter, AWS Load Balancer Controller, EBS CSI y permisos por pod con IAM. | Las versiones de EKS tienen fecha de fin de soporte estándar; pasada esa fecha, el soporte ampliado se cobra aparte. |
| Google Cloud | GKE Standard o Autopilot, con canal de versiones elegido y ventanas de mantenimiento definidas. | Google actualiza el plano de control por su cuenta: lo importante es que el canal y las ventanas encajen con vuestros despliegues. |
| Azure | AKS con grupos de nodos de sistema y de usuario, actualización automática configurada e identidad de cargas con Microsoft Entra ID. | Conviene separar los grupos de nodos para poder renovar los de aplicación sin tocar los de sistema. |
| DigitalOcean | DOKS con autoescalado de nodos, balanceadores y volúmenes de DigitalOcean. | |
| OVH | Managed Kubernetes Service de OVHcloud, con nodos de Public Cloud y almacenamiento en bloque. | |
| Hetzner | Sin Kubernetes gestionado: montamos el plano de control con k3s, Talos o kubeadm, integrado con los balanceadores y volúmenes de Hetzner. | Menos coste de infraestructura a cambio de operar también el plano de control. |
| Servidor propio | k3s, Talos o kubeadm en vuestros servidores o en máquinas virtuales, con balanceador y almacenamiento propios. | El hardware, la red y el almacenamiento persistente pasan a ser parte del trabajo. |
Qué incluye
- Inventario del clúster: versión, add-ons, cargas, permisos y lo que no está en código.
- Calendario de actualizaciones de Kubernetes, de los nodos y de los add-ons, sin saltarse versiones menores.
- Ingress, certificados automáticos y DNS externo revisados y en el repositorio.
- Autoescalado de pods y de nodos con peticiones y límites ajustados al consumo real.
- Despliegue por GitOps con Argo CD o Flux, con el estado del clúster en Git.
- Métricas, registros y alertas del clúster y de las aplicaciones, con runbooks para cada alerta.
- Copias con Velero fuera del clúster y una restauración de prueba documentada.
- Revisión de costes: nodos sobredimensionados, volúmenes huérfanos, balanceadores olvidados y tráfico.
Preguntas frecuentes
¿Si ya pagamos EKS, GKE o AKS, qué nos queda por gestionar?
Casi todo lo que no es el plano de control: los nodos, los add-ons, el ingress, los certificados, las copias, los permisos, las alertas y el gasto. El proveedor mantiene la API y etcd; lo que corre encima sigue siendo vuestro.
¿Cada cuánto hay que actualizar Kubernetes?
Kubernetes publica una versión menor aproximadamente cada cuatro meses y mantiene parches para las tres más recientes. En la práctica, un clúster de producción necesita una actualización planificada dos o tres veces al año para no quedarse fuera de soporte.
¿Trabajáis en nuestra cuenta o en la vuestra?
En la vuestra. El clúster, la facturación y el código son vuestros; entramos con accesos nominales que podéis revocar. Si un día dejamos de trabajar juntos, todo sigue funcionando y está documentado.
¿Merece la pena Kubernetes para nuestro equipo?
Si tenéis pocas aplicaciones y nadie que lo opere, a menudo no. Un PaaS autoalojado o unos servidores bien gestionados cubren muchos casos con menos piezas. Os lo decimos antes de montar nada.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
- Kubernetes: política de diferencia de versiones entre componentes (Version Skew Policy)
- Velero: referencia de restauración (documentación oficial)
Revisado el