1 points par GN⁺ 2025-08-16 | 1 commentaires | Partager sur WhatsApp
  • Edka permet aux utilisateurs de créer et de gérer facilement eux-mêmes un cluster Kubernetes dans leur compte Hetzner
  • Fournit un environnement offrant la simplicité d’un PaaS sans sacrifier la flexibilité
  • Intègre diverses fonctionnalités comme un workflow basé sur GitOps, l’installation d’add-ons en un clic et des fonctions de monitoring intégrées
  • Permet de simplifier les processus d’exploitation Kubernetes traditionnellement complexes
  • Offre aux startups et aux professionnels de l’IT une expérience de gestion autonome de plateforme

Présentation d’Edka

  • Edka est une plateforme qui permet aux utilisateurs de créer, faire évoluer et gérer des clusters Kubernetes dans leur propre compte Hetzner
  • Au lieu d’une configuration d’infrastructure complexe, il est possible d’automatiser la gestion de l’infrastructure via un workflow GitOps
  • Tout en conservant la simplicité d’un PaaS (Platform as a Service), la plateforme offre aussi l’évolutivité et la flexibilité de configuration

Principales caractéristiques

  • Add-ons en un clic : permet d’installer et d’appliquer divers add-ons Kubernetes en un seul clic
  • Monitoring intégré : permet de surveiller immédiatement l’état du cluster et l’utilisation des ressources sans outil supplémentaire
  • Montée en charge et gestion : permet d’ajuster facilement la taille du cluster et d’en assurer la gestion selon les besoins

Avantages et public visé

  • En supprimant la complexité traditionnelle de l’exploitation de Kubernetes, même les développeurs débutants peuvent gérer facilement l’infrastructure
  • Grâce à un service basé sur son propre compte, qui permet de contrôler directement les coûts, les risques de vendor lock-in sont réduits
  • Offre un environnement où les startups et les professionnels de l’IT peuvent gérer leurs clusters de manière autonome et mettre en place des workflows DevOps

