Réduire de 75 % les coûts d’infrastructure en utilisant Kubernetes chez Hetzner

Hetzner

• La migration vers Hetzner a été motivée principalement par la réduction des coûts. Les tarifs de Hetzner sont compétitifs à l’échelle mondiale.
• Hetzner propose des machines virtuelles et des serveurs bare metal ; l’offre est plus limitée que celle d’AWS, mais cela est compensé par les prix.
• La migration vers Hetzner a permis de réduire les coûts d’infrastructure de plus de 75 %.

Kubernetes sur Hetzner

Kubernetes autogéré

• Kubernetes était exploité sur DigitalOcean, et il l’est également sur Hetzner en mode autogéré.
• Hetzner ne fournit pas de control plane Kubernetes managé, il faut donc le gérer soi-même.
• Les nœuds sont gérés et configurés avec Terraform et Puppet.

Rôles des nœuds

• Une convention de nommage des nœuds permet de garder des rôles simples dans le cluster : control-plane, worker, database.
• Ajouter des rôles est simple, mais cela peut nuire à l’efficacité de l’utilisation des ressources.

Mise en place des nœuds

• Le cluster est bootstrapé avec Terraform.
• Hetzner fournit un pare-feu managé et des fonctions de réseau, faciles à configurer avec Terraform.
• Les serveurs sont entièrement gérés avec Terraform, et des modules par rôle rendent l’ajout de serveurs plus simple.

Réseau

• Les connexions d’administration aux nœuds passent par le VPN Tailscale.
• Tailscale fournit du NAT hole punching, ce qui permet de se connecter en toute sécurité même en fermant les ports.
• Les ports sont bloqués à l’aide du pare-feu managé de Hetzner et de l’UFW d’Ubuntu.
• Calico est utilisé pour configurer l’interface réseau des conteneurs.

Stockage

• Hetzner propose du stockage bloc sur SSD ainsi que des SSD nVME.
• Les volumes Hetzner n’ont pas de fonction de snapshot, les sauvegardes des données doivent donc être effectuées manuellement.
• Sur les nœuds de base de données, le Local Persistence Volume Static Provisioner est utilisé pour préprovisionner les volumes locaux.

Sauvegardes

• Hetzner ne propose pas de sauvegarde des volumes, mais fournit des sauvegardes complètes des serveurs.
• VMware Velero est utilisé pour sauvegarder les namespaces et les PVC.
• Pour Postgres, pgBackRest est utilisé.

Fonctionnalités supplémentaires

• Utilisation de SealedSecrets pour la gestion des secrets.
• Utilisation de Node Exporter, Prometheus, Grafana et Loki pour la supervision du cluster.
• Utilisation d’Alertmanager pour l’intégration des alertes avec Slack.

Réflexions sur l’exploitation de Kubernetes chez Hetzner

• La migration vers Hetzner a pris environ une semaine, avec quatre semaines supplémentaires de tests et d’ajustements.
• Les tarifs de Hetzner sont raisonnables, et il est probable qu’ils restent inférieurs à ceux des autres fournisseurs.
• Hetzner présente des limites liées à la qualité des IP et au service client.
• Hetzner déploie rapidement de nouvelles fonctionnalités, mais peut aussi arrêter rapidement les services peu rentables.
• Les datacenters d’Europe centrale sont situés à Falkenstein et Nuremberg en Allemagne, ainsi qu’à Helsinki en Finlande.

Résumé

• La transition s’est déroulée sans heurts, en réduisant les coûts d’infrastructure de plus de 75 % tout en doublant les ressources de calcul du cluster.
• Hetzner est un choix très avantageux lorsqu’il est nécessaire de réduire les coûts.
• Les contrôleurs open source de Hetzner facilitent la gestion des load balancers et l’attachement persistant des volumes.

[GN⁺]

Réactions sur Hacker News

• Souligne l’absence de toute mention de durabilité ou de « green hosting », en précisant que les data centers européens de Hetzner utilisent de l’énergie verte, contrairement à ceux des États-Unis
• Partage une expérience d’exploitation d’un cluster Kubernetes chez Hetzner, en expliquant que le coût peut tomber à environ 20 % de celui d’AWS, mais avec de nombreux compromis en contrepartie
  • Il fallait gérer soi-même les mises à jour du cluster Kubernetes, subir divers bugs de Ceph et de Kubernetes, et cela demandait beaucoup de travail et de supervision
  • Utiliser un grand fournisseur cloud comme AWS réduit la charge opérationnelle grâce aux services managés
  • Hetzner est peu coûteux, mais le temps supplémentaire passé sur les tâches DevOps peut annuler les économies réalisées
• Partage une ancienne expérience d’hébergement web où des IP de Hetzner avaient été bloquées, en évoquant les problèmes associés aux fournisseurs de VM bon marché
• Partage une idée de réduction des coûts liée à Kubernetes, en proposant de configurer un cluster mêlant des nœuds on-premise et des nœuds chez un fournisseur cloud
  • Le coût de l’egress serait probablement la variable principale
• Estime qu’il manque des explications sur le cluster et les charges de travail, et aimerait connaître l’ampleur absolue des économies réalisées
• Recommande un projet GitHub pour configurer et administrer Kubernetes chez Hetzner
• Partage une expérience d’interruption d’un serveur de jeu à cause de problèmes dans le système de support de Hetzner, et appelle à la prudence
• Partage une expérience d’implémentation d’un opérateur léger pour intégrer le load balancer de Hetzner à Kubernetes, et présente le projet associé
• Explique avoir réduit ses coûts de 75 % en passant de Heroku à DigitalOcean, et suppose qu’un passage à Hetzner aurait permis d’atteindre 93 % d’économies
• Corrige une idée reçue sur le cluster managé de DigitalOcean, en précisant que le coût des nœuds ne s’ajoute pas, et souligne l’attractivité de DigitalOcean