Hetzner
- La migración a Hetzner se realizó principalmente para reducir costos. Los precios de Hetzner son competitivos a nivel mundial.
- Hetzner ofrece máquinas virtuales y máquinas bare metal, y aunque es más limitado que AWS, lo compensa con el precio.
- Al migrar a Hetzner, se redujeron los costos de infraestructura en más de 75%.
Kubernetes en Hetzner
Kubernetes autogestionado
- Se operaba Kubernetes en DigitalOcean, y en Hetzner también se opera de forma autogestionada.
- Hetzner no ofrece un control plane de Kubernetes administrado, por lo que hay que gestionarlo directamente.
- Se usan Terraform y Puppet para administrar y configurar los nodos.
Roles de nodos
- Se usa una convención de nombres de nodos para mantener simples los roles dentro del clúster:
control-plane,worker,database. - Agregar roles es sencillo, pero puede perjudicar la eficiencia en el uso de recursos.
Construcción de nodos
- Se usa Terraform para hacer el bootstrap del clúster.
- Hetzner ofrece firewall y red administrados, que se pueden configurar fácilmente con Terraform.
- Los servidores se gestionan completamente con Terraform, y se escribieron módulos por rol para facilitar la adición de servidores.
Redes
- Se usa Tailscale VPN para las conexiones de administración hacia los nodos.
- Tailscale ofrece NAT hole punching, lo que permite conectarse de forma segura incluso con los puertos cerrados.
- Se bloquean puertos usando el firewall administrado de Hetzner y UFW de Ubuntu.
- Se usa Calico para configurar la interfaz de red de contenedores.
Almacenamiento
- Hetzner ofrece almacenamiento en bloques basado en nVME SSD y SSD.
- Los volúmenes de Hetzner no tienen función de snapshots, por lo que los respaldos de datos deben hacerse manualmente.
- En los nodos de base de datos se usa Local Persistence Volume Static Provisioner para preaprovisionar volúmenes locales.
Respaldos
- Hetzner no ofrece respaldo de volúmenes, pero sí respaldo de servidores completos.
- Se usa Velero de VMware para respaldar namespaces y PVC.
- En el caso de Postgres, se usa pgBackRest.
Funciones adicionales
- Se usa SealedSecrets para la gestión de secretos.
- Se usan Node Exporter, Prometheus, Grafana y Loki para monitorear el clúster.
- Se usa Alertmanager para integrar alertas con Slack.
Opiniones sobre operar Kubernetes en Hetzner
- La migración a Hetzner tomó alrededor de 1 semana, y las pruebas y ajustes adicionales tomaron 4 semanas.
- Los precios de Hetzner son razonables, y se cree que seguirán siendo más bajos que los de otros proveedores.
- Hay limitaciones relacionadas con la calidad de IP de Hetzner y su servicio al cliente.
- Hetzner lanza nuevas funciones rápidamente, pero también puede discontinuar con rapidez los servicios menos rentables.
- Las ubicaciones de sus centros de datos en Europa Central son Falkenstein y Nuremberg en Alemania, y Helsinki en Finlandia.
Resumen
- Esta transición se realizó sin problemas, redujo los costos de infraestructura en más de 75% y duplicó los recursos de cómputo del clúster.
- Hetzner es una opción muy ventajosa cuando se necesita reducir costos.
- El controlador open source de Hetzner facilita la gestión de load balancers y la conexión persistente de volúmenes.
1 comentarios
Opiniones de Hacker News
Durante varios años hemos ofrecido clústeres de Kubernetes a clientes usando servidores dedicados de Hetzner, y el rendimiento sin duda parece excelente: por lo general, los tiempos de solicitud se reducen aproximadamente a la mitad.
Como el hardware es barato, también podemos ofrecer horas dedicadas de ingeniería DevOps para cada cliente, pero hay algunas condiciones. Un clúster de staging para probar actualizaciones es prácticamente indispensable, y nadie quiere empujar actualizaciones de producción un domingo a puro instinto. La replicación a nivel de aplicación es lo más importante, luego viene la replicación a nivel de bloques, y estamos usando OpenEBS/Mayastor. Después de probar varios operadores de Postgres, actualmente consideramos que StackGres es el mejor.
Los playbooks de Ansible son un activo: si se organizan bien y se comentan para un servicio específico, más adelante es fácil volver a desplegar el mismo servicio en otro lugar. Si es posible, recomiendo una red dedicada de 10G para conectar los servidores. 1G se queda corto cuando se combinan el tráfico de producción, los pulls de imágenes y el tráfico entre servicios, y la latencia mejora 10 veces frente a la comunicación interna entre zonas de disponibilidad como en AWS.
Si se necesita redundancia de red, se puede crear un vSwitch (VLAN) interno de 1G sobre el puerto de 1G, asignar una IP de loopback a cada servidor y distribuir las rutas con BGP (bird). Un clúster de MinIO no es tan difícil si se opera de la forma estándar mediante el operador, y proporciona almacenamiento de objetos local de alto ancho de banda y baja latencia. La inversión inicial requiere alrededor de 2 a 4 meses de tiempo de ingeniería experimentada sin interrupciones, y las tareas auxiliares y molestas como el balanceo de carga HTTP todavía se pueden delegar a un proveedor cloud como CloudFlare.
En la documentación pública aparece una opción de uplink de 10G, pero es para la red externa, y el límite de 20 TB parece bastante ajustado. Si se trata de entrada/salida interna del clúster, 20 TB puede convertirse fácilmente en un problema.
Trabajo en esa empresa, y creamos una plataforma que entrega clústeres listos para producción en cuestión de minutos.
Si eres una consultora, seguramente quieras vender ese trabajo, pero desde el punto de vista del cliente no parece que valga la pena en absoluto, salvo que espere una factura mensual de AWS de unos 10 mil dólares. Me recuerda a xkcd: https://xkcd.com/1319/.
He operado clústeres de Kubernetes en servidores dedicados de Hetzner y también he trabajado con servicios total o altamente administrados como Aurora, S3 y ECS Fargate.
Según mi experiencia, la factura cloud de Hetzner a veces puede bajar hasta el 20% de una equivalente en AWS, pero esa ventaja de costo viene con grandes compromisos.
En Kubernetes sobre Hetzner administré un clúster de Ceph basado en almacenamiento NVMe, un operador de MariaDB, Cilium para networking y ArgoCD para desplegar Helm charts. También tuvimos que encargarnos directamente de las actualizaciones del clúster de Kubernetes, y una vez sufrimos una caída completa del clúster. Encontramos varios bugs tanto en Kubernetes como en Ceph, muchos de los cuales ya estaban registrados en issues de GitHub y en el tracker de Ceph. La lista de tareas que había que administrar y monitorear era interminable, y según la cantidad de workloads y la complejidad del entorno, mantener una configuración así puede convertirse en un trabajo de tiempo completo para el equipo DevOps.
En cambio, con AWS u otros proveedores cloud importantes se puede tener una configuración que requiere mucha menos intervención. Usar servicios administrados reduce mucho el esfuerzo de mantenimiento y también baja la carga operativa del equipo. En definitiva, AWS reduce mucho la carga de trabajo de DevOps, mientras que Hetzner reduce mucho la factura cloud. Para saber cuál es más rentable hace falta un análisis del costo total de propiedad (TCO), y aunque Hetzner parezca barato al inicio, el tiempo adicional de DevOps puede compensar esos ahorros.
Por ejemplo, si comparas una configuración de 2 vCPU y 4 GB con una similar en AWS, AWS es mucho más caro, así que me gustaría ver el análisis de costos. También existe https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner como herramienta para reducir la carga operativa.
Ni siquiera fue fácil descubrir la causa raíz, y en línea había muchos comandos tipo receta necesarios para recuperarlo, pero simplemente borré todo y volví a crear el clúster. Desde entonces hago eso cada pocas semanas. Supongo que un operador real de Kubernetes tendría automatización para actualizar certificados y muchas otras herramientas, pero si fuera una empresa tendría que pagarle a alguien así.
Sé que hay lugares que lo usan, pero comparado con sistemas maduros como Lustre o GPFS, termina siendo una enorme pérdida de tiempo. Es mejor exportar varios sistemas de archivos pequeños por NFS y garantizar la replicación a nivel de bloques. Un sistema de archivos con un único espacio de direcciones es cómodo, pero muchas veces no vale la pena asumir el costo administrativo de hacerlo estable a gran escala. Así como se hace sharding de bases de datos, también se puede hacer sharding del sistema de archivos, y en Kubernetes es fácil agregar lógica de mapeo para que el almacenamiento correcto se adjunte a la imagen correcta.
Permite reducir mucho la carga DevOps y, al mismo tiempo, obtener el rendimiento y la flexibilidad del bare metal. Es un excelente híbrido entre servicios caros totalmente administrados y construirlo todo por cuenta propia. Como tiene un costo considerable, quizá no sea una buena opción para startups, pero si se trata de un clúster con 72 GB de RAM o 36 CPU o más, algo así como 9 nodos medianos, definitivamente vale la pena considerar algo como OpenShift.
El problema de que los volúmenes de Hetzner sean demasiado lentos para bases de datos en producción se puede resolver de forma sorprendentemente sencilla: usar equipos bare metal muy baratos de Hetzner como nodos.
Los equipos con almacenamiento NVMe ofrecen muy buen rendimiento para bases de datos y suelen tener bastante RAM. En lugar de correr la base de datos en Kubernetes, puede ser incluso mejor tener dos o más equipos bare metal robustos para una configuración maestro-réplica. Si la configuración te resulta tediosa, puedes usar un paquete moderno como Pigsty: https://pigsty.cc/
Puedes fijar los pods de la base de datos a nodos específicos y usar LocalPathProvisioner, o usar soluciones distribuidas como JuiceFS u OpenEBS.
La guía que escribí para un cliente está aquí: https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal
He usado Hetzner con satisfacción durante más de 10 años; antes usaba servidores dedicados en sus centros de datos de Alemania, y luego migré a VM de Cloud US para reducir la latencia hacia Estados Unidos.
Es un poco decepcionante que el generoso tráfico gratuito de 20 TB se haya reducido recientemente a 3 TB y que el TB adicional cueste €1.19, pero aun así parece tener una relación costo-beneficio mucho mejor que otros proveedores cloud de EE. UU. que evalué.
No elegiría Kubernetes necesariamente, pero migré con éxito mis despliegues existentes por SSH/Docker Compose a GitHub Actions y kamal-deploy.org. Es fácil de configurar y también tiene buenas herramientas de UX para monitorear apps desplegadas remotamente: https://servicestack.net/posts/kamal-deployments
Los centros de datos en Alemania todavía ofrecen 20 TB de ancho de banda: https://www.hetzner.com/cloud/
Pero en EE. UU. ofrecen más de un orden de magnitud menos por el mismo precio.
Antes hacía yo mismo el mantenimiento del auto para ahorrar dinero y porque era divertido, pero resultó más complicado de lo esperado y, con el tiempo, se iban rompiendo o quebrando cosas por todos lados.
Pasé mucho tiempo “arreglando de nuevo”, y en unos años probablemente gasté miles de dólares en herramientas. También estaba el costo de reemplazar herramientas baratas que se rompían o se oxidaban rápido, y el auto muchas veces quedaba subido en soportes. Aun así aprendí muchas lecciones valiosas; la más importante fue que hay cosas que no vale la pena hacer uno mismo. Si tu sustento depende de eso, conviene dejarlo en manos de un mecánico o hacer leasing de un auto.
Incluso algo simple como cambiar el aceite casi no vale la pena hacerlo uno mismo. Hay que comprar herramientas como una bandeja para aceite, una llave para filtro, un embudo y una camilla de mecánico; hacerse tiempo; buscar ropa de trabajo sucia; ir a la tienda a comprar aceite y filtro nuevos; volver a casa y hacer el cambio; y luego, ese mismo día u otro, ir a una tienda que reciba el aceite usado. En cambio, en un taller pagas unos 15 dólares más que el costo del aceite y el filtro, y en 20 minutos está listo.
Kubernetes es un auto completo, y además uno complejo. Si no lo haces por diversión, realmente no vale la pena mantenerlo tú mismo.
Es una recompensa bastante buena y una habilidad que vale la pena aprender. Que mi vecino tuviera un elevador para autos definitivamente ayudó.
La clave es encontrar el equilibrio entre lo que haces tú mismo y lo que tercerizas, y no es tan fácil ni tan limpio como se plantea aquí.
Desde la perspectiva de un consultor que trabaja frecuentemente con Kubernetes, conviene asegurarse de tener una vía de ayuda inicial y continua, pero también que internamente haya alguien con suficiente interés que aprenda junto con el proceso.
Los consultores y especialistas pueden ayudarte al inicio a evitar malas decisiones y a ahorrarte meses de darte contra la pared. Cuando también tienes que concentrarte en el negocio principal, no es fácil aprender en un tiempo razonable los rincones oscuros y trampas habituales de una tecnología o ecosistema. Recibe ayuda, pero aprende también a pescar y a encender fuego.
Es un artículo interesante, pero siento que falta una descripción de los workloads que corren en el clúster y sobre él.
Me gustaría saber cuántos nodos hay, cuánto tráfico reciben y cuáles son los requisitos de uptime y latencia. Y el monto absoluto del ahorro también importa. Ahorrar 75% de 100,000 dólares al mes y ahorrar 75% de 100 dólares al mes son cosas completamente distintas.
En la práctica, creo que 100,000 dólares al mes es el punto de inflexión. Son 1.2 millones de dólares al año.
Dar soporte adecuado a un despliegue bare metal sofisticado cuesta alrededor de 400,000 dólares al año en salarios de ingeniería, y aproximadamente 100,000 dólares al año en compromisos de centro de datos, depreciación de hardware y ancho de banda. Este tipo de personal normalmente también aporta mucho valor a otras partes del negocio mientras hace ese trabajo, así que el costo real puede ser menor. Entonces ahorrar 700,000 dólares al año es excelente, y cuanto mayor sea el gasto cloud equivalente, mucho más grande será la ventaja.
Durante más de 10 años, cuando trabajaba en web hosting, solíamos mandar a blackhole las IP de Hetzner por mal comportamiento.
Lo mismo pasaba con otros proveedores de VM baratos, y no tenía nada que ver con bases de datos geográficas: era puramente por el comportamiento. Si es barato, por algo es.
Me gustaban las funciones del producto, pero la reputación de las IP del nivel gratuito era terrible, y casi no se aceptaban correos, especialmente en Hotmail o Yahoo. Los servicios de hosting gratuito quedan inundados de spammers y estafadores, y los servicios baratos son parecidos, solo que en menor medida. Cuanto más caro es, menos se usa para fraude y spam.
AWS, Google, DigitalOcean, Linode, Contabo, etc. también alojan muchos ataques de fuerza bruta contra inicios de sesión y escaneos de vulnerabilidades comunes.
Trabajo en una consultora que ayuda a empresas a armar y proteger su infraestructura, y tenemos muchos clientes que operan Kubernetes en proveedores baratos como Hetzner, proveedores regionales de gama media y los tres grandes clouds como AWS/GCP/Azure.
También hay empresas de gobierno, finanzas y salud que no pueden o no quieren operar en clouds públicos, así que normalmente alojan on-premise.
Si Hetzner tiene un problema o falla una vez al mes, un proveedor de gama media lo tendrá una vez cada 2 o 3 meses, y lugares como AWS una vez cada 5 o 6 meses. Dicho eso, el precio también se mueve más o menos en línea con esa observación, así que hay que evaluar con cuidado caso por caso si agregar más equipos, backups y escenarios de falla es un mejor trato.
Una gran ventaja de usar servicios de hosting básicos es que la previsibilidad de costos es mucho mayor. Pagas el equipo y escalas según lo necesites. Si quedas atado a los servicios adicionales de un proveedor como AWS, puedes recibir facturas enormes e inesperadas, y además salir de ahí se vuelve mucho más difícil. Si eres una empresa chica, conviene no dejarse tentar al principio por soluciones fáciles o “créditos gratuitos” y tomar decisiones cortoplacistas que amenacen la viabilidad a largo plazo.
No hay una respuesta correcta aquí, solo compromisos.
No lo he usado personalmente, pero https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner se ve como una excelente forma de configurar y administrar Kubernetes en Hetzner.
Ahora estoy usando el nivel gratuito de Oracle, pero sigo pensando en moverme a esto para salir de Oracle.
Funciona bastante bien. También tengo un cronograma para reiniciar las máquinas todos los domingos para actualizaciones automáticas de seguridad en SuSE MicroOS. Ya probé escalar máquinas conforme aumenta la carga de trabajo. Hay que revisar obligatoriamente todos los cambios que Terraform quiere hacer, pero si lo haces, es bastante seguro.
La única desventaja es que todos los nodos necesitan una IP pública aunque estén detrás de un firewall, pero están trabajando en eso.
En una noche ya tenía el clúster funcionando y anda bastante bien. Un pequeño problema fue que las actualizaciones automáticas no se ejecutaban en nodos arm; en ese momento solo estaba corriendo un único nodo y, por el taint del plano de control, el pod de actualización no podía ejecutarse y quedaba atascado.
https://github.com/syself/cluster-api-provider-hetzner
Funciona de forma muy estable.
Me da curiosidad si hay alguna molestia concreta que te haga querer mudarte.
No creo que sea correcto decir que DigitalOcean, como otros proveedores, ofrece un plano de control administrado gratuito pero normalmente aplica un markup del 100% a los nodos del clúster administrado.
En DigitalOcean, el costo de los nodos worker es el mismo que el de Droplets normales y no hay costo adicional. Por eso la propuesta de DigitalOcean es bastante atractiva: un plano de control gratuito del que no tienes que preocuparte, upgrades gratuitos e integraciones adicionales como balanceadores de carga y almacenamiento. No se me ocurre una buena razón para no elegirlo frente a administrarlo uno mismo.
La CPU compartida con 8 GB de RAM de Hetzner cuesta unos 10 dólares, y el equivalente de DigitalOcean cuesta 48 dólares.
Si quieres una experiencia administrada en Hetzner, puedes mirar https://syself.com. Trabajo para esa empresa.