Canine - une plateforme open source qui rend Kubernetes aussi simple qu’Heroku

 (github.com/czhu12)
33 points par GN⁺ 2025-06-18 | 1 commentaires | Partager sur WhatsApp
  • Une plateforme open source conçue pour permettre même aux développeurs solo d’utiliser facilement Kubernetes, en offrant une simplicité proche de celle d’Heroku
    • Fonctionne dans des environnements Docker et Docker Compose, avec installation et exécution possibles via de simples commandes
  • Développée pour résoudre le problème de hausse imprévue des coûts IT rencontré dans une startup existante
  • Recherche la simplicité en n’exposant que les éléments essentiels comme Ingress, Services, Deployments, Pods et CronJobs, plutôt que des fonctionnalités complexes
  • Permet de déployer presque n’importe quelle application open source via Helm, et il est aussi possible de quitter Canine en téléchargeant la configuration YAML
  • Vise à devenir une plateforme de développement adaptée aux petites équipes en complétant des fonctions absentes nativement de Kubernetes, comme les comptes, les déploiements ou les tableaux de bord

Présentation

  • Canine est une plateforme open source de déploiement Kubernetes, conçue pour permettre de déployer des applications aussi facilement qu’avec Heroku
  • Elle fonctionne sur son propre cluster Kubernetes et, si nécessaire, il est possible de télécharger la configuration YAML pour adopter aussi une exploitation décentralisée
  • Elle n’expose que les ressources essentielles comme Ingress, Services, Deployments, Pods et CronJobs, afin d’offrir une expérience simple et intuitive

Constat de départ : une architecture complexe et des coûts qui explosent

  • L’expérience d’exploitation d’une startup existante a montré que les coûts IT augmentaient bien plus vite que prévu
  • Ces coûts augmentaient surtout avec la complexité organisationnelle et la multiplication des services intégrés, souvent indépendamment de l’usage réel des serveurs ou de la puissance de calcul
  • L’accumulation d’outils tiers comme les suivants faisait rapidement grimper les coûts IT :
    • outils liés à la donnée comme Looker, Redshift, Databricks, DBT Cloud et FiveTran
    • outils de monitoring comme Datadog, New Relic et Sentry
    • outils d’infrastructure comme Google Maps API et AWS
  • Certains pouvaient être remplacés par de l’open source, mais la charge liée à la mise en place de l’infrastructure d’exploitation — monitoring, health checks, alertes, etc. — freinait leur adoption

Le potentiel et les limites de Kubernetes

  • Kubernetes est une plateforme capable de passer d’un nœud unique à des milliers de clusters, et elle est proposée comme standard sur presque tous les clouds
  • Mais pour les débutants et les petites équipes, elle reste perçue comme un système complexe et fragile
  • Une simple erreur, comme la suppression de CoreDNS, peut par exemple rendre tout le cluster inopérant
  • Quand les coûts et la complexité opérationnelle s’accumulent, les PaaS abstraits existants finissent au contraire par devenir un frein

Les caractéristiques de Canine

  • N’expose que les fonctionnalités minimales nécessaires de Kubernetes afin de garantir simplicité et contrôle
  • Comble les manques avec des fonctions comme :
    • gestion des comptes
    • gestion des déploiements
    • exécution simple de scripts ponctuels one-off
    • tableaux de bord de métriques
  • Grâce à sa plateforme de déploiement intuitive, même les débutants peuvent facilement déployer des applications dans un environnement Kubernetes
  • Il suffit d’avoir Docker et Docker Compose prêts pour pouvoir installer et lancer l’outil en une seule commande
  • Fournit un environnement d’administration basé sur une UI qui réduit la complexité des réglages Kubernetes et la charge de maintenance
  • Grâce à l’intégration de Helm, il devient facile de déployer aussi des applications open source comme Sentry

Migration et liberté

  • Canine s’utilise par-dessus un Kubernetes existant, ce qui le rend également facile à quitter
  • Toute la configuration peut être téléchargée en YAML, ce qui facilite ensuite une migration vers une autre plateforme

Importance et différenciation

  • Par rapport aux outils Kubernetes classiques, elle propose une UI pensée pour les débutants et un processus d’installation simple
  • En introduisant dans l’écosystème Kubernetes une expérience proche de celle d’Heroku, elle réduit fortement la barrière à l’entrée
  • Son socle open source permet une grande extensibilité ainsi qu’une amélioration portée par la communauté
  • Elle devrait avoir un impact important en permettant même à de petites équipes de développement ou à des startups de tirer facilement parti des avantages de Kubernetes
  • Utilisable, distribuable et modifiable librement sous licence Apache 2.0

