Was ist das beste Kubernetes-Tool für die Entwicklung im Jahr 2023? Dieser Artikel vergleicht drei der beliebtesten Lösungen. Getdeck, entwickelt von Blueshoe, ist eine neue Alternative zur lokalen Kubernetes-Entwicklung, die auf den Markt kommt.

Einführung

In diesem Artikel vergleichen wir drei beliebte lokale Kubernetes-Entwicklungstools. Zusätzlich wird Getdeck Beiboot als remote Kubernetes-basierte Entwicklungsumgebung in den Vergleich aufgenommen.

Der Schwerpunkt dieses Blogbeitrags liegt auf der Bewertung der DX ("Developer Experience") in tatsächlichen Entwicklungsszenarien. Dies ist besonders wichtig, da du diese Tools möglicherweise auch für Produktbereitstellungen verwenden kannst. Die wichtigen Dimensionen für die Bewertung dieser Tools unterscheiden sich jedoch sehr zwischen Entwicklung und Produktionshosting.

Die folgenden Aspekte sind für Softwareentwicklungsfälle relevant:

Diese Liste der Bewertungskriterien ist nicht abschließend. Es gibt auch einige Aspekte, die die Arbeit mit diesen Tools attraktiv machen, wie persönliche Vorlieben. Ich werde jedoch nicht auf alle diese Kriterien in diesem Artikel eingehen.

Alle Tools sind in der Lage, dem Entwickler eine dedizierte Kubernetes-Umgebung zum Erlernen von Kubernetes, zum Herumspielen oder zur Lösung von Entwicklungsaufgaben bereitzustellen.

Minikube vs. k3d

Minikube

minikube ist eine der ausgereiftesten Lösungen auf dem Markt. Als unser Team bei Blueshoe im Jahr 2017 begann, Kubernetes zu übernehmen, war minikube bereits verfügbar. Die erste Version 0.1.0 wurde am 30. Mai 2016 veröffentlicht, kurz nach dem ersten Commit auf Github am 16. April 2016.

minikube wurde von einer Kubernetes SIG, einer Interessengruppe, gestartet, die den Bedarf an lokalen Kubernetes-Umgebungen erkannte. Heute ist die SIG eng mit dem Kubernetes-Entwicklungsteam verbunden und daher auf dem neuesten Stand des offiziellen Kubernetes-Codebasis.

Alleskönner für verschiedene Plattformen

Ein sehr wichtiger Unterschied zwischen Minikube und allen anderen Teilnehmern ist, dass es Kubernetes-Cluster mit einem der verschiedenen Treiber bereitstellen kann. Diese Treiber implementieren die Art und Weise, wie du den Kubernetes-Cluster auf einer Entwicklungs-Maschine ausführst: entweder in einer virtuellen Maschine (z.B. Hyper-V, KVM2, QEMU oder andere) oder in einer Container-Laufzeitumgebung (z.B. mit Docker oder Podman). Wenn man sich Minikube mit den oben genannten Bewertungsaspekten ansieht, kann man Unterschiede in den Details zwischen diesen Treibern feststellen. Aber im Allgemeinen abstrahiert Minikube die Implementierung des Treibers für den Entwickler.

Daher ist es sehr wahrscheinlich, dass Minikube Kubernetes für praktisch jede Plattform ausführen kann, an der ein Entwickler arbeitet. Mit einer einheitlichen Benutzeroberfläche ist Minikube eine sehr plattformunabhängige Lösung. Wenn dein Team mit Windows, macOS, Linux oder sogar exotischeren Plattformen arbeitet, ist es ein großer Vorteil, wenn alle Mitglieder das gleiche Tool verwenden. Du kannst Wissen leichter teilen, Skripte für die Automatisierung bereitstellen und Dokumentation erstellen, die alle Plattformen gleichermaßen abdeckt.

Ein großer Pluspunkt für Minikube ist seine umfassende Dokumentation. Sie enthält nicht nur technische Referenzen, sondern auch eine lange Liste von Tutorials für viele spezifische Anwendungsfälle und Bereitstellungsszenarien.

Verwende alle K8s-Funktionen mit Minikube

Mit Minikube kann ein Entwickler praktisch jede erforderliche Kubernetes-Funktion verwenden. Einige von ihnen müssen mit dem Flag –feature-gates aktiviert werden. Dies ist eine Reihe von Schlüssel-Wert-Paaren, die Feature-Gates für experimentelle Funktionen beschreiben. Andere Funktionen werden vom Addons-System von Minikube gesteuert. Addons können von Drittanbietern integriert werden. Hier ist eine Liste von Addons von meinem System.

|-----------------------------|--------------------------------|
|         ADDON NAME          |           MAINTAINER           |
|-----------------------------|--------------------------------|
| ambassador                  | 3rd party (Ambassador)         |
| auto-pause                  | Google                         |
| csi-hostpath-driver         | Kubernetes                     |
| dashboard                   | Kubernetes                     |
| default-storageclass        | Kubernetes                     |
| efk                         | 3rd party (Elastic)            |
| freshpod                    | Google                         |
| gcp-auth                    | Google                         |
| gvisor                      | Google                         |
[...]
| nvidia-gpu-device-plugin    | 3rd party (Nvidia)             |
| olm                         | 3rd party (Operator Framework) |
| pod-security-policy         | 3rd party (unknown)            |
| portainer                   | 3rd party (Portainer.io)       |
| registry                    | Google                         |
| registry-aliases            | 3rd party (unknown)            |
| registry-creds              | 3rd party (UPMC Enterprises)   |
| storage-provisioner         | Google                         |
| storage-provisioner-gluster | 3rd party (Gluster)            |
| volumesnapshots             | Kubernetes                     |
|-----------------------------|--------------------------------|

