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,
pgBackRestest 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.
1 commentaires
Commentaires sur Hacker News
Pendant plusieurs années, j’ai fourni à des clients des clusters Kubernetes sur des serveurs dédiés de Hetzner, et les performances sont clairement excellentes, avec des temps de réponse généralement réduits de moitié
Le matériel est bon marché, ce qui permet même d’inclure du temps d’ingénierie DevOps dédié pour chaque client, mais cela repose sur quelques prérequis. Un cluster de staging pour tester les mises à jour est pratiquement indispensable, et personne ne veut pousser des mises à jour en production à l’aveugle un dimanche. La réplication au niveau applicatif est la plus importante, suivie par la réplication au niveau bloc, et nous utilisons OpenEBS/Mayastor. Après avoir testé plusieurs opérateurs Postgres, nous estimons actuellement que StackGres est le meilleur
Les playbooks Ansible sont un actif : s’ils sont bien organisés et commentés pour un service donné, il devient facile de redéployer le même service ailleurs plus tard. Si possible, je recommande un réseau dédié 10G pour relier les serveurs. Le 1G ne suffit pas une fois combinés le trafic de production, les pulls d’images et le trafic inter-services, et la latence est 10 fois meilleure que la communication intra-zone de disponibilité chez AWS
Si vous avez besoin de redondance réseau, il suffit de créer un vSwitch 1G interne (VLAN) sur le port 1G, d’attribuer une IP loopback à chaque serveur, puis d’annoncer les routes via BGP (bird). Un cluster MinIO n’est pas si difficile à exploiter si on suit les bonnes pratiques via l’opérateur, et il fournit un stockage objet local à très haut débit et faible latence. L’investissement initial demande environ 2 à 4 mois de temps d’ingénierie qualifié, sans interruption, et vous pouvez toujours confier les tâches annexes et pénibles, comme l’équilibrage de charge HTTP, à un fournisseur cloud comme CloudFlare
La documentation publique mentionne une option d’uplink 10G, mais elle semble destinée au réseau externe, et la limite de 20 To paraît assez contraignante. Pour des E/S internes au cluster, 20 To pourraient vite devenir un problème
J’y travaille, et nous avons créé une plateforme qui fournit en quelques minutes des clusters prêts pour la production
Une société de conseil voudra sans doute vendre ce travail, mais du point de vue d’un client, cela ne semble pas du tout rentable à moins de prévoir environ 10 000 dollars par mois de facture AWS. Ça me fait penser à xkcd : https://xkcd.com/1319/
J’ai déjà exploité des clusters Kubernetes sur des serveurs dédiés Hetzner, et j’ai aussi travaillé avec des services entièrement ou fortement managés comme Aurora, S3 et ECS Fargate
D’après mon expérience, la facture cloud chez Hetzner peut parfois tomber à 20 % de l’équivalent sur AWS, mais cet avantage de coût s’accompagne de compromis importants
Sur Kubernetes chez Hetzner, j’ai géré un cluster Ceph sur stockage NVMe, un opérateur MariaDB, Cilium pour le réseau et ArgoCD pour le déploiement de charts Helm. Il fallait aussi gérer soi-même les mises à jour du cluster Kubernetes, et j’ai même vécu une panne complète du cluster une fois. J’ai rencontré de nombreux bugs à la fois dans Kubernetes et dans Ceph, dont beaucoup étaient déjà documentés dans des issues GitHub et sur le tracker Ceph. La liste des tâches à gérer et à surveiller ne finissait jamais, et selon le nombre de workloads et la complexité de l’environnement, maintenir une telle configuration peut devenir un travail à plein temps pour une équipe DevOps
À l’inverse, avec AWS ou un autre grand fournisseur cloud, il est possible d’avoir une configuration bien moins exigeante en interventions manuelles. Les services managés réduisent fortement l’effort de maintenance et donc la charge opérationnelle de l’équipe. En fin de compte, AWS réduit fortement la charge de travail DevOps, tandis que Hetzner réduit fortement la facture cloud. Pour savoir quelle option est la plus rentable, il faut faire une analyse du coût total de possession (TCO), car même si Hetzner paraît moins cher au départ, le temps DevOps supplémentaire peut annuler les économies
Par exemple, si l’on compare une configuration 2 vCPU, 4 Go avec une offre similaire chez AWS, AWS est bien plus cher, donc j’aimerais voir l’analyse de coûts. Il existe aussi des outils pour réduire la charge opérationnelle, comme https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner
Il n’a même pas été facile d’identifier la cause racine, et il y avait en ligne toutes sortes de commandes quasi magiques pour le réparer, mais j’ai simplement tout supprimé et recréé le cluster. Ensuite, je faisais ça toutes les quelques semaines. Un vrai opérateur Kubernetes aurait sans doute la mise à niveau automatique des certificats et beaucoup d’autres outils, mais dans une entreprise, il faudrait payer quelqu’un pour ce rôle
Je sais que certaines organisations l’utilisent, mais comparé à des systèmes matures comme Lustre ou GPFS, c’est une énorme perte de temps. Il vaudrait mieux exposer plusieurs petits systèmes de fichiers via NFS et garantir la réplication au niveau bloc. Un système de fichiers à espace d’adressage unique est pratique, mais bien souvent cela ne vaut pas le coût d’administration nécessaire pour le rendre fiable à grande échelle. Comme pour le sharding de bases de données, il vaut mieux aussi shard le système de fichiers, et il est facile d’ajouter dans Kubernetes une logique de mapping pour attacher le bon stockage à la bonne image
Cela réduit fortement la charge DevOps tout en offrant à la fois les performances et la flexibilité du bare metal. C’est un excellent hybride entre les services entièrement managés et coûteux, et une infrastructure entièrement autogérée. C’est assez cher, donc ce n’est peut-être pas un bon choix pour une startup, mais pour un cluster d’au moins 72 Go de RAM ou 36 CPU, soit environ 9 nœuds de taille intermédiaire, quelque chose comme OpenShift mérite vraiment d’être envisagé
Le problème selon lequel les volumes Hetzner sont trop lents pour une base de données de production se résout de façon étonnamment simple. Il suffit d’utiliser comme nœuds du matériel bare metal Hetzner très bon marché.
Les machines équipées de stockage NVMe offrent d’excellentes performances pour les bases de données et disposent souvent de beaucoup de RAM. Plutôt que d’exécuter la base de données dans Kubernetes, il peut même être préférable d’avoir au moins deux machines bare metal robustes en configuration maître-réplique. Si la configuration est pénible, on peut utiliser un paquet moderne comme Pigsty : https://pigsty.cc/
Il suffit d’épingler les pods de base de données à des nœuds spécifiques et d’utiliser LocalPathProvisioner, ou d’employer des solutions distribuées comme JuiceFS ou OpenEBS
Le guide rédigé pour un client est ici : https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal
J’utilise Hetzner avec satisfaction depuis plus de 10 ans, et j’utilisais auparavant des serveurs dédiés dans des datacenters allemands avant de passer aux VM Cloud US pour réduire la latence depuis les États-Unis
La récente réduction du trafic gratuit de 20 To à 3 To, avec un tarif de 1,19 € par To supplémentaire, est un peu décevante, mais cela reste de loin le meilleur rapport qualité-prix parmi les autres fournisseurs cloud américains que j’ai évalués
Je ne choisirais pas forcément Kubernetes, mais j’ai migré avec succès des déploiements SSH/Docker Compose existants vers GitHub Actions et kamal-deploy.org. La configuration est simple et les outils UX pour surveiller les apps déployées à distance sont aussi très bons : https://servicestack.net/posts/kamal-deployments
Les datacenters allemands offrent toujours 20 To de bande passante : https://www.hetzner.com/cloud/
Mais aux États-Unis, c’est bien moins pour le même prix
Avant, je faisais moi-même l’entretien de ma voiture pour économiser de l’argent et parce que c’était amusant, mais c’était plus complexe que prévu et, avec le temps, diverses choses ont lâché ou se sont cassées
J’ai passé beaucoup de temps à « réparer à nouveau » et j’ai probablement dépensé plusieurs milliers de dollars en outils au fil des ans. Il y avait aussi le coût de remplacement des outils bon marché qui se cassaient ou rouillaient vite, et la voiture se retrouvait souvent sur chandelles. Malgré tout, j’en ai tiré beaucoup d’excellentes leçons, la principale étant que certaines choses ne valent pas la peine d’être faites soi-même. Si votre gagne-pain en dépend, mieux vaut confier ça à un mécanicien ou prendre une voiture en leasing
Même une tâche simple comme une vidange ne vaut pas vraiment la peine d’être faite soi-même. Il faut acheter des outils comme un bac de vidange, une clé à filtre, un entonnoir ou un plateau d’atelier, libérer du temps, retrouver des vêtements de travail sales, aller au magasin acheter de l’huile et un filtre neufs, revenir chez soi, faire la vidange, puis apporter l’huile usagée le jour même ou un autre jour dans un magasin qui l’accepte. À l’inverse, dans un garage, pour environ 15 dollars de plus que le prix de l’huile et du filtre, c’est réglé en 20 minutes
Kubernetes, c’est une voiture entière, et en plus une voiture complexe. À moins de le faire pour le plaisir, cela ne vaut vraiment pas la peine de l’entretenir soi-même
C’est une récompense plutôt correcte et une compétence utile à apprendre. Le fait que mon voisin ait un pont élévateur aide clairement
L’essentiel est de trouver l’équilibre entre ce qu’on fait soi-même et ce qu’on externalise, et ce n’est ni aussi simple ni aussi net que ce qui est dit ici
Du point de vue d’un consultant qui intervient souvent sur Kubernetes, il vaut mieux avoir à la fois un point d’appui pour l’aide initiale et l’accompagnement dans la durée, tout en faisant apprendre le sujet en interne à quelqu’un de suffisamment motivé
Les consultants et experts permettent d’éviter de mauvaises décisions au départ et de réduire les mois passés à se cogner la tête contre les murs. Quand il faut aussi rester concentré sur le cœur du business, il n’est pas facile d’apprendre en un temps raisonnable les recoins sombres et pièges habituels d’une technologie ou d’un écosystème. Il faut se faire aider, mais aussi apprendre à pêcher et à faire du feu
Article intéressant, mais j’ai l’impression qu’il manque une description du cluster et des workloads qui tournent dessus
Combien y a-t-il de nœuds, quel volume de trafic reçoivent-ils, quelles sont les exigences en matière de disponibilité et de latence ? Et le montant absolu des économies compte aussi. Réduire de 75 % une facture mensuelle de 100 000 dollars ou de 100 dollars, ce n’est pas du tout la même chose
En pratique, je considère que 100 000 dollars par mois est le point de bascule. Cela fait 1,2 million de dollars par an
Pour prendre correctement en charge un déploiement bare metal sophistiqué, il faut compter environ 400 000 dollars par an en salaires d’ingénieurs, puis environ 100 000 dollars par an pour les engagements datacenter, l’amortissement du matériel et la bande passante. Comme ces profils apportent généralement aussi une forte valeur à d’autres aspects du business tout en faisant ce travail, le coût réel peut être plus faible. On économise alors 700 000 dollars par an, ce qui est excellent, et plus la dépense cloud équivalente dépasse ce niveau, plus l’avantage devient important
Il y a plus de 10 ans, quand je travaillais dans l’hébergement web, on blackholait régulièrement les IP de Hetzner à cause de mauvais comportements.
C’était pareil pour d’autres fournisseurs de VM low cost, sans rapport avec les bases de données de géolocalisation, uniquement à cause des abus. Si ce n’est pas cher, ce n’est pas sans raison.
Les fonctionnalités du produit me plaisaient, mais la réputation des IP du free tier était catastrophique, et les mails étaient très souvent refusés, surtout par Hotmail ou Yahoo. Les services d’hébergement gratuits sont submergés par les spammeurs et les escrocs, et les services low cost ne valent guère mieux, juste à un degré moindre. Plus c’est cher, moins c’est utilisé pour la fraude et le spam.
AWS, Google, DigitalOcean, Linode, Contabo, etc. hébergent aussi beaucoup d’attaques par force brute sur les connexions et de scans de vulnérabilités courantes.
Je travaille dans une société de conseil qui aide les entreprises à monter leur infrastructure et leur sécurité, et nous avons beaucoup de clients qui exploitent Kubernetes chez des fournisseurs low cost comme Hetzner, chez des acteurs régionaux de milieu de gamme, et sur les trois grands clouds comme AWS/GCP/Azure.
Il y a aussi des entreprises du public, de la finance ou de la santé qui ne peuvent pas, ou ne veulent pas, tourner sur le cloud public, donc elles sont généralement hébergées on-premises.
Si Hetzner a un incident ou une panne environ une fois par mois, chez les fournisseurs intermédiaires c’est plutôt une fois tous les 2 à 3 mois, et chez AWS ou équivalent plutôt tous les 5 à 6 mois. Cela dit, les prix suivent à peu près la même logique, donc il faut vraiment évaluer au cas par cas si ajouter davantage d’équipement, de sauvegardes et de scénarios de panne reste une meilleure affaire.
Le gros avantage des services d’hébergement basiques, c’est que la prévisibilité des coûts est bien meilleure. On paie le matériel et on scale selon ses besoins. Quand on se retrouve verrouillé dans les services annexes d’un fournisseur comme AWS, on peut recevoir de grosses factures inattendues, et il devient aussi beaucoup plus difficile d’en sortir. Pour une petite entreprise, mieux vaut éviter de prendre au début des décisions à courte vue, séduite par une solution simple ou des « crédits gratuits », au risque de compromettre sa survie à long terme.
Il n’y a pas de bonne réponse ici, seulement des compromis.
Je ne l’ai pas utilisé moi-même, mais https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner a l’air excellent pour configurer et gérer Kubernetes chez Hetzner.
En ce moment j’utilise le free tier d’Oracle, mais je pense régulièrement à migrer vers ça pour sortir d’Oracle.
Ça fonctionne plutôt bien. J’ai aussi planifié un redémarrage hebdomadaire des machines le dimanche pour appliquer les mises à jour de sécurité automatiques sur SuSE MicroOS. J’ai également déjà fait grossir les machines pour suivre l’augmentation de la charge. Il faut impérativement vérifier tous les changements que Terraform veut appliquer, mais en faisant ça, c’est assez sûr.
Le seul inconvénient, c’est que tous les nœuds ont besoin d’une IP publique même s’ils sont derrière un pare-feu, mais c’est en cours de traitement.
Le cluster tournait en une nuit et fonctionne plutôt bien. Le seul petit problème, c’est que les mises à jour automatiques ne s’exécutaient pas sur les nœuds arm à ce moment-là, parce qu’il n’y avait qu’un seul nœud en service et que le pod de mise à jour ne pouvait pas démarrer à cause du taint du control plane.
https://github.com/syself/cluster-api-provider-hetzner
Ça fonctionne de façon très stable.
Je me demande s’il y a des points de friction concrets qui te donnent envie de partir.
Je ne pense pas qu’il soit juste de dire que DigitalOcean, tout en proposant comme d’autres un control plane managé gratuit, applique généralement une majoration de 100 % sur les nœuds d’un cluster managé.
Chez DigitalOcean, les worker nodes coûtent le même prix que des Droplets classiques, sans surcoût. Du coup, leur offre est assez attractive. On a un control plane gratuit sans souci à gérer, des upgrades gratuits, ainsi que des intégrations supplémentaires comme le load balancing et le stockage. J’ai du mal à voir pourquoi on choisirait de gérer ça soi-même.
Un CPU partagé avec 8 Go de RAM chez Hetzner coûte environ 10 $, contre 48 $ pour l’équivalent chez DigitalOcean.
Si vous voulez une expérience managée sur Hetzner, vous pouvez regarder https://syself.com. Je travaille dans cette société.