Reduzindo os custos de infraestrutura em 75% com Kubernetes na Hetzner

Hetzner

• A migração para a Hetzner teve como principal objetivo reduzir custos. Os preços da Hetzner são competitivos em nível global.
• A Hetzner oferece máquinas virtuais e servidores bare metal e, embora seja mais limitada que a AWS, compensa isso no preço.
• Com a migração para a Hetzner, os custos de infraestrutura foram reduzidos em mais de 75%.

Kubernetes na Hetzner

Kubernetes autogerenciado

• O Kubernetes era operado na DigitalOcean e, na Hetzner, também passou a ser operado de forma autogerenciada.
• A Hetzner não oferece um control plane de Kubernetes gerenciado, então é necessário administrá-lo diretamente.
• Terraform e Puppet são usados para gerenciar e configurar os nós.

Papéis dos nós

• Usa-se uma convenção de nomenclatura dos nós para manter os papéis no cluster simples: control-plane, worker, database.
• Adicionar papéis é simples, mas pode prejudicar a eficiência no uso de recursos.

Provisionamento dos nós

• O cluster é inicializado com Terraform.
• A Hetzner oferece firewall e rede gerenciados, que podem ser configurados facilmente com Terraform.
• Os servidores são totalmente gerenciados com Terraform, e módulos por função tornam simples adicionar novos servidores.

Rede

• O Tailscale VPN é usado para conexões administrativas com os nós.
• O Tailscale oferece NAT hole punching, permitindo conexões seguras mesmo com as portas fechadas.
• As portas são bloqueadas usando o firewall gerenciado da Hetzner e o UFW do Ubuntu.
• O Calico é usado para configurar a interface de rede de contêineres.

Armazenamento

• A Hetzner oferece nVME SSD e armazenamento em bloco baseado em SSD.
• Os volumes da Hetzner não têm recurso de snapshot, então o backup dos dados precisa ser feito manualmente.
• Nos nós de banco de dados, usa-se o Local Persistence Volume Static Provisioner para pré-provisionar volumes locais.

Backup

• A Hetzner não oferece backup de volumes, mas oferece backup do servidor inteiro.
• O Velero, da VMware, é usado para fazer backup de namespaces e PVCs.
• No caso do Postgres, é usado o pgBackRest.

Recursos adicionais

• SealedSecrets para gerenciamento de segredos.
• Node Exporter, Prometheus, Grafana e Loki para monitoramento do cluster.
• Alertmanager para integração de alertas com o Slack.

Opiniões sobre operar Kubernetes na Hetzner

• A migração para a Hetzner levou cerca de 1 semana, e testes e ajustes adicionais levaram 4 semanas.
• Os preços da Hetzner são razoáveis, e acredita-se que continuarão mais baixos que os de outros provedores.
• Há limitações relacionadas à qualidade dos IPs da Hetzner e ao atendimento ao cliente.
• A Hetzner lança novos recursos rapidamente, mas também pode descontinuar rapidamente serviços com baixa rentabilidade.
• Os data centers na Europa Central ficam em Falkenstein e Nuremberg, na Alemanha, e em Helsinki, na Finlândia.

Resumo

• A transição ocorreu sem problemas, reduziu os custos de infraestrutura em mais de 75% e dobrou os recursos computacionais do cluster.
• A Hetzner é uma escolha muito vantajosa quando há necessidade de reduzir custos.
• O controlador open source da Hetzner facilita o gerenciamento de load balancers e a conexão contínua de volumes.

[GN⁺]

Comentários do Hacker News

• Aponta a ausência de qualquer menção à sustentabilidade ou a "green hosting", observando que os data centers europeus da Hetzner usam energia limpa, mas os dos EUA não
• Compartilha a experiência de operar um cluster Kubernetes na Hetzner e explica que o custo pode cair para cerca de 20% do da AWS, mas com muitos trade-offs em troca
  • Destaca que foi preciso gerenciar manualmente as atualizações do cluster Kubernetes, que enfrentou vários bugs no Ceph e no Kubernetes, e que isso exigiu muito trabalho e monitoramento
  • Usar grandes provedores de nuvem como a AWS reduz a carga operacional graças aos serviços gerenciados
  • Explica que a Hetzner é barata, mas o tempo extra gasto em trabalho de DevOps pode anular essa economia
• Compartilha uma experiência passada de ter bloqueado IPs da Hetzner em um contexto de hospedagem web, mencionando problemas associados a provedores baratos de VM
• Compartilha uma ideia de redução de custos relacionada ao Kubernetes, propondo configurar um cluster misturando nós on-premises com nós de provedores de nuvem
  • Acredita que o custo de egress será a principal variável
• Diz sentir falta de uma explicação melhor sobre o cluster e as cargas de trabalho, e comenta que gostaria de saber o tamanho absoluto da economia obtida
• Recomenda um projeto no GitHub como forma de configurar e gerenciar Kubernetes na Hetzner
• Compartilha uma experiência em que um servidor de jogos ficou fora do ar por causa de problemas no sistema de suporte da Hetzner e faz um alerta
• Compartilha a experiência de ter implementado um operador enxuto para integrar o load balancer da Hetzner ao Kubernetes e apresenta o projeto relacionado
• Diz que, ao migrar do Heroku para a DigitalOcean, obteve uma redução de custos de 75%, e especula que teria conseguido 93% se tivesse migrado para a Hetzner
• Corrige um mal-entendido sobre o cluster gerenciado da DigitalOcean, explicando que o custo dos nós não é cobrado à parte, e destaca a atratividade da DigitalOcean