Diese Addons werden aktiviert mit...

minikube addons enable [...]

...und ermöglichen es einem Minikube-Cluster, diese bestimmte Funktion im lokalen Entwicklungsscluster bereitzustellen. Wenn du beispielsweise Volumesnapshots benötigst, wie wir es beim Aufbau des Getdeck Beiboot-Regalfeatures getan haben, führe einfach Folgendes aus:

minikube addons enable volumesnapshots

Das macht es sehr bequem, eine solche Funktion zu verwenden, ohne jede Entwicklungsumgebung von Anfang an aufzublähen. Außerdem stehen dem Team dieselben Addons zur Verfügung, vorausgesetzt, sie verwenden alle dieselbe Version von Minikube.

Minikube-Profile: mehrere logische Cluster auf einer Entwicklungs-Maschine

Als wir begannen, Kubernetes zu übernehmen, suchten wir nach einer Lösung, die es uns ermöglichte, mehrere logische Cluster auf einer Entwicklungs-Maschine zu verwalten. In den Jahren 2016/2017 legte Minikube nicht viel Wert auf dieses spezielle Feature. Es war nur möglich, einen Cluster pro Maschine zu starten, und es gab nur eine Single-Node-Cluster-Konfiguration. Aus diesem Grund haben wir uns bei Blueshoe entschieden, mit k3d zu arbeiten. Minikube hat jedoch dieses wichtige Entwickler-Feature aufgeholt und unterstützt jetzt mehrere sogenannte Minikube-Profile.

Minikube-Profile sind logische Cluster, die separat voneinander gestartet und gestoppt werden können. Es ermöglicht einem Entwickler, mehr als eine Kubernetes-basierte Entwicklungsumgebung zu haben. Denke nur an mehrere getrennte Projekte, die unterschiedliche Kubernetes-API-Versionen, Funktionen oder einfach unterschiedliche Workloads erfordern, die in ihnen ausgeführt werden. Du kannst... :

minikube start -p myprofile1

...ausführen und du erhältst einen leeren neuen Cluster mit einem frischen Profil, das neben anderen Profilen existieren kann.

k3d

k3d ist in Bezug auf die Bereitstellung auf einer Entwicklungs-Maschine eingeschränkter. Von Anfang an unterstützte k3d nur eine lokale Container-Runtime für die Ausführung des Kubernetes-Clusters. Wie ich zuvor erwähnt habe, war es jedoch immer möglich, mehrere separate Cluster für die Entwicklung auf einem Host zu verwalten. Das war ein echtes Killer-Feature, insbesondere für Blueshoe, da wir mehrere verschiedene Kubernetes-Projekte für verschiedene Kunden betreiben. Gerade bei unserer Wartungsarbeit ist es ein Muss, gleichzeitig eine topaktuelle (keine Sorge, ich habe diesen Begriff erfunden) Entwicklungsumgebung sowie eine stabile, produktionsnahe Umgebung zu haben. Als Entwickler muss ich Fehlerkorrekturen in kürzester Zeit bereitstellen und die Entwicklung neuer Funktionen vorantreiben.

k3d basiert auf k3s, einer schlanken Kubernetes-Lösung, die von Rancher entwickelt wird. K3d ist jedoch nicht eng mit k3s verbunden und wird von einer Entwicklergemeinschaft vorangetrieben.

Das Besondere an k3s ist, dass es einige der standardmäßigen Kubernetes-Komponenten wie etcd durch weniger skalierbare und ressourcenintensive Alternativen (z. B. SQLite) ersetzt. Darüber hinaus wird das gesamte System in eine sehr kleine ausführbare Binärdatei kompiliert (weniger als 40 MiB), was auch den Speicherplatzbedarf sehr gering hält. Das Basis-Kubernetes-System k3s wurde ursprünglich für IoT- und Edge-Computing-Umgebungen entwickelt. Ich würde sagen, dass es auch für Entwicklungsumgebungen perfekt ist, da diese geringen Ressourcenanforderungen perfekt passen. Den Vergleich des Ressourcenverbrauchs werden wir später in diesem Artikel sehen.

Da k3d nur ein Wrapper für k3s ist, kann es sich auf die Entwicklererfahrung konzentrieren. Es wird mit sehr guter Dokumentation geliefert, genau wie bei Minikube, die auch Tutorials für bestimmte Anwendungsszenarien enthält. Zum Beispiel findest du ein Beispiel für einen Entwicklungsworkflow mit Tilt und einen Build-Push-Test-Zyklus mit k3d's Container-Image-Sharing-Funktion.

Gut für Teams: Teilen von k3d-Konfigurationen

