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.
1 comentários
Opiniões no Hacker News
Há alguns anos venho fornecendo clusters Kubernetes para clientes em servidores dedicados da Hetzner, e o desempenho é claramente excelente, normalmente reduzindo o tempo de requisição pela metade
Como o hardware é barato, também dá para oferecer horas de engenharia DevOps dedicadas por cliente, mas há algumas premissas. Um cluster de staging para testar atualizações é praticamente obrigatório, e ninguém quer empurrar atualizações de produção no domingo no chute. A replicação no nível da aplicação é o mais importante, seguida pela replicação no nível de bloco; estamos usando OpenEBS/Mayastor. Depois de testar vários operadores de Postgres, hoje considero o StackGres o melhor
Playbooks Ansible são ativos; se forem bem organizados e comentados para um serviço específico, fica mais fácil reimplantar o mesmo serviço em outro lugar mais tarde. Se possível, recomendo uma rede 10G dedicada para interconexão dos servidores. 1G não é suficiente quando tráfego de produção, pull de imagens e tráfego entre serviços se somam, e a latência melhora 10 vezes em relação à comunicação interna de zonas de disponibilidade como as da AWS
Se for necessária redundância de rede, basta criar um vSwitch (VLAN) interno de 1G na porta 1G, atribuir um IP de loopback a cada servidor e distribuir as rotas via BGP (bird). Um cluster MinIO, operado da forma padrão por meio do operador, não é tão difícil e fornece armazenamento de objetos local com alta largura de banda e baixa latência. O investimento inicial exige algo como 2 a 4 meses de tempo de engenharia experiente e sem interrupções, e trabalhos auxiliares e chatos, como balanceamento de carga HTTP, ainda podem ser repassados a provedores de nuvem como a CloudFlare
Na documentação pública há uma opção de uplink 10G, mas é para rede externa, e o limite de 20 TB parece bem apertado. Para entrada e saída internas de um cluster, 20 TB pode facilmente virar um problema
Trabalho nessa empresa e criamos uma plataforma que fornece clusters prontos para produção em poucos minutos
Se você for uma consultoria, vai querer vender esse trabalho, mas, do ponto de vista do cliente, isso não parece ter valor algum a menos que o custo mensal esperado com AWS seja algo como 10 mil dólares. Lembro deste xkcd: https://xkcd.com/1319/
Já operei clusters Kubernetes em servidores dedicados da Hetzner e também trabalhei com serviços totalmente ou altamente gerenciados, como Aurora, S3 e ECS Fargate
Pela minha experiência, a fatura de nuvem da Hetzner às vezes cai para 20% do equivalente na AWS, mas essa vantagem de custo vem com grandes concessões
No Kubernetes na Hetzner, gerenciei um cluster Ceph baseado em armazenamento NVMe, um operador MariaDB, Cilium para rede e ArgoCD para implantação de Helm charts. Também precisei cuidar diretamente das atualizações do cluster Kubernetes e, certa vez, passei até por uma falha do cluster inteiro. Encontrei vários bugs tanto no Kubernetes quanto no Ceph, muitos deles registrados em issues do GitHub e no tracker do Ceph. A lista de tarefas a gerenciar e monitorar era interminável e, dependendo da quantidade de workloads e da complexidade do ambiente, manter uma configuração dessas pode se tornar um trabalho em tempo integral para uma equipe de DevOps
Por outro lado, usando AWS ou outro grande provedor de nuvem, é possível ter uma configuração que exige muito menos intervenção. Serviços gerenciados reduzem bastante o esforço de manutenção e também diminuem a carga operacional da equipe. No fim, a AWS reduz bastante a carga de trabalho de DevOps, e a Hetzner reduz bastante a fatura de nuvem. Qual lado é mais eficiente em custo exige uma análise de custo total de propriedade (TCO); mesmo que a Hetzner pareça barata no começo, o tempo adicional de DevOps pode anular a economia
Como exemplo, se comparar uma configuração de 2 vCPU e 4 GB com uma configuração parecida na AWS, a AWS é muito mais cara; eu gostaria de ver a análise de custos. Também há esta ferramenta para reduzir a carga operacional: https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner
Nem foi fácil descobrir a causa raiz, e na internet havia muitos comandos meio mágicos necessários para a recuperação, mas simplesmente apaguei tudo e recriei o cluster. Desde então faço isso a cada poucas semanas. Um operador Kubernetes de verdade provavelmente teria atualização automática de certificados e várias outras ferramentas, mas, para uma empresa, imagino que seja preciso pagar por esse operador
Sei que há lugares que usam, mas, comparado a sistemas maduros como Lustre ou GPFS, vira uma enorme perda de tempo. É melhor expor vários sistemas de arquivos pequenos via NFS e garantir replicação no nível de bloco. Um sistema de arquivos com espaço de endereçamento único é conveniente, mas muitas vezes não vale o custo de gestão para torná-lo confiável em grande escala. Assim como se faz sharding de bancos de dados, também dá para fazer sharding de sistemas de arquivos, e é fácil adicionar lógica de mapeamento no Kubernetes para que o armazenamento correto seja anexado à imagem correta
Dá para obter tanto o desempenho e a flexibilidade do bare metal quanto uma redução muito maior da carga de DevOps. É um ótimo híbrido entre serviços totalmente gerenciados e caros e uma construção totalmente manual. Tem um custo considerável, então talvez não seja uma boa escolha para startups, mas, para um cluster com 72 GB de RAM ou 36 CPUs ou mais, algo como 9 nós de porte médio, definitivamente vale considerar algo como OpenShift
O problema de os volumes da Hetzner serem lentos demais para bancos de dados em produção pode ser resolvido de forma surpreendentemente simples: basta usar máquinas bare metal bem baratas da Hetzner como nós.
Máquinas com armazenamento NVMe têm ótimo desempenho para bancos de dados e muitas vezes também bastante RAM. Em vez de rodar o banco de dados no Kubernetes, pode até ser melhor manter duas ou mais máquinas bare metal robustas para uma configuração mestre-réplica. Se a configuração for trabalhosa, dá para usar um pacote moderno como o Pigsty: https://pigsty.cc/
Você pode fixar os pods do banco de dados em nós específicos e usar o LocalPathProvisioner, ou usar soluções distribuídas como JuiceFS e OpenEBS.
O guia que escrevi para clientes está aqui: https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal
Uso a Hetzner com satisfação há mais de 10 anos; antes usava servidores dedicados em data centers na Alemanha, mas migrei para VMs Cloud US para reduzir a latência nos EUA.
Foi um pouco decepcionante ver o generoso tráfego gratuito de 20 TB cair para 3 TB, com €1,19 por TB adicional, mas ainda parece ter um custo-benefício muito melhor do que outros provedores de nuvem nos EUA que avaliei.
Eu não escolheria necessariamente Kubernetes, mas migrei com sucesso meus deploys antigos via SSH/Docker Compose para GitHub Actions e kamal-deploy.org. A configuração é fácil e as ferramentas de UX para monitorar apps implantados remotamente também são boas: https://servicestack.net/posts/kamal-deployments
Os data centers alemães ainda oferecem 20 TB de banda: https://www.hetzner.com/cloud/
Mas nos EUA, pelo mesmo preço, é mais de uma ordem de grandeza menor.
Antigamente eu fazia a manutenção do meu carro por conta própria para economizar dinheiro e porque era divertido, mas era mais complicado do que parecia, e com o tempo várias coisas quebravam ou se danificavam.
Passei muito tempo “consertando de novo” e devo ter gasto milhares de dólares em ferramentas ao longo de alguns anos. Também havia o custo de substituir ferramentas baratas que quebravam ou enferrujavam rápido, e o carro frequentemente ficava em cima de cavaletes. Ainda assim, aprendi muitas lições excelentes; a principal foi que algumas coisas não valem a pena fazer por conta própria. Se disso depende o seu sustento, é melhor deixar com um mecânico ou fazer leasing do carro.
Mesmo algo simples como trocar óleo quase não vale a pena fazer sozinho. É preciso comprar ferramentas como bandeja para óleo, chave de filtro, funil e carrinho de mecânico, reservar tempo, achar roupas de trabalho sujas, ir à loja comprar óleo e filtro novos, voltar para casa e fazer a troca, e depois levar o óleo usado a uma loja que o aceite naquele dia ou em outro. Já numa oficina, você paga cerca de 15 dólares a mais do que o custo do óleo e do filtro, e em 20 minutos está pronto.
Kubernetes é um carro inteiro, e ainda por cima um carro complexo. Se não for por diversão, realmente não vale a pena manter por conta própria.
É uma recompensa bem boa e uma habilidade que vale a pena aprender. Ter um elevador automotivo no vizinho certamente ajudou.
O ponto é encontrar o equilíbrio entre o que fazer por conta própria e o que terceirizar, e isso não é tão fácil nem tão simples quanto parece aqui.
Do ponto de vista de um consultor que trabalha frequentemente com Kubernetes, é bom garantir uma fonte de ajuda inicial e contínua, mas também ter alguém internamente com interesse suficiente para aprender junto.
Consultores e especialistas podem ajudar a evitar decisões ruins no começo e poupar meses batendo a cabeça na parede. Quando também é preciso focar no negócio principal, não é fácil aprender, em um prazo razoável, os cantos obscuros e armadilhas comuns de uma tecnologia ou ecossistema. Receba ajuda, mas também aprenda a pescar e a acender o fogo.
É um texto interessante, mas parece faltar uma descrição dos workloads do cluster e do que roda sobre ele.
Fico curioso para saber quantos nós há, quanto tráfego recebem e quais são os requisitos de uptime e latência. E a economia absoluta também importa. Economizar 75% de 100 mil dólares por mês é completamente diferente de economizar 75% de 100 dólares por mês.
Na prática, vejo 100 mil dólares por mês como o ponto de inflexão. São 1,2 milhão de dólares por ano.
Para dar suporte adequado a uma implantação bare metal sofisticada, você gasta cerca de 400 mil dólares por ano em salários de engenharia, e aproximadamente 100 mil dólares por ano com compromissos de data center, depreciação de hardware e banda. Como esse pessoal geralmente também gera grande valor em outras partes do negócio enquanto faz esse trabalho, o custo real pode ser menor. Assim, economizar 700 mil dólares por ano é excelente; e quanto maior for o gasto equivalente em nuvem, muito maiores ficam as vantagens.
Há mais de 10 anos, quando eu trabalhava com hospedagem web, eu costumava blackholear IPs da Hetzner por causa de mau comportamento
O mesmo valia para outros provedores de VMs baratas, e isso não tinha nada a ver com bancos de dados geográficos; era puramente por comportamento. Se é barato, há um motivo
Gostei dos recursos do produto, mas a reputação dos IPs do tier gratuito era terrível, e os e-mails quase nunca eram aceitos, especialmente pelo Hotmail ou Yahoo. Serviços de hospedagem gratuitos são dominados por spammers e golpistas, e serviços baratos são parecidos, só em menor grau. Quanto mais caro, menos é usado para fraude e spam
AWS, Google, DigitalOcean, Linode, Contabo etc. também hospedam muitos ataques de força bruta em login e varreduras de vulnerabilidades comuns
Trabalho em uma consultoria que ajuda empresas a montar infraestrutura e segurança, e temos muitos clientes rodando Kubernetes em provedores baratos como a Hetzner, provedores regionais intermediários e nos três grandes clouds como AWS/GCP/Azure
Também há empresas de governo, finanças e saúde que não podem ou não querem operar em nuvem pública, então normalmente hospedam on-premises
Se a Hetzner tem um problema ou falha uma vez por mês, um provedor intermediário tem a cada 2 ou 3 meses, e lugares como a AWS a cada 5 ou 6 meses. Mas o preço também se move de forma parecida com essa observação, então é preciso avaliar cuidadosamente caso a caso se adicionar mais equipamentos, backups e cenários de falha é um negócio melhor
Uma grande vantagem de usar serviços básicos de hospedagem é que a previsibilidade de custos é muito maior. Você paga pelo hardware e escala conforme necessário. Se ficar preso aos serviços complementares de provedores como a AWS, pode receber contas inesperadamente altas, e também fica muito mais difícil sair. Se você é uma empresa pequena, é melhor não se deixar seduzir por soluções fáceis no início ou por “créditos gratuitos” e tomar decisões míopes que ameacem sua sobrevivência no longo prazo
Não há resposta certa aqui, apenas trade-offs
Não usei pessoalmente, mas https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner parece uma ótima forma de configurar e gerenciar Kubernetes na Hetzner
Atualmente uso o tier gratuito da Oracle, mas continuo pensando em migrar para isso para sair da Oracle
Funciona muito bem. Também tenho uma agenda para reiniciar as máquinas todo domingo para atualizações automáticas de segurança no SuSE MicroOS. Também já escalei máquinas conforme o aumento de workload. É preciso revisar todas as mudanças que o Terraform pretende fazer, mas, se fizer isso, é bem seguro
A única desvantagem é que todos os nós precisam de IP público, mesmo estando atrás de um firewall, mas isso está sendo trabalhado
O cluster estava funcionando em uma noite e funciona muito bem. Um pequeno problema foi que as atualizações automáticas não rodaram nos nós arm; naquele momento eu estava rodando apenas um único nó, e por causa do taint do control plane o pod de atualização não conseguiu executar e ficou travado
https://github.com/syself/cluster-api-provider-hetzner
Funciona de forma muito estável
Fiquei curioso se há algum incômodo específico que faça você querer migrar
Não acho correto dizer que a DigitalOcean oferece control plane gerenciado gratuito como outros provedores, mas normalmente aplica um markup de 100% nos nós do cluster gerenciado
Na DigitalOcean, o custo dos worker nodes é igual ao de Droplets comuns, sem custo adicional. Por isso, a oferta da DigitalOcean é bem atraente. Há um control plane gratuito com o qual você não precisa se preocupar, upgrades gratuitos e integrações adicionais como balanceadores de carga e armazenamento. Não vejo muitos motivos para escolher gerenciar isso por conta própria em vez disso
A CPU compartilhada de 8 GB de RAM da Hetzner custa cerca de US$ 10, enquanto o equivalente da DigitalOcean custa US$ 48
Se você quer uma experiência gerenciada na Hetzner, pode dar uma olhada em https://syself.com. Trabalho nessa empresa