Reduciendo 75% los costos de infraestructura usando Kubernetes en Hetzner

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.

[GN⁺]

Opiniones de Hacker News

• Señala que no se menciona la sostenibilidad ni el "hosting verde", y comenta que los centros de datos europeos de Hetzner usan energía ecológica, pero los de EE. UU. no
• Comparte su experiencia operando un clúster de Kubernetes en Hetzner, y explica que el costo puede ser tan bajo como un 20% del de AWS, pero con muchos trade-offs
  • Destaca que tuvo que gestionar por su cuenta las actualizaciones del clúster de Kubernetes, enfrentó varios bugs de Ceph y Kubernetes, y que eso requirió mucho trabajo y monitoreo
  • Usar grandes proveedores de nube como AWS reduce la carga operativa gracias a los servicios administrados
  • Explica que Hetzner es barato, pero el tiempo adicional dedicado a tareas de DevOps puede compensar ese ahorro
• Comparte una experiencia pasada en hosting web en la que bloqueó IPs de Hetzner, y menciona problemas asociados con proveedores de VM baratos
• Comparte una idea de ahorro de costos relacionada con Kubernetes, proponiendo configurar un clúster mezclando nodos on-premise con nodos de proveedores de nube
  • Cree que el costo de egress sería la variable principal
• Dice que siente que falta una explicación sobre el clúster y la carga de trabajo, y que le gustaría conocer el tamaño absoluto del ahorro logrado
• Recomienda un proyecto de GitHub como forma de configurar y administrar Kubernetes en Hetzner
• Comparte una experiencia en la que un servidor de juegos quedó caído por problemas con el sistema de soporte de Hetzner, y pide precaución
• Comparte su experiencia implementando un operador ligero para integrar los balanceadores de carga de Hetzner con Kubernetes, y presenta un proyecto relacionado
• Cambió de Heroku a DigitalOcean y logró una reducción de costos del 75%; especula que con Hetzner habría podido ahorrar un 93%
• Corrige un malentendido sobre los clústeres administrados de DigitalOcean, explicando que el costo de los nodos no se cobra por separado, y destaca el atractivo de DigitalOcean