Ein großer Vorteil, den k3d bietet (den Minikube zu diesem Zeitpunkt vermisst), ist, dass k3d eine Cluster-Konfigurationsdatei bereitstellt (ab Version 4.0.0). Dadurch können Entwicklungsteams die Konfiguration eines k3d-Clusters in einer lokalen YAML-Datei speichern, die im Team geteilt werden kann. Diese Datei enthält die Konfiguration für fast alle Parameter, die einen Cluster ausmachen, z. B. die Anzahl der Clusterknoten, die Kubernetes-Version, die lokal zugeordneten Ports, Registrierungen, Funktionen und vieles mehr. Mit dieser Datei kannst du die gleiche Cluster-Konfiguration im Team problemlos bereitstellen, ohne dass der Entwickler einer Anleitung oder einem Skript folgen muss, um seinen lokalen Kubernetes-Cluster einzurichten. Du kannst k3d cluster create --config mycluster1.yaml ausführen und alles wird wie angegeben bereitgestellt. Meiner Meinung nach ist das viel einfacher als das, was du derzeit mit Minikube tun kannst.

Keine Sorge um kubectl

Mit beiden Lösungen, Minikube und k3d, wird der kubectl-Kontext des Entwicklers automatisch auf den neu erstellten Cluster gesetzt. Beide Alternativen benennen ihren kube-Kontext nach dem Cluster-Namen/Profil-Namen, der beim Erstellen des Clusters angegeben wurde. Auf diese Weise kann der Entwickler problemlos mit der Arbeit beginnen, ohne sich um die kubectl-Konfiguration kümmern zu müssen.

Weniger Komplexität, weniger CLI-Befehle

Da k3d nicht die Komplexität von Minikube bietet, ist die CLI viel weniger umfassend, aber dennoch einfach. Ich würde sagen, für Entwickler, die mit der CLI arbeiten, ist das ein Pluspunkt. Insbesondere bei Verwendung der k3d-Konfigurationsdatei kann ich die meisten Eingaben auf der Befehlszeilenschnittstelle einsparen und die Oberfläche der CLI auf die wenigen erforderlichen Befehle reduzieren: Starten, Stoppen und Löschen eines Clusters.

Ich vermute, dass in k3d nur wenige Funktionen fehlen, da sie in k3s nicht unterstützt werden, aber für 95% der Entwicklungsarbeit sollte es völlig ausreichend sein. Sogar der Snapshot-Controller wurde kürzlich zu k3s hinzugefügt.

Minikube vs. kind

Kind ist ein weiteres Projekt, das von einer Kubernetes SIG vorangetrieben wird. An diesem Punkt konnte ich nicht herausfinden, warum es noch gepflegt wird (ich habe einen Grund gefunden, aber lies weiter). Kind ist ein Akronym für "Kubernetes in Docker" und entstand aus der Idee, Kubernetes auf einer Container-Runtime (anstelle einer virtuellen Maschine) auszuführen. Heutzutage bevorzugt minikube jedoch ebenfalls Docker als Bereitstellungsoption, sodass es in diesem wichtigen Punkt keinen Unterschied mehr zwischen minikube und kind gibt. Sie haben jedoch eine schöne Seite in ihrer Dokumentation, auf der die Prinzipien und Zielanwendungsfälle von Kind erklärt werden. Ich würde sagen, es läuft alles auf Automatisierung hinaus.

Konfigurationsdateien und K8s-Funktionen

Ähnlich wie k3d bietet auch Kind die Möglichkeit, Konfigurationsdateien zu verwenden. Ähnlich wie bei k3d kannst du...

kind create cluster --config mycluster1.yaml

... ausführen, um einen lokalen Kubernetes-Cluster basierend auf der angegebenen Konfiguration zu erstellen.

Kind bietet auch Feature Gates, um experimentelle Kubernetes-Funktionen und viele andere Konfigurationsoptionen zu aktivieren.

Podman? Rootless? Kind!

Im Vergleich zu Minikube, wo die Verwendung von Podman als experimentell betrachtet wird, bietet Kind solide Unterstützung für Podman. Das Projektteam hat sogar erhebliche Anstrengungen unternommen, um Kind auch im rootless-Modus auszuführen. Für diejenigen, für die dies wichtig ist, ist Kind derzeit die einzige Lösung. Natürlich bringt es jedoch mehrere Einschränkungen mit sich.

Kind verfügt über eine weniger komplexe CLI im Vergleich zu Minikube. Sie verzichtet auch auf Emojis, was ein Vorteil sein kann. Aber das ist Geschmackssache.

Wenn man die Startseite beider Produkte vergleicht, behauptet Minikube, sich "...auf die Unterstützung von Anwendungsentwicklern und neuen Kubernetes-Benutzern zu konzentrieren.", während Kind "ursprünglich für das Testen von Kubernetes selbst entwickelt wurde, aber auch für die lokale Entwicklung oder CI verwendet werden kann". Ich denke, das gibt eine gewisse Vorahnung davon, worum es geht.

Vergleich von Minikube, k3d und Kind im Jahr 2023

Lass uns nun einen direkten Vergleich dieser drei Alternativen für die lokale Kubernetes-Entwicklung im Jahr 2023 durchführen.