1 commentaires

 
GN⁺ 2025-08-16
Avis Hacker News
  • Quelle chance totalement inattendue : j’ai même reçu des retours sur HN, j’ai été rate limited sur GitHub (vite réglé), puis Hetzner a eu quelques incidents, donc la création de nouveaux clusters ne fonctionnait pas correctement. Merci beaucoup à tous pour l’intérêt porté au projet. C’était un side project et je ne m’attendais absolument pas à ce que ça prenne cette ampleur. Je compte continuer à améliorer la plateforme et à intégrer les retours.
  • Je me demande quelle est la différence avec des outils déjà connus qui prennent en charge Hetzner, comme kops (https://github.com/kubernetes/kops).
    • L’outil le plus simple à l’heure actuelle est probablement https://github.com/vitobotta/hetzner-k3s. Il existe plusieurs options, selon le niveau de contrôle bas niveau que l’on veut avoir. Le projet Hetzner Terraform est l’option la plus complexe et la plus complète, mais il demande beaucoup de temps de configuration. L’idée principale ici est de simplifier non seulement le déploiement de Kubernetes sur Hetzner, mais aussi celui des applications nécessaires pour étendre les fonctionnalités Kubernetes, comme un ingress controller, Prometheus, Elasticsearch, des bases de données, etc.
    • Il y a aussi Talos, qui prend en charge Hetzner et qui est plutôt streamlined. Ce n’est pas exactement la même idée, mais c’est très proche. https://www.talos.dev/v1.10/talos-guides/install/cloud-platforms/hetzner
    • Je me demande quelle est la différence avec l’utilisation de https://github.com/vitobotta/hetzner-k3s.
    • Je suppose que la différence se situe au niveau de l’UI et du support commercial.
  • Ça a l’air d’être une façon vraiment intuitive de déployer un cluster k8s. Cela dit, cette solution repose sur les services cloud de Hetzner, et de notre côté nous avons eu une expérience un peu inquiétante sur cette partie cloud en production. Nos clients déploient sur l’offre bare metal de Hetzner, qui est elle très stable. Le problème le plus grave qu’on ait eu, ce sont des redémarrages occasionnels de routeurs, mais on s’en sort avec des déploiements multi-AZ. Pour des clusters en dessous d’une certaine taille, un déploiement bare metal sur mesure n’est ni rentable ni justifié en effort, donc je vais continuer à suivre ce projet.
  • Il existe aussi un projet pour déployer k3s sur Hetzner avec Terraform : https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner. Ce n’était pas l’expérience la plus fluide du monde, mais tout est self-hosted, et on peut résoudre la plupart des problèmes via Terraform ou SSH. Ça fait plaisir de voir du Kubernetes managé sur Hetzner.
  • Je n’ai encore jamais vu de guide pour automatiser k8s sur les puissantes instances bare metal de Hetzner. Dans l’idéal, je vise une approche cattle, mais ce serait parfait de pouvoir aussi utiliser du bare metal avec de bons CPU et beaucoup de mémoire. C’est pour ça que mon cluster comprend à la fois des nœuds cloud et des nœuds bare metal. Avant, j’utilisais le vSwitch de Hetzner pour avoir un réseau L2 entre les nœuds cloud et bare metal, mais aujourd’hui je n’utilise plus que Tailscale. La plupart des outils comme Terraform ajoutent ou retirent des nœuds via l’API, mais il serait vraiment idéal d’avoir une fonctionnalité permettant, pour certaines classes de nœuds qu’on ne peut pas créer à nouveau, de faire au moins un wipe/rebuild.
  • C’est un peu hors sujet, mais l’API Hetzner est désormais aussi prise en charge en Raku : https://raku.land/zef:wayland/WWW::CloudHosting::Hetzner. On peut donc maintenant écrire des scripts d’automatisation de déploiement en Raku.
  • Pour ceux que ça intéresse, j’ai presque terminé un cours très pratique basé sur Kube-Hetzner (https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner, 3k stars). Il couvre le fonctionnement interne avec divers scripts, les sauvegardes/restaurations et même des exercices sur les pannes fréquentes. L’idée est de permettre d’apprendre les principes en mettant directement les mains dedans, sans abstraction. Sans compréhension, on finit forcément par être bloqué un jour. Liste d’attente : https://shipacademy.dev
  • Je n’arrive pas du tout à savoir où se trouve cette entreprise ni si ce n’est pas une arnaque. Il n’y a ni mentions légales, ni coordonnées, ni adresse physique sur le site. Il y a bien une adresse e-mail dans la politique de confidentialité, mais elle est masquée par Cloudflare. Le nom de l’entreprise semble être Edka Digital S.L., mais je ne sais pas dans quel pays elle est enregistrée. J’imagine que c’est un numéro de TVA de l’UE, mais je n’en suis pas sûr, et ça me met mal à l’aise.
    • Bonjour, ce projet est un side project personnel que j’ai créé en tant que freelance, et je suis enregistré comme freelance en Espagne. Mon numéro de TVA est ESY1848661G. J’en suis encore à la phase de collecte de retours, donc honnêtement je ne m’attendais pas à recevoir autant d’attention. Je vais mettre à jour la politique de confidentialité et les conditions d’utilisation. J’aimerais à terme transformer ça en entreprise, mais pour le moment ce n’est qu’une activité de freelance. Vos retours me permettent de corriger ça rapidement.
  • Le plus gros problème quand on configure k8s sur Hetzner, c’est qu’il n’existe pas de bon moyen de passer du bare metal à petite échelle (1 nœud) à une taille moyenne (10 à 100 nœuds). J’ai réussi à connecter des nœuds ingress avec la Gateway API en bricolant Envoy, mais le stockage reste le vrai problème. Ceph Rook est bien trop lourd pour tourner sur une seule machine, et je n’ai pas trouvé de wrapper permettant de passer facilement d’une gestion de volumes locaux à des volumes distribués. Dans l’idéal, il faudrait un démon PV capable de fonctionner légèrement même sur une seule machine, d’automatiser le déplacement des PV, puis de s’effacer de lui-même plus tard lors d’une migration vers Ceph ou autre.
  • Je me demande si cloud-init est utilisé lors de la création des instances sur Hetzner. De mon côté, j’utilise un script maison pour ajouter des instances Ubuntu comme nœuds Docker Swarm, et ce serait vraiment bien d’avoir aussi une version Docker Swarm de ce genre de solution.