Canine – eine Open-Source-Plattform, die Kubernetes so einfach wie Heroku macht

 (github.com/czhu12)
33 Punkte von GN⁺ 2025-06-18 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Open-Source-Plattform, mit der auch Solo-Entwickler Kubernetes einfach nutzen können, und die eine ähnliche Einfachheit wie Heroku bietet
    • Läuft in Docker- und Docker Compose-Umgebungen und lässt sich mit einfachen Befehlen installieren und starten
  • Wurde entwickelt, um das Problem unerwartet steigender IT-Kosten zu lösen, das in einem früheren Startup auftrat
  • Statt komplexer Funktionen werden nur Kernelemente wie Ingress, Services, Deployments, Pods und CronJobs offengelegt, um maximale Einfachheit zu erreichen
  • Über Helm lassen sich nahezu alle Open-Source-Apps bereitstellen, und durch das Herunterladen der YAML-Konfigurationen ist es auch möglich, Canine wieder zu verlassen
  • Ergänzt Funktionen, die Kubernetes standardmäßig nicht bietet, etwa Accounts, Deployments und Dashboards, und zielt damit auf eine Entwicklungsplattform, die sich gut für kleine Teams eignet

Überblick

  • Canine ist eine Open-Source-Plattform für Kubernetes-Deployments, die so konzipiert wurde, dass sich Apps ähnlich einfach wie bei Heroku bereitstellen lassen
  • Läuft auf einem eigenen Kubernetes-Cluster; bei Bedarf können die YAML-Konfigurationen heruntergeladen werden, sodass auch ein dezentralisierter Betrieb möglich ist
  • Durch die Beschränkung auf zentrale Ressourcen wie Ingress, Services, Deployments, Pods und CronJobs bietet Canine eine einfache und intuitive Bedienung

Problemstellung: komplexe Strukturen und explodierende Kosten

  • Aus der Erfahrung beim Betrieb eines früheren Startups zeigte sich, dass IT-Kosten sehr viel schneller als erwartet anstiegen
  • Die Kosten stiegen meist mit zunehmender organisatorischer Komplexität und der Zahl angebundener Services, oft unabhängig von Server- oder Compute-Nutzung
  • Die folgenden Third-Party-Tools summierten sich zu stark steigenden IT-Kosten:
    • Daten-Tools wie Looker, Redshift, Databricks, DBT Cloud und FiveTran
    • Monitoring-Tools wie Datadog, New Relic und Sentry
    • Infrastruktur-Tools wie Google Maps API und AWS
  • Ein Teil davon ließ sich zwar durch Open Source ersetzen, doch der Aufwand für Betriebsinfrastruktur wie Monitoring, Health Checks und Benachrichtigungen schreckte von der Einführung ab

Potenzial und Grenzen von Kubernetes

  • Kubernetes ist eine Plattform, die sich von einem einzelnen Node bis zu Tausenden von Clustern skalieren lässt und in nahezu jeder Cloud standardmäßig angeboten wird
  • Für Einsteiger und kleine Teams gilt es jedoch als komplexes und leicht kaputtgehendes System
  • Schon Fehler wie das Löschen von CoreDNS können dazu führen, dass der gesamte Cluster nicht mehr funktioniert
  • Wenn sich Kosten und betriebliche Komplexität aufstauen, können bestehende abstrahierte PaaS-Lösungen eher zum Hemmschuh werden

Eigenschaften von Canine

  • Legt nur die minimal nötigen Kubernetes-Funktionen offen und schafft damit Einfachheit und Kontrollierbarkeit
  • Fehlende Teile werden durch folgende Funktionen ergänzt:
    • Account-Verwaltung
    • Deployment-Verwaltung
    • Einfache Ausführung von einmaligen Skripten
    • Metrik-Dashboards
  • Über eine intuitive Deployment-Plattform können auch Einsteiger Anwendungen leicht in einer Kubernetes-Umgebung bereitstellen
  • Wenn Docker und Docker Compose vorhanden sind, sind Installation und Start mit einem einzigen Befehl möglich
  • Bietet eine UI-basierte Verwaltungsumgebung, die komplexe Kubernetes-Konfigurationen und den Wartungsaufwand reduziert
  • Dank Helm-Integration lassen sich auch Open-Source-Apps wie Sentry einfach deployen

Migration und Freiheit

  • Canine wird auf bestehendem Kubernetes aufgesetzt, daher ist auch ein Wechsel weg davon einfach
  • Alle Konfigurationen können als YAML heruntergeladen werden, was eine spätere Migration auf andere Plattformen erleichtert

Bedeutung und Unterschiede

  • Bietet gegenüber typischen Kubernetes-Tools eine einsteigerfreundliche UI und einen einfachen Installationsprozess
  • Führt eine Heroku-ähnliche Nutzungserfahrung in das Kubernetes-Ökosystem ein und senkt damit die Einstiegshürde deutlich
  • Auf Open Source basierend sind flexible Erweiterbarkeit und community-getriebene Verbesserungen möglich
  • Gerade für kleine Entwicklungsteams oder Startups wird ein großer Nutzen erwartet, weil sie die Vorteile von Kubernetes damit leicht nutzen können
  • Unter der Apache 2.0 License frei nutzbar, verteilbar und modifizierbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-18