Beliebtheit

Beliebtheit ist ein Indikator dafür, wie gesichert die fortlaufende Wartung eines Produkts ist. Eine gute Währung, um dies zu messen, ist die Anzahl der GitHub-Stargazers:

Wie du sehen kannst, haben alle drei Kandidaten bereits eine erhebliche Beliebtheit auf GitHub. Minikube ist jedoch bei weitem die beliebteste Option. Ich würde sagen, dass alle drei Lösungen aufgrund ihrer lebendigen Community dauerhaft gewartet werden.

Leistungsbewertung

Die folgende Leistungsbewertung wurde auf einem Ubuntu-System durchgeführt, das auf einem Intel Core i7 (8. Generation) mit 16 GiB RAM läuft. Obwohl ich auf Linux arbeite, habe ich Docker Desktop auf meinem Rechner verwendet und hoffe, vergleichbare Ergebnisse mit anderen Plattformen zu sammeln.

Hinweis: Docker Desktop führt auf Linux ebenfalls eine QEMU-basierte virtuelle Maschine aus, genau wie auf Windows und macOS. Das Kubernetes in Docker Desktop wurde deaktiviert.

Ich habe die folgenden Versionen der Tools verwendet:

Cluster-Startzeit

In diesem Testfall messe ich die Zeit vom Anfordern eines neuen lokalen Clusters bis zu dessen Start. Ich habe keine speziellen Konfigurationen angegeben, sondern die Standardwerte verwendet.

Ich habe diesen Test fünfmal durchgeführt und das beste Ergebnis aller Messungen genommen, damit keine Container-Images während der gemessenen Zeit heruntergeladen werden.

Die Startzeiten sind wie folgt:

Die Startzeiten aller Kandidaten sind ziemlich nah beieinander. Wenn du beispielsweise zuerst die erforderlichen Container-Images herunterladen musst, wird dies wahrscheinlich den Gesamtprozess mehr beeinflussen als der zugrunde liegende Bootstrapping-Prozess. Mit Ausnahme des kvm2-Treibers von Minikube. Dieser Prozess ist viel aufwändiger und beinhaltet das Hochfahren einer gesamten virtuellen Maschine. Ich gehe davon aus, dass VM-basierte Treiber sowieso nicht die erste Wahl für die Mehrheit der Entwickler sind.

Cluster-Abschaltzeit

Ich habe die Zeiten für das Stoppen und Löschen eines Clusters gemessen. Ich habe diesen Test mehrmals durchgeführt und das beste Ergebnis aller Messungen genommen:

Alle Tools stoppen und löschen ihre Cluster sehr schnell. Kein großer Unterschied zwischen ihnen.

Cluster-Ressourcenverbrauch

Ich habe einen lokalen Kubernetes-Cluster gestartet und etwa 120 s nach dem abgeschlossenen Start die Ressourcenverbräuche für einen im Leerlauf befindlichen Einzelknoten-Cluster überprüft. Dafür habe ich den Befehl "docker stats" verwendet.

Bitte beachte, dass ich traefik bei k3d deaktiviert habe, um eine vergleichbare Konfiguration zu erhalten. Da k3d mindestens zwei Container ausführt, habe ich die Verbräuche aggregiert.

Hier sind die Ergebnisse:

Bei Betrachtung der Ergebnisse kann man einige Unterschiede zwischen Minikube und k3d oder Kind erkennen. Für einen leeren und im Leerlauf befindlichen Cluster benötigt Minikube etwa 35% mehr Speicher als k3d und 17% mehr Speicher als Kind. Ich vermute, dass mit zunehmender Anzahl von Workloads der Ressourcenverbrauch von Minikube sehr schnell an die Grenze der Entwicklungsmaschine stoßen wird.

In jedem Fall war ich sehr überrascht von der CPU-Auslastung, die von 10% auf 50% stieg, obwohl in diesen Clustern nichts los war. Dieses Muster trat bei allen Kubernetes-Anbietern auf.

Benutzerfreundlichkeit und Entwicklererfahrung (DX)

Benutzerfreundlichkeit und DX sind sehr komplexe Themen und es ist schwierig, quantitative Metriken zu finden. Dennoch möchte ich einige meiner Erkenntnisse hervorheben, die mir an den Tools gefallen oder nicht gefallen.

Alle Tools sind derzeit nur als CLI (Befehlszeilenschnittstelle) verfügbar. Das ist für mich in Ordnung und wahrscheinlich für einen Großteil der Entwickler auf Linux und macOS. Soweit ich weiß, arbeiten nur wenige Entwickler unter Windows gerne mit einem Terminal. Aus ihrer Sicht bietet eine CLI wahrscheinlich nicht die bestmögliche DX. Es gibt jedoch einige GUIs (grafische Benutzeroberflächen). Meine Ergebnisse dazu habe ich im nächsten Kapitel hinzugefügt.

Minikube

Minikube wird mit einer CLI geliefert, die viele Emojis verwendet. Das ist eine sehr individuelle Vorliebe, aber ich finde sie ein wenig nervig. Allerdings können sie deaktiviert werden.

Die Installation ist sehr einfach. Du kannst es über Brew, ein Skript oder als Binärdatei herunterladen und manuell in deinen Pfad legen.

