Categoría: PaaS y contenedores
Kubernetes en Hetzner, montado y operado para producción
Un clúster en Hetzner con el plano de control que no os da el proveedor, montado en código, con copias, GitOps y actualizaciones de versión que alguien hace por vosotros.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
En resumen
Kubernetes en Hetzner es un clúster de Kubernetes montado sobre servidores de Hetzner Cloud, que no ofrece Kubernetes gestionado. Montamos el clúster con k3s, Talos o kubeadm, lo integramos con los balanceadores, la red privada y los volúmenes de Hetzner, configuramos copias con Velero y despliegues por GitOps, y nos ocupamos de las actualizaciones. Es una alternativa europea y más barata a EKS o GKE.
¿Qué cambia al no haber Kubernetes gestionado?
En EKS, GKE o AKS el proveedor mantiene el plano de control: la API, etcd y las actualizaciones de los componentes centrales. En Hetzner no existe ese servicio, así que el plano de control es otro servidor más que alguien tiene que montar, copiar y actualizar. Esa es la parte de la que nos hacemos cargo:
Plano de control
Tres nodos con etcd, copias periódicas de etcd y certificados que se renuevan solos.
Integración con Hetzner
CCM para balanceadores y nodos; CSI para volúmenes; etiquetas de ubicación en cada nodo.
Red
Red privada entre nodos, CNI con políticas de red y cortafuegos del proveedor.
GitOps
Argo CD o Flux: lo que hay en el clúster es lo que hay en el repositorio.
Copias
Velero con los manifiestos y los volúmenes, hacia Object Storage.
Observabilidad
Métricas, registros y alertas del clúster y de las aplicaciones.
¿Qué distribución elegimos?
| Opción | Cuándo la usamos | Lo que hay que saber |
|---|---|---|
| k3s | Equipos pequeños o medianos que quieren algo ligero y fácil de mantener | Binario único; etcd integrado en alta disponibilidad con tres servidores |
| Talos Linux | Cuando la seguridad del nodo importa: sistema inmutable, sin SSH | Se administra solo por API; hay que acostumbrarse |
| kubeadm | Cuando queréis Kubernetes sin modificar y control total | Más piezas que mantener a mano |
| Cluster API con el proveedor de Hetzner | Varios clústeres o clústeres que se crean y se destruyen a menudo | Más complejo de arrancar, más cómodo a escala |
En todos los casos, los nodos hablan entre sí por la red privada de Hetzner, el tráfico de entrada llega por un Load Balancer de Hetzner que crea el propio CCM y los volúmenes persistentes se piden al driver CSI.
¿Qué problemas encontramos en clústeres de Hetzner?
- Un solo nodo de plano de control: si ese servidor cae o se corrompe etcd, el clúster se queda sin cerebro.
- Sin copia de etcd: se copia el contenido de los volúmenes, pero no el estado del clúster.
- Volúmenes que no se mueven: un pod con volumen no puede arrancar en un nodo de otra ubicación.
- API expuesta a internet: el puerto de la API abierto a cualquiera, sin cortafuegos.
- Versión fuera de soporte: Kubernetes saca versiones menores con frecuencia y el clúster se queda atrás.
- Clúster hecho a mano: nadie sabe recrearlo porque no está en código.
¿Cómo hacemos las copias, las actualizaciones y la seguridad?
Copiamos etcd cada pocas horas fuera del clúster y, con Velero, los manifiestos y los volúmenes hacia Object Storage de Hetzner o de otro proveedor. Restauramos periódicamente en un clúster de prueba para confirmar que las aplicaciones arrancan con sus datos. Las bases de datos importantes las preferimos fuera de los volúmenes del clúster o con su propio sistema de copias, como explicamos en PostgreSQL gestionado.
Las actualizaciones de Kubernetes van de versión menor en versión menor, primero en el plano de control y luego nodo a nodo, vaciando cada uno antes. Antes revisamos las API que desaparecen. Para la seguridad aplicamos el bastionado de Kubernetes: políticas de red, admisión de pods, RBAC mínimo y secretos fuera del repositorio.
¿Cómo migramos desde EKS, GKE o AKS?
Primero hacemos inventario de lo que depende del proveedor: balanceadores, clases de almacenamiento, identidades de IAM, secretos y bases de datos gestionadas. Montamos el clúster de Hetzner en paralelo, traducimos esas dependencias, desplegamos por GitOps y movemos el tráfico servicio a servicio con el DNS. El ahorro lo calculamos antes con vuestra factura real; lo explicamos más en migraciones y costes cloud. Si preferís no tener plano de control propio, la tabla comparativa de Kubernetes gestionado compara un clúster autogestionado como este con los Kubernetes gestionados.
¿Usáis otro proveedor? Lo que hacemos en EKS, GKE, AKS y el resto está en Kubernetes gestionado.
¿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
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Plano de control y nodos en servidores cloud, montados por nosotros. Load Balancers, Networks, Volumes y Firewalls de Hetzner integrados con el CCM y el CSI oficiales. | Sin Kubernetes gestionado: la etcd, las versiones y la alta disponibilidad del plano de control son responsabilidad nuestra. |
| AWS | EKS, con nodos gestionados o Karpenter, balanceadores de AWS y volúmenes EBS. | El plano de control lo pone AWS; integración profunda con IAM. Más caro, sobre todo en tráfico de salida. |
| Google Cloud | GKE en modo estándar o Autopilot. | Muy maduro; las actualizaciones del clúster pueden ser automáticas. |
| Azure | AKS con grupos de nodos y Azure Disk o Azure Files para volúmenes. | Encaja si la identidad ya va con Microsoft Entra ID. |
| DigitalOcean | DOKS, con balanceadores y volúmenes de DigitalOcean. | Gestionado y sencillo; menos opciones de red que los grandes. |
| OVH | Managed Kubernetes Service de OVHcloud. | |
| Servidor propio | k3s o Talos en vuestros servidores o en máquinas virtuales de Proxmox, con MetalLB o un balanceador propio. | Sin volúmenes del proveedor: el almacenamiento persistente hay que resolverlo aparte. |
Qué incluye
- Clúster de Kubernetes en vuestra cuenta de Hetzner, definido en código (Terraform u OpenTofu) en vuestro repositorio.
- Distribución elegida según el caso: k3s, Talos Linux, kubeadm o Cluster API.
- Controlador de nube de Hetzner para balanceadores y nodos, y driver CSI para volúmenes.
- Red privada entre nodos, cortafuegos de Hetzner y API del clúster sin exponer a todo internet.
- Ingress, certificados automáticos y DNS externo.
- Copias del clúster y de los volúmenes con Velero hacia Object Storage, con restauración de prueba.
- Despliegues por GitOps con Argo CD o Flux.
- Actualizaciones de versión de Kubernetes y del sistema de los nodos, una versión menor cada vez.
Preguntas frecuentes
¿Es seguro usar k3s en Hetzner para producción?
Sí, si se monta como producción: tres nodos de plano de control, etcd con copias, red privada, cortafuegos y actualizaciones al día. k3s es Kubernetes certificado; lo que lo hace frágil no es k3s, sino un clúster de un nodo sin copias.
¿Cuánto nos ahorramos respecto a EKS o GKE?
Depende de la carga, pero los servidores y el tráfico de Hetzner suelen salir bastante más baratos. A cambio, el plano de control no lo mantiene el proveedor, y ese trabajo tiene que hacerlo alguien. Hacemos la comparación con vuestros números antes de decidir, sin cifras de catálogo.
¿Cómo se migra de EKS a Hetzner?
Montamos el clúster nuevo en paralelo, adaptamos lo que dependía de AWS (balanceadores, volúmenes, IAM, secretos), restauramos las aplicaciones con Velero o las desplegamos por GitOps, y cambiamos el DNS servicio a servicio. Las bases de datos gestionadas como RDS se migran aparte, con replicación.
¿Qué pasa si se cae un centro de datos de Hetzner?
Si el clúster está repartido en varias ubicaciones de la misma zona de red, sigue funcionando con los nodos que quedan. Los volúmenes de Hetzner, en cambio, están en una sola ubicación: los datos críticos van con réplica a nivel de aplicación o con copias que se pueden restaurar en otra.
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:
- Hetzner Cloud: Kubernetes Cloud Controller Manager (repositorio oficial)
- Hetzner Cloud: Container Storage Interface driver (repositorio oficial)
Revisado el