Hacker-News-Kommentare

  • Ich bin jemand, der immer nach besseren Lösungen sucht, um auf meinem eigenen Server eine „Heroku-ähnliche Erfahrung“ umzusetzen, deshalb freut mich das wirklich sehr.
    Die Kubernetes-Dokumentation von Canine ist sehr zugänglich und gehört gefühlt zu den freundlichsten, die ich bisher gesehen habe.
    Beim Lesen der Doku kam bei mir die Frage auf: Kann man Canine auch in einer Managed-K8s-Umgebung wie bei Digital Ocean nutzen? Nach der Lektüre hatte ich aber eher den Eindruck, dass man den K8s-Cluster selbst verwalten muss.
    Ein paar Fragen dazu:

    1. Wenn man bei Hetzner einen „Cluster“ erstellt, ist das dann ein echter K8s-Cluster über mehrere Maschinen hinweg oder nur eine virtuelle Aufteilung auf einer einzelnen Maschine?
    2. Wenn man das Installationsskript auf einem anderen Server ausführt, tritt dieser dann dem Cluster bei, sodass Pods verteilt gehostet werden, also eine wirklich verteilte Serverkonfiguration entsteht?
    3. Kann man Canine an ein bereits existierendes Managed-K8s anschließen und darauf deployen?
    • Aktuell unterstützt Canine zwei Setups:
      1. Betrieb auf einem einzelnen Hetzner-VPS
      2. Nutzung auf einem bereits bestehenden Kubernetes-Cluster
        Üblicherweise wird Option 1 für Staging-/Entwicklungs-Apps genutzt und Option 2 für Produktions-Apps.
        Bei 2 verwaltet man dann z. B. bei Digital Ocean die Anzahl der Nodes, und Kubernetes übernimmt das automatische Rescheduling der Workloads sowie Autoscaling.
        Das trifft wohl den Kern der Frage: Canine unterstützt derzeit noch nicht, in der Hetzner-Umgebung selbst einen Multi-Node-Cluster zu erstellen.
        Es gibt zwar Terraform für Hetzner zum Erstellen eines K8s-Clusters, aber das ist in Canine noch nicht integriert.
        Nach Verbesserungen an der UI besteht daran aber Interesse.
        Im Moment hilft es entweder mit einer Installationsanleitung für K3s auf einem einzelnen VPS, oder es setzt voraus, dass bereits ein Cluster vorhanden ist.
        Referenzlink: terraform-hcloud-kube-hetzner

  • Als jemand, der findet, dass es solche Projekte unbedingt braucht, drücke ich die Daumen.
    Heute würde ich vermutlich zwischen Canine und Dokploy abwägen (ich halte auch Docker Swarm für eine unterschätzte Technologie).
    Feedback: Der Abschnitt „Warum man Canine nicht benutzen sollte“ wirkte zunächst erfrischend ehrlich, hatte aber einen leicht sarkastischen Unterton, der mich gestört hat.
    Ich fände es besser, wenn dort einfach klar und ehrlich die realen Nachteile stünden: dass man Server kaufen und verwalten muss, bei Ausfällen selbst verantwortlich ist und dass es sich um ein frühes Produkt eines Solo-Entwicklers handelt.

    • Ich frage mich, wie es aktuell um Wartung und Support von Docker Swarm steht.
      Ich hatte vor ein paar Jahren aufgehört, das weiterzuverfolgen, weil es so wirkte, als hätte das aktuelle Docker-Team die Entwicklung eingestellt.

    • Das war so formuliert, um sich von anderen Landingpages abzuheben, aber ich bin sehr dankbar für echtes Nutzerfeedback.
      Ich werde es noch einmal überarbeiten.

  • Geteilt wurde eine Liste, die verschiedene PaaS-Plattformen sammelt und verwaltet.
    awesome-paas

  • Eine Frage an den OP (Autor):
    Mich würde interessieren, was der Hintergrund dafür war, so ein Projekt zu bauen.
    Ich habe auch den Wunsch, einmal etwas Komplexes von Anfang bis Ende zu bauen, habe bisher aber nur mit API- und React-Integrationen gearbeitet.
    Mich interessiert, wie du den Prozess geschafft hast, eine komplexe Idee in realistische Aufgaben zu zerlegen und daraus tatsächlich ein Open-Source-Projekt als „Heroku-Alternative“ zu machen.
    Ich selbst habe kaum Erfahrung mit Heroku und würde beim Ermitteln der „umzusetzenden Funktionen“ vermutlich auf Dinge wie Preisseiten schauen; ich frage mich aber, ob das nicht ein ineffizienter Ansatz wäre.

  • Eine Heroku-Alternative auf Kubernetes-Basis klingt interessant.
    Wenn man dafür aber Dinge wie K8s oder Helm Charts kennen muss, ist es für mich in Wirklichkeit keine Heroku-Alternative.
    Natürlich verstehe ich, dass das aus Betreibersicht vielleicht so simpel wie echo hello wirken kann.
    Aber wenn ich möglichst schnell irgendetwas deployen will, möchte ich nicht einmal an die Worte „Kubernetes“ und „Helm Chart“ denken müssen.

    • Genau das war das Ziel von Canine.
      Nutzer müssen nicht einmal wissen, dass Kubernetes überhaupt existiert, können aber trotzdem von seinem ausgereiften Ökosystem profitieren.
      Und wenn man irgendwann mächtigere Funktionen braucht, kann man jederzeit auch direkt professionelle Features wie die Kubernetes API freilegen und nutzen.

  • Ein kleiner Hinweis:
    Kubernetes betreibt keine Docker-Container, sondern Container nach dem Standard der Open Container Initiative (OCI).
    Docker ist ein Markenname.

    • Noch ein kleiner Hinweis:
      Im Canine Kubernetes Crash Course wird erklärt, Kubernetes unterstütze „10.000 Server“.
      Offiziell ist aber dokumentiert, dass Kubernetes bis zu 5.000 Nodes unterstützt.
      Siehe offizielle Kubernetes-Dokumentation
      Deutlich größere Cluster sind zwar möglich, erfordern dann aber umfangreiche Anpassungen, etwa einen vollständigen Austausch der API registry.
      Natürlich spielt auch die Workload eine Rolle.
      Kubernetes ist noch ein Stück davon entfernt, out of the box wirklich große Cluster zu unterstützen, entwickelt sich aber mit jedem Release weiter.

    • Ich mag es nicht, wenn Docker als zwingend erforderlich dargestellt wird.
      Heutzutage wird oft eher mit podman oder containerd als mit Docker gearbeitet.

  • Dieses Projekt zu bauen hat enorm viel Spaß gemacht und war die schönste Entwicklungsarbeit meines Lebens.
    Das Gefühl, den gesamten „Tech-Stack“ in einer Hand zu halten, ist großartig.
    Die Rails-App, die Canine-Infrastruktur, der Raspberry-Pi-Server, sogar der ISP, den ich nutze.
    Ich habe die Erfahrung gemacht, alles selbst zu verwalten und darauf Apps zu deployen.

  • Auf der Website steht als Lizenz „2024 MIT License“,
    während im eigentlichen GitHub-Repository eine Apache-Lizenz angegeben ist.
    Unabhängig davon, ob die Jahreszahl stimmt oder nicht, scheint mir die Art der Lizenz der wichtigere Unterschied zu sein.
    Mich würde interessieren, welche Lizenz tatsächlich gilt.

  • Beim Self-Hosting wollte ich eine Zwischenstufe zwischen Docker und K8s, daher habe ich mich selbst schon nach etwas Ähnlichem umgesehen.
    Ich habe auch Nomad in Betracht gezogen, aber das war immer noch etwas komplexer als dead simple Docker und das Ökosystem war schwächer.
    Am Ende betreibe ich meinen Homeserver nur mit Docker und akzeptiere Downtime während Deployments.
    Für Produktion würde mich interessieren, wie weit Canine K8s abstrahiert.
    Ob man doch irgendwann in die Interna schauen muss, und ob dieser Mittelweg für K8s-Neulinge wirklich praktikabel ist.

    • Ich entwickle ebenfalls ein Tool, das zwischen Docker und Kubernetes positioniert ist.
      uncloud
      Ziel ist es, eine Docker-artige CLI und Multi-Machine-/Produktions-Funktionen ähnlich Docker Compose zu bieten, dabei aber ohne operierende Control Plane simpel und klar zu bleiben.
      Es ist noch in Entwicklung, aber mein Ziel ist, dass man auf allen Ebenen leicht verstehen kann, was passiert, und dass auch Troubleshooting einfach bleibt.

  • Das Konzept gefällt mir wirklich sehr.
    K8s ist großartige Technologie, aber seine Komplexität ist eine hohe Einstiegshürde.
    Nach dem, was öffentlich dazu verfügbar ist, scheint hier das Wesentliche gut verstanden worden zu sein.
    Gerade im Self-Hosting-Bereich, wo Lösungen wie PVE, Microcloud und Cockpit beliebt sind, dürfte das besonders nützlich sein.
    Ich habe zu Hause noch einen ungenutzten N100-NUC herumstehen und bekomme Lust, Canine zu testen, statt weiter an Microcloud festzuhalten.

    • Helm kann manchmal lästig sein.
      Es ist verwirrend, welche Werte nach einer Änderung in values.yaml übernommen werden und welche von Anfang an gesetzt sein müssen.
      Manche Helm-Installationen bringen so viele Services mit, dass man leicht den Überblick verliert, was man wann neu starten darf.
      Im Gegensatz dazu fühlt sich reines Kubernetes für stateless Jobs wirklich angenehm an.

    • Ich weiß mittlerweile gar nicht mehr, woher dieses Gerede über die „Komplexität“ von K8s kommt.
      Früher musste man mit kubespray schon mal zwei Stunden für ein Setup einplanen.
      Heute kann man mit Tools wie rke schon mit nur einer YAML-Datei und einem SSH-Key einen Cluster erstellen.