Minikube macht es sehr einfach und schnell, einen neuen Cluster zu erstellen. Es ist nur ein Befehl mit zwei Wörtern: minikube start. So einfach ist das. Wie gibt man Konfigurationsoptionen an? Genau! Direkt als Argument für den Startvorgang. Eine sehr wichtige Konfiguration ist die Kubernetes-API-Version. Es spielt keine Rolle, welche Version von Minikube du auf deinem lokalen Rechner installiert hast. Du kannst immer eine andere Kubernetes-API-Version als die Standardversion auswählen. Das ist sehr einfach und intuitiv. Dein Produktionscluster läuft auf Version 1.25.5, dann möchtest du Folgendes ausführen:

minikube start --kubernetes-version=1.25.5

...und du erhältst die richtige API- Version.

Andere grundlegende Clusteroperationen sind ähnlich: Das Anhalten, Stoppen oder Löschen des Clusters erfolgt immer mit nur einem Befehl.

Saubere CLI, schnelles Kubernetes Dashboard

Die Befehlspalette der minikube CLI ist sauber und übersichtlich. Wenn du mit mehreren Clustern parallel arbeitest, die entweder gestartet sind oder sich im Ruhezustand befinden, kannst du immer das Argument -p/--profile zu den meisten Aktionen hinzufügen und die gewünschte Aktion auf dem angegebenen Cluster ausführen.

Wie listet man alle vorhandenen Cluster auf der Maschine auf? Das ist eine

minikube profile list

...und dir wird eine Liste der erstellten Cluster angezeigt.

Wenn du einen laufenden Cluster hast, kannst du immer das offizielle Kubernetes-Dashboard mit minikube dashboard öffnen (für das Standardprofil). Natürlich kannst du das Kubernetes-Dashboard immer auf jedem Cluster installieren, aber dieser Befehl ist wirklich eine Abkürzung, um nach wenigen Sekunden eine visuelle Benutzeroberfläche für diesen Cluster zu erhalten.

Ingress hinzufügen

Wenn du eine Kubernetes-Bereitstellung oder einen Dienst auf deiner lokalen Entwicklungsmaschine freigeben musst, verwende einfach die Netzwerk- und Verbindungskommandos:

Ein häufiges Komponente, die über Addons aktiviert werden muss, ist der Ingress-Controller. Normalerweise ist dies die bevorzugte Methode, um eine Anwendung freizugeben. Mit Minikube hast du standardmäßig keinen Ingress-Controller zur Verfügung, stattdessen musst du ihn manuell bereitstellen. Glücklicherweise gibt es ein Addon mit dem bekannten und weit verbreiteten "nginx-ingress". Führe einfach aus:

minikube addons enable ingress

und du kannst Ingress-Objekte erstellen, die unter http://192.168.49.2 bereitgestellt werden. Bitte beachte, dass die IP-Adresse deines Clusters eine andere sein kann. Du kannst sie herausfinden mit

minikube ip

Kritik

Es gibt nur eine Kritik, die ich an Minikube habe: die schlechten Automatisierungsoptionen. Es gibt keine Konfigurationsdatei, die ich einfach in den Befehl eingeben kann, um einen gesamten Cluster gemäß den Vorgaben einzurichten. Stattdessen muss ich all diese Befehle sequentiell ausführen. Das ist schade und kann in Zukunft verbessert werden.

Ein Befehl zum Generieren des Tab-Completion-Skripts ist auch für viele Terminals verfügbar.

k3d

Die Installation der k3d CLI ist sehr einfach. Du kannst sie über Brew, ein Skript oder als Binärdatei herunterladen und manuell in deinen Pfad legen. Die CLI benötigt jedoch etwas Zeit, um sich daran zu gewöhnen. Im Vergleich zu Minikube bietet k3d nicht so viele Funktionen auf der Befehlszeile, aber du kannst mit k3d fast alle erforderlichen Setups genauso gut realisieren.

Weniger CLI-Optionen, aber Ingress out of the box

Ein Entwickler wird die meisten praktischen Funktionen vermissen, die die Minikube CLI bietet, aber bei der k3d-CLI fehlen. Das ist jedoch kein großes Problem. Wenn du ein erfahrenerer Entwickler bist, arbeitest du wahrscheinlich sehr effizient mit kubectl und kennst andere Tools aus dem Ökosystem wie Helm oder Kustomize. Wenn du beispielsweise das Kubernetes-Dashboard benötigst, musst du es über Helm installieren (oder eine andere Installationsmethode). Das ist kein großes Problem, aber es ist nicht so bequem wie bei Minikube. Sobald du einen Cluster erstellt hast, wird dein globaler kubeconfig-Kontext so eingestellt, dass er auf den neuen Cluster zeigt.

k3d wird mit Traefik als Ingress-Controller geliefert. Es ist immer installiert, es sei denn du deaktivierst es explizit mit einem Konfigurationsflag. Bei Blueshoe fanden wir es sehr hilfreich, es immer verfügbar zu haben, da wir dieses wichtige Feature während der Entwicklungseinrichtung nicht extra handhaben mussten.

Port-Mapping meh

Das Festlegen des Port-Mappings auf deinem lokalen Rechner kann etwas umständlich sein. Wenn du beispielsweise eine Anwendung über Ingress auf Port 8080 auf deiner Entwicklungsmaschine freigeben möchtest, musst du dies während der Clustererstellung angeben. Und die Notation ist für Entwickler nicht super intuitiv. Schaue dir die Dokumentation an. Erstelle einen Cluster mit einer festen Reihe von Port-Mappings wie folgt:

k3d cluster create -p "8080:80@loadbalancer" -p "8443:443@loadbalancer" …

Es sind auch andere Portkonfigurationen möglich, aber aus Sicht der Entwicklererfahrung ist es nicht sehr praktisch, den gesamten Cluster neu zu erstellen, nur weil man vergessen hat, die Ports zuzuordnen.

Wenn du nur als Entwickler in einem Team arbeiten möchtest, erhältst du wahrscheinlich sowieso eine Cluster-Konfigurationsdatei. Mit dieser Datei und den richtigen Spezifikationen wird es dir leichtfallen, alles einzurichten. Du musst nur noch starten:

k3d cluster create --config myconfig.yaml

...und innerhalb weniger Sekunden bist du startklar. Das ist schnell und sehr bequem. Ein großes Plus für die Entwicklererfahrung mit k3d.

Es gibt auch einen Befehl, um das Tab-Completion-Skript für viele Terminals zu generieren.

kind

kind ist in den meisten Aspekten sehr ähnlich zu k3d. Genau wie k3d und minikube kannst du es mit beliebten Paketmanagern, Skripten und als einzelne ausführbare Datei installieren.

Wenn du bereits mit der k3d CLO vertraut bist, wirst du dich wahrscheinlich schnell an die kind CLI gewöhnen. Die Optionen sind fast identisch, und auch die Einschränkungen sind ähnlich.

Es gibt in diesem Abschnitt nicht viel hinzuzufügen.

Entwicklungsoptionen

Es kann herausfordernd und umständlich sein, deinen eigenen Code in einem der Kubernetes-Tools auszuführen. Zunächst musst du Container-Images erstellen, da Kubernetes nur das Ausführen von Container-Instanzen zulässt. Normalerweise bezieht Kubernetes diese Images aus einem externen Container-Register (wie Dockerhub, quay.io oder einem selbst gehosteten Register). Wenn ein Entwickler eigenen Code ausführen möchte, erfordert dies eine Arbeitslastspezifikation und ein Register, das das Container-Image bereitstellt. Dies kann zu einem enormen Effizienzverlust führen.

Glücklicherweise bieten alle Tools einige Workarounds oder Abkürzungen, um diese Hürde zu überwinden (zumindest teilweise).

Lokalen Code einbinden

minikube und k3d bieten die Möglichkeit, Code direkt von der Entwicklermaschine in den laufenden Kubernetes-Knoten einzubinden.

Mit k3d ist dies mit dem lokalen Pfadbereitsteller von k3s möglich. Ein Entwickler kann einen PersistentVolumeClaim erstellen, der auf einen Pfad im Host-System verweist. Anschließend kann dieser PVC in eine Container-Instanz eingebunden und im Container-Prozess verwendet werden. Dadurch kannst du entweder einen Container-Prozess mit dem aktuellen Code ausführen (den Container neu starten, sobald der Code geändert wurde) oder den Container-Prozess mit Hot-Reloading-Funktionen starten. Natürlich ist dies stark abhängig von einem Framework oder Prozess, der ausgeführt wird, und hat nichts mit Kubernetes zu tun. Dies funktioniert jedoch nur bei der Erstellung des Clusters wie folgt:

k3d cluster create my-cluster --volume /my/home/go/src/github.com/nginx:/data

Das Hinzufügen von Volumes nachdem der Cluster erstellt und ausgeführt wird, ist noch ein offenes Problem.

Mit dem minikube mount-Befehl ist dasselbe möglich. Du kannst sogar Speichervolumes nach der Erstellung des Clusters einbinden. Anstatt einen Kubernetes PVC zu verwenden, kannst du den Code mit der hostPath-Eigenschaft eines Pods einbinden, was es etwas bequemer macht.

Lokales Container-Image laden

Ein praktischerer und weniger invasiver Ansatz, um lokalen Code in minikube, k3d und kind auszuführen, ist die Load-Image-Funktion. Warum weniger invasiv? - Als Entwickler musst du die Kubernetes-Objekte (Pods, PVCs usw.) für deine lokale Umgebung nicht anpassen, basierend auf den Pfaden, die möglicherweise einzigartig für dein System sind (z. B. das Einbinden von Home-Verzeichnissen unterscheidet sich normalerweise zwischen Entwicklern). Stattdessen stellst du ein Container-Image für deinen lokalen Cluster zur Verfügung, ohne dass ein dediziertes Container-Register erforderlich ist. Das bedeutet, du erstellst ein lokales Container-Image basierend auf deinem aktuellen Code (z. B. docker build . -t myimage) und überträgst es direkt in dein lokales Kubernetes, um es auszuführen.