À lire aussi

1 commentaires

 
GN⁺ 2025-06-18
Avis Hacker News

  • J’ai toujours été du genre à chercher de meilleures solutions pour reproduire une « expérience proche de Heroku » sur mon propre serveur, donc ça me fait vraiment plaisir de voir ça.
    La documentation Kubernetes de Canine est très accessible, probablement l’une des plus pédagogiques que j’aie vues jusqu’ici.
    En la lisant, je me suis demandé si on pouvait utiliser Canine aussi dans un environnement K8s managé comme Digital Ocean, mais après lecture, j’ai l’impression qu’il faut gérer soi-même son cluster K8s.
    Quelques questions :

    1. Quand on crée un « Cluster » chez Hetzner, est-ce un vrai cluster K8s couvrant plusieurs machines, ou simplement un découpage virtuel d’une seule machine ?
    2. Si on exécute le script d’installation sur d’autres serveurs, rejoignent-ils le cluster pour héberger les pods de façon répartie, comme dans une vraie configuration distribuée ?
    3. Peut-on connecter Canine à un cluster K8s managé existant pour y déployer ?
    • À l’heure actuelle, Canine prend en charge deux configurations :
      1. fonctionnement sur un seul VPS Hetzner
      2. utilisation sur un cluster Kubernetes déjà en place
        En général, l’option 1 sert pour des apps de staging/développement, et l’option 2 pour des apps de production.
        Dans le cas 2, on gère le nombre de nœuds via Digital Ocean ou autre, et Kubernetes replanifie automatiquement les workloads et permet l’autoscaling.
        C’est sans doute le cœur de la question : Canine ne prend pas encore en charge la création directe d’un cluster multinœud dans l’environnement Hetzner.
        Il existe aussi du terraform pour créer un cluster K8s sur Hetzner, mais ce n’est pas encore intégré à Canine.
        J’y ai de l’intérêt, après quelques améliorations de l’UI et autres.
        Pour l’instant, l’idée est soit de vous aider avec le guide d’installation K3s sur un VPS unique, soit de l’utiliser si vous avez déjà un cluster prêt.
        Lien utile : terraform-hcloud-kube-hetzner

  • En tant que personne convaincue qu’il faut absolument ce genre de projet, je vous soutiens de tout cœur.
    Aujourd’hui, j’hésiterais probablement entre Canine et Dokploy (et je pense aussi que Docker Swarm est une techno sous-estimée).
    Retour : la section « pourquoi il ne faut pas utiliser Canine » semblait vouloir jouer la carte de l’honnêteté, ce qui m’avait paru rafraîchissant, mais le ton m’a paru un peu sarcastique et ça m’a gêné.
    J’aurais préféré quelque chose de simplement franc, expliquant clairement les inconvénients réels : il faut acheter et gérer son serveur, assumer les pannes, et le produit en est encore à un stade précoce, porté par un seul développeur.

    • Je me demande où en sont aujourd’hui la maintenance et le support de Docker Swarm.
      J’avais arrêté de suivre il y a quelques années, quand l’équipe Docker semblait avoir cessé son développement.

    • Je l’avais écrit comme ça pour me différencier des autres landing pages, mais je suis très reconnaissant pour ce retour d’un vrai utilisateur.
      Je vais essayer à nouveau.

  • Partage d’une liste qui recense de nombreuses plateformes PaaS existantes :
    awesome-paas

  • Question à l’OP (l’auteur) :
    Qu’est-ce qui t’a amené à créer ce projet ?
    J’ai envie, moi aussi, de construire quelque chose de complexe de bout en bout, mais jusqu’ici je n’ai travaillé que sur de l’intégration API et React.
    Je suis curieux de savoir comment tu as découpé une idée complexe en tâches concrètes et réalistes jusqu’à en faire un projet open source de type « alternative à Heroku ».
    Comme j’ai très peu d’expérience avec Heroku, je pense que je me baserais sur des choses comme la page tarifaire pour comprendre « quelles fonctionnalités implémenter », mais j’ai peur que ce soit une approche inefficace.

  • Une alternative à Heroku basée sur Kubernetes, c’est intriguant.
    Mais si je dois connaître K8s ou les charts Helm pour l’utiliser, alors pour moi ce n’est pas vraiment une alternative à Heroku.
    Je comprends bien que, du point de vue de l’opérateur, ça puisse être aussi simple que echo hello.
    Mais quand je veux mettre quelque chose en ligne le plus vite possible, je n’ai même pas envie que les mots « Kubernetes » et « chart Helm » me traversent l’esprit.

    • C’était précisément l’objectif de Canine.
      L’utilisateur n’a même pas besoin de savoir que Kubernetes existe, tout en profitant de son écosystème mature.
      Et s’il a besoin de fonctions plus puissantes plus tard, il peut toujours ouvrir l’accès à des outils avancés comme l’API Kubernetes et les utiliser directement.

  • Petite remarque :
    Kubernetes n’exécute pas des conteneurs Docker, mais des conteneurs conformes à la spécification Open Container Initiative (OCI).
    Docker est une marque.

    • Une autre petite remarque :
      Le Canine Kubernetes Crash Course parle d’une « prise en charge de 10 000 serveurs », alors qu’officiellement Kubernetes est annoncé comme supportant jusqu’à 5 000 nœuds.
      Voir la documentation officielle de Kubernetes
      On peut bien sûr aller vers des clusters beaucoup plus gros, mais cela demande alors une forte personnalisation (jusqu’au remplacement complet du registre API, etc.).
      La charge de travail a aussi son importance.
      Kubernetes est encore loin de prendre en charge de très grands clusters out-of-the-box, même si ça progresse à chaque release.

    • J’ai tendance à décrocher dès qu’on me dit que Docker est indispensable.
      Aujourd’hui, j’opère plutôt avec podman ou containerd qu’avec Docker.

  • Construire ce projet a été incroyablement amusant, probablement l’expérience de développement la plus plaisante de ma vie.
    Le sentiment de maîtriser toute la « stack technique » est fantastique.
    Entre l’app Rails, l’infra Canine, le serveur Raspberry Pi et même l’ISP que j’utilise,
    j’ai partagé l’expérience de tout gérer moi-même pour déployer mon application.

  • Sur le site web, la licence est indiquée comme étant la MIT License 2024,
    alors que le GitHub mentionne une licence Apache.
    Plus que l’année, c’est le type de licence qui me semble être une vraie différence importante.
    Je me demande donc quelle est la licence effectivement applicable.

  • En self-hosting, je voulais un palier intermédiaire entre Docker et K8s, donc j’ai moi-même cherché quelque chose de similaire.
    J’ai envisagé Nomad aussi, mais ça restait un peu plus compliqué que du Docker dead simple, avec un écosystème plus limité.
    Au final, sur mon home server, je tourne uniquement avec Docker et j’accepte les temps d’arrêt pendant les déploiements.
    Je me demande jusqu’à quel point Canine abstrait réellement K8s en production.
    Est-ce qu’on finit par devoir regarder sous le capot ? Comme je débute sur K8s, je me demande si ce juste milieu est réellement possible.

    • Moi aussi, je développe un outil positionné entre Docker et Kubernetes.
      uncloud
      L’objectif est de proposer un CLI dans l’esprit de Docker et les capacités multi-machine / production de Docker Compose, tout en restant simple et sans plan de contrôle opérationnel.
      C’est encore en développement, mais le but est qu’on puisse facilement comprendre ce qui se passe à chaque couche et que le troubleshooting reste simple.

  • J’aime vraiment beaucoup le concept.
    K8s est une techno impressionnante, mais sa complexité constitue une barrière à l’entrée.
    D’après les ressources publiques, vous semblez bien en avoir compris l’essence.
    Cela me paraît particulièrement utile dans le monde du self-hosting, où des solutions comme PVE, Microcloud ou Cockpit sont populaires.
    J’ai un NUC N100 qui traîne à la maison ; ça me donne envie d’abandonner Microcloud et de tester Canine.

    • Helm peut parfois être pénible.
      Entre les valeurs qui s’appliquent après modification de values.yaml et celles qu’il faut définir dès le départ, on peut vite s’y perdre.
      Certaines installations Helm déploient tellement de services qu’on ne sait plus très bien quoi redémarrer, ni à quel moment.
      En revanche, le cœur de Kubernetes est vraiment agréable à utiliser pour les jobs stateless.

    • Je ne sais plus très bien d’où vient aujourd’hui cette idée de « complexité » de K8s.
      Avant, il fallait parfois deux heures de setup avec kubespray,
      alors qu’aujourd’hui, avec des outils comme rke, on peut créer un cluster avec un simple fichier yaml et une clé SSH.