Dieser Ansatz wird von fast allen Kubernetes-Entwicklungstools wie tilt.dev, devspace und anderen genutzt. Diese Arten von Entwicklungstools führen automatisch einen Build-Load-Execute-Zyklus durch, während sie auf Codeänderungen achten. Dieser Ansatz ist langsamer als das Einbinden von lokalem Code mit einem angepassten Container-Prozess, aber zumindest modifiziert er (normalerweise) nicht die Kubernetes-Objekte.

Um dies mit minikube zu tun, führst du aus...

minikube image load <name>

Bei k3d lade ein Image mit...

k3d image import <name>

und bei kind ist es...

kind load docker-image <name>

...von deiner Konsole aus.

Es gibt noch einige andere verfügbare Tools wie ksync, das Code in Container kopiert, die in Kubernetes laufen, aber mit einem allgemeineren technischen Ansatz. Eine großartige Option für Entwickler, die mit jeder Art von Kubernetes-Umgebung, sei es lokal oder remote, arbeiten, wird im nächsten Abschnitt vorgestellt.

Die beste Alternative für die lokale Kubernetes-Entwicklung

Die oben genannten Optionen machen nicht alle erforderlichen Entwicklungsfunktionen leicht zugänglich. Zum Beispiel ist das Überschreiben von Umgebungsvariablen nicht sehr einfach, da sie aus verschiedenen Kubernetes-Objekten stammen können: ConfigMaps, Secrets, Pod-Spezifikationen, Downward API und andere. Ein Entwickler, der nicht daran gewöhnt ist, mit Kubernetes zu arbeiten, könnte Schwierigkeiten haben, mit Umgebungsvariablen herumzuspielen.

Der allmächtige Debugger, der nicht einfach an einen in Kubernetes ausgeführten Prozess angehängt werden kann, ist mit den oben genannten Optionen nicht sehr praktisch. Die oben genannten Optionen haben auch einige andere Nachteile.

An diesem Punkt hat Blueshoe beschlossen, ein anspruchsvolleres Entwicklungstool zu entwickeln, das Entwickler von der Zeit im Build-Load-Execute-Zyklus oder vom Ausführen lokaler Verzeichnisse in Kubernetes entlastet: Gefyra.

Gefyra verbindet sich nicht nur mit lokalen Kubernetes-Clustern, die auf minikube, k3d oder kind basieren. Es verbindet sich mit praktisch jedem Kubernetes-Cluster, der irgendwo läuft. Dies ermöglicht Gefyra-Benutzern, dedizierte Entwicklungsumgebungen in der Cloud zu erstellen und gleichzeitig lokales Codieren für die Entwickler bereitzustellen.

Gefyra führt den Code auf einer lokalen Docker-Laufzeitumgebung aus (ganz ohne Kubernetes), erledigt jedoch einige Netzwerk- und Prozessmagie, um die lokale Container-Instanz mit einem Kubernetes-Cluster zu verbinden. Der Prozess auf einer Entwicklermaschine fühlt sich an, als würde er direkt in einem Kubernetes-Namespace ausgeführt (einschließlich Netzwerkfunktionen) und bietet den Vorteil, dass alle gängigen Entwicklungstools lokal verfügbar sind. Dies kann die Entwicklungsgeschwindigkeit drastisch verbessern und gleichzeitig eine sehr gute Übereinstimmung zwischen Entwicklung und Produktion gewährleisten.

Wenn du eine Meinung zu Gefyra hast, fehlende Funktionen oder einen Fehler melden möchtest, kannst du gerne ein Issue oder eine Diskussion auf GitHub eröffnen.

Grafische Benutzeroberflächen und Docker Desktop

Wenn du nach einer grafischen Benutzeroberfläche für deinen lokalen Kubernetes-Cluster suchst, wirf einen Blick auf K3x und minikube GUI. Beide Projekte befinden sich zum Zeitpunkt des Verfassens dieses Artikels noch in einem sehr frühen Entwicklungsstadium.

Die Hauptziele dieser Projekte sind es, dem Benutzer zu ermöglichen, Kubernetes-Cluster mit einem Mausklick zu erstellen, zu starten und zu beenden. Darüber hinaus ermöglichen sie Entwicklern, die wichtigsten Operationen mit Tastenkombinationen zu verwalten und die Lernkurve bei der Verwendung von Kubernetes zu reduzieren.

Und dann gibt es Docker Desktop, das eine eigene Kubernetes-Lösung mitbringt. Allerdings bietet Kubernetes in Docker Desktop nicht wirklich die Funktionen, die minikube, k3d oder kind bieten. Du kannst lediglich einen Kubernetes-Cluster mit einer grafischen Benutzeroberfläche starten und stoppen.

Eine cloud-basierte Kubernetes-Entwicklungsumgebung mit Getdeck

Bei Blueshoe haben wir festgestellt, dass lokale Kubernetes-Cluster mit wachsenden Arbeitslasten eine Herausforderung darstellen. Insbesondere unter Windows und macOS verwandelt selbst eine geringe Anzahl von Entwicklungsaufgaben in Kubernetes die Entwicklungsmaschine in einen langsamen Zombie. Das war sehr unpraktisch, daher haben wir uns entschieden, nach anderen Lösungen für unsere Entwicklungsteams zu suchen. Für die komplexe Kubernetes-native Softwarearchitektur, an der wir arbeiten, war es nicht möglich, eine gemeinsame Cluster-Konfiguration zu erstellen. Das Aufteilen eines physischen Clusters mit Namespaces ist etwas, das viele Entwicklungsteams derzeit tun. Stattdessen wollten wir unseren Entwicklern dedizierte, vollwertige, bedarfsgesteuerte Kubernetes-Cluster zur Verfügung stellen. Aber mit allen Funktionen, die eine reife Entwicklungsorganisation benötigt, wie z.B. Lebenszyklusmanagement, Ressourcenbeschränkungen usw.

Dafür haben wir Getdeck entwickelt.

Mit Getdeck Beiboot muss ein Team von Entwicklern nur einen physischen Kubernetes-Cluster betreiben. Der Beiboot-Operator erstellt "virtuelle" Kubernetes-Cluster innerhalb des Host-Clusters und verwaltet deren Lebenszyklen. Die Erstellung einer ad-hoc Kubernetes-Umgebung dauert etwa 20 Sekunden und beansprucht keine Ressourcen auf einer Entwicklungsmaschine.

Darüber hinaus ermöglicht die Beiboot Shelf-Funktion Entwicklern, vorkonfigurierte Kubernetes-Cluster von der Stange zu erstellen. Das bedeutet, es dauert nur wenige Sekunden länger und Entwickler haben einen dedizierten Kubernetes-Cluster, der alle erforderlichen Arbeitslasten für ihre Aufgaben enthält und alle Daten enthält, die erforderlich sind, um die Produktionsinfrastruktur abzubilden. Dies ist nicht nur bequem für Entwicklungszwecke, sondern auch für automatisierte Aufgaben in CI/CD-Szenarien.

Und das Beste daran: Diese Cluster werden zum lokalen Rechner getunnelt, so dass es sich so anfühlt, als würden sie auf dem lokalen Host ausgeführt werden. Das ist sehr praktisch.

Getdeck kommt jetzt auch mit einer grafischen Benutzeroberfläche: Getdeck Desktop.

Damit können Entwickler Beiboot-Cluster in kürzester Zeit verwalten. Sie können eine Verbindung dazu herstellen und damit arbeiten, als würde es auf ihrem lokalen Rechner laufen, aber ohne dass der Computer abstürzt.

Du kannst dies mit unserem kostenlosen Getdeck-as-a-Service-Angebot einfach testen. Lade einfach die Desktop-App herunter, gib einige Ports ein, erstelle einen Cluster und beginne mit der Entwicklung in einem virtuellen Kubernetes-Cluster, der von uns gehostet und bezahlt wird. Der Cluster unterliegt folgenden Einschränkungen:

Abschließende Bemerkungen

Es ist sehr schwierig, in diesem Vergleich einen Gewinner zu ermitteln. Alle drei etablierten Lösungen, minikube, k3d und kind, sind sehr ähnlich zueinander. Es gibt einige Vor- und Nachteile für jede Lösung, aber nichts, was wirklich herausragt. Das ist gut, denn es ist auch nicht wirklich möglich, das falsche Tool auszuwählen. Mir gefällt die allgemeine Benutzerfreundlichkeit aller dieser Tools, da sie eine professionelle Arbeitsumgebung ansprechen. Alle sind schnell, einfach zu installieren und ziemlich einfach zu bedienen.

Ich habe das Gefühl, dass minikube etwas voraus ist und der offiziellen Kubernetes-Entwicklungs-Roadmap am nächsten kommt. Insbesondere für einen einzelnen (potenziell unerfahrenen) Entwickler scheint die Einstiegshürde ziemlich niedrig zu sein. Es ist jedoch die Option mit dem höchsten Ressourcenbedarf. Ich würde Kubernetes-Einsteigern minikube empfehlen.

Bei Blueshoe waren wir in der Vergangenheit sehr zufrieden mit k3d. Besonders wenn du viele verschiedene Kubernetes-Cluster ausführst, wirst du über den geringeren Ressourcenverbrauch im Vergleich zu minikube erfreut sein. Wenn du in einem Team arbeitest, werden die mit k3d oder kind gelieferten Konfigurationsdateien für alle von großem Nutzen sein.

Für einige unserer automatisierten Testfälle sind wir auf minikube umgestiegen, aufgrund des --kubernetes-version Arguments. Es ist sehr einfach, die gewünschte Kubernetes-Version festzulegen und voilà, es läuft. Bei k3d musst du dir das entsprechende k3s Docker-Image ansehen, das verwendet werden soll.

Langfristig betrachten wir die lokale Kubernetes-Entwicklung tatsächlich nicht als nachhaltige Option. Remote-Entwicklungsumgebungen sind die Zukunft! Getdeck Beiboot wird alle auf Kubernetes basierenden Ressourcen ausführen, und mit Tools wie Gefyra ermöglichen wir Entwicklern, in einer echten Kubernetes-basierten Entwicklungsumgebung zu arbeiten.

Wenn du mehr über die Kubernetes-basierte Entwicklung erfahren möchtest, kannst du mir auf LinkedIn folgen, unserem Discord beitreten oder uns bei Blueshoe kontaktieren .