Kubernetes lokal testen mit k3d

29.07.2026

Mit k3d steht ein lokaler Kubernetes-Cluster in 20 Sekunden. k3d, kind und minikube sind alle frei lizenziert, gebunden wirst du trotzdem: eine Ebene tiefer, im Unterbau.

Inhaltsverzeichnis

Warum überhaupt lokal
Voraussetzungen
Ein Cluster in unter einer Minute
Den Kontext mit kubectl setzen
- Der Fehler, der wirklich weh tut
Was k3d von kind und minikube unterscheidet
- Der Komfort hat einen Preis
Die Brücke zu k3s
Die Lizenzfrage
Wo du dich wirklich bindest
Was ich empfehle

Warum überhaupt lokal

Wer ein Manifest schreibt, will es ausprobieren, bevor es in einen echten Cluster geht. Ein StatefulSet mit einem PersistentVolumeClaim verhält sich nun einmal anders, als man es beim Schreiben erwartet, und das merkt man erst, wenn es läuft.

Genau dafür gibt es Werkzeuge, die einen vollständigen Kubernetes-Cluster auf dem eigenen Rechner hochziehen. Ich zeige dir hier k3d, das ich für den Alltag am praktischsten finde, und ordne es danach ehrlich gegen kind und minikube ein. Am Ende kommt die Frage, die bei solchen Vergleichen fast immer fehlt: Wo bindest du dich eigentlich, und was kostet das in einem größeren Unternehmen.

Voraussetzungen

Docker läuft bereits, mehr braucht es nicht. k3d selbst ist eine einzelne Binärdatei:

curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash
k3d version

k3d version v5.9.0
k3s version v1.35.5-k3s1 (default)

Die zweite Zeile ist schon der wichtigste Hinweis auf das, was hier passiert. Dazu später mehr.

Ein Cluster in unter einer Minute

k3d cluster create dev

Das war es. Nach etwa zwanzig Sekunden steht ein einsatzbereiter Cluster:

kubectl get nodes

NAME                STATUS   ROLES                  AGE   VERSION
k3d-dev-server-0    Ready    control-plane,master   18s   v1.35.5+k3s1

Mehrere Knoten und ein durchgereichter Port sind je ein Flag:

k3d cluster create dev --agents 2 -p "8080:80@loadbalancer"

--agents 2 erzeugt zwei zusätzliche Worker als eigene Container. Das Port-Mapping hängt Port 8080 deines Rechners an den mitgelieferten Loadbalancer, sodass ein Ingress unter http://localhost:8080 erreichbar ist.

Cluster anhalten, weiterlaufen lassen und wegwerfen:

k3d cluster stop dev
k3d cluster start dev
k3d cluster delete dev

Das Wegwerfen ist der eigentliche Punkt. Ein lokaler Cluster ist kein Haustier. Wenn du etwas kaputt konfiguriert hast, ist Löschen und neu Anlegen schneller als jede Fehlersuche.

Den Kontext mit kubectl setzen

k3d schreibt die Zugangsdaten von sich aus in deine ~/.kube/config und schaltet den aktiven Kontext auf den neuen Cluster um. Beide Optionen stehen standardmäßig auf true:

k3d cluster create dev \
  --kubeconfig-update-default=true \
  --kubeconfig-switch-context=true

Der Kontext heißt immer k3d- plus Clustername:

kubectl config get-contexts

CURRENT   NAME             CLUSTER      AUTHINFO           NAMESPACE
*         k3d-dev          k3d-dev      admin@k3d-dev
          prod-cluster     prod         admin              default

Umschalten und nachsehen, wo du gerade bist:

kubectl config use-context k3d-dev
kubectl config current-context

Der Fehler, der wirklich weh tut

Und jetzt der Teil, den ich in Schulungen am häufigsten sehe. Das automatische Umschalten ist bequem, aber es funktioniert auch in die andere Richtung: Wenn du den lokalen Cluster löschst, bleibt irgendein anderer Kontext aktiv. Und wenn das der Produktionscluster ist, geht dein nächstes kubectl apply dorthin.

Es gibt zwei saubere Auswege. Entweder du verbietest k3d das Umschalten:

k3d cluster create dev --kubeconfig-switch-context=false

Oder, besser, du hältst die lokale Konfiguration komplett getrennt:

k3d cluster create dev --kubeconfig-update-default=false
k3d kubeconfig get dev > /tmp/k3d-dev.yaml
export KUBECONFIG=/tmp/k3d-dev.yaml

In dieser Shell erreichst du nur noch den lokalen Cluster. Schließt du das Terminal, ist die Verbindung weg. Für Experimente ist das die Variante, die ich empfehle, weil ein Versehen technisch ausgeschlossen ist und nicht nur unwahrscheinlich.

Was k3d von kind und minikube unterscheidet

Alle drei lösen dieselbe Aufgabe, aber nicht auf dieselbe Weise.

	k3d	kind	minikube
Startet	k3s in Docker-Containern	Upstream-Kubernetes in Docker-Containern	Cluster in VM oder Container
Startzeit	sehr kurz	kurz	am längsten
Laufzeitumgebung	Docker, Podman experimentell	Docker, Podman, nerdctl	viele Treiber, auch ohne Docker
Mehrere Knoten	ja	ja	ja
Ab Werk enthalten	Traefik, ServiceLB, local-path	bewusst nichts	Addons zuschaltbar
Getragen von	k3d-Community, k3s von SUSE	Kubernetes SIG Testing	Kubernetes-Projekt

k3d ist am schnellsten und am bequemsten. Ein Ingress-Controller, eine LoadBalancer-Implementierung und ein Storage-Provisioner sind schon da. Du legst ein Manifest an und es funktioniert.

kind startet echtes Upstream-Kubernetes, aufgesetzt mit denselben Werkzeugen wie ein richtiger Cluster, und liefert bewusst nichts mit. Es wurde vom Kubernetes-Projekt gebaut, um Kubernetes selbst zu testen. Wenn du wissen willst, wie sich dein Manifest in einem nackten Cluster verhält, ist kind ehrlicher.

minikube ist das älteste und flexibelste der drei. Es kann in einer VM laufen, in einem Container, oder direkt auf dem Blech. Diese Treibervielfalt macht es langsamer, aber unabhängiger, und darauf komme ich beim Thema Lizenzen zurück.

Der Komfort hat einen Preis

Die vorinstallierten Komponenten von k3d sind praktisch, verfälschen aber deinen Test. Ein type: LoadBalancer-Service bekommt lokal eine funktionierende Adresse, weil k3s eine eigene, einfache Implementierung mitbringt. In einem Cluster ohne Cloud-Controller bleibt derselbe Service auf pending stehen. Genauso beim Ingress: lokal antwortet Traefik, in deinem Zielcluster steht vielleicht NGINX mit anderen Annotationen.

Das ist kein Argument gegen k3d, aber ein Argument dafür, zu wissen, was da läuft. Wer den Unterschied nicht kennt, hält einen bestandenen lokalen Test für eine Aussage über die Produktion, und das ist er nicht.

Die Brücke zu k3s

Damit zurück zu der Zeile aus k3d version. k3d ist kein eigenes Kubernetes. Der Name sagt es: k3s in Docker. k3d ist die Verpackung, k3s ist der Inhalt.

k3s ist eine schlanke Kubernetes-Distribution, ursprünglich von Rancher gebaut, heute bei SUSE und seit August 2020 CNCF-Projekt. Gedacht für Umgebungen, in denen ein vollständiges Cluster-Setup zu schwer ist: Edge, IoT, kleine Server, Homelabs. Sie ist zertifiziert konform, ersetzt aber einzelne Bausteine durch leichtere Varianten und packt alles in eine Binärdatei.

Das ist der interessante Unterschied zu den anderen beiden. kind und minikube sind ausdrücklich Werkzeuge zum Entwickeln und Testen, für Produktion sind sie nicht gedacht. Bei k3d ist das anders: Was lokal läuft, ist dieselbe Distribution, die auf einem Server in Produktion laufen kann. Du übst also nicht nur Kubernetes, du übst k3s.

Für alle, die ohnehin in Richtung eigener, schlanker Cluster denken, ist das ein echtes Argument. Wer dagegen für einen großen, verwalteten Cluster entwickelt, sollte wissen, dass er lokal eine andere Distribution vor sich hat.

Die Lizenzfrage

Jetzt der Teil, der in Vergleichen fast immer fehlt.

Projekt	Lizenz	Träger
k3d	MIT	k3d-io, Community
k3s	Apache 2.0	CNCF, Ursprung Rancher, heute SUSE
kind	Apache 2.0	Kubernetes SIG Testing
minikube	Apache 2.0	Kubernetes-Projekt

Alle vier sind echtes Open Source unter OSI-anerkannten Lizenzen. Bei den Werkzeugen selbst bindest du dich also nirgends. Das ist die gute Nachricht, und sie ist auch der Grund, warum man an dieser Stelle meist aufhört zu lesen.

Nur sitzt die Bindung eine Ebene tiefer.

Wo du dich wirklich bindest

k3d und kind brauchen einen Container-Runtime-Unterbau. Bei k3d ist das faktisch Docker, die Podman-Unterstützung ist ausdrücklich experimentell. Und Docker ist nicht gleich Docker.

Docker Engine, das, was unter Linux läuft, steht unter Apache 2.0 und ist frei. Docker Desktop, das, was du unter macOS und Windows installierst, ist ein proprietäres Produkt. Es verlangt eine kostenpflichtige Lizenz pro Nutzer, sobald dein Unternehmen mehr als 250 Mitarbeitende oder mehr als 10 Millionen US-Dollar Jahresumsatz hat. Das ist ein Oder, nicht ein Und. Ein Konzern erfüllt beide Kriterien mühelos.

Daraus ergeben sich zwei sehr unterschiedliche Situationen.

Als Einzelentwickler oder in einer kleinen Firma ist alles frei. Du installierst Docker Desktop, du installierst k3d, fertig. Es entsteht keine Bindung, die dich später einholt.

Als Entwickler in einem größeren Unternehmen sieht es anders aus. Dein Werkzeugkasten ist zwar offen lizenziert, aber der Boden, auf dem er steht, ist es nicht. Konkret heißt das:

Unter Linux ist alles unproblematisch. Docker Engine ist frei, k3d und kind laufen direkt darauf, es fällt keine Lizenz an.
Unter macOS oder Windows brauchst du eine Lösung für die Container-Laufzeit, und die kostenlose Variante heißt dort nicht Docker Desktop. Freie Alternativen sind Rancher Desktop und Podman Desktop, beide unter Apache 2.0, unter macOS zusätzlich colima.
minikube ist hier der unauffälligste Weg, weil es Treiber jenseits von Docker mitbringt und deshalb gar nicht erst in diese Frage gerät.

Und das ist der eigentliche Punkt: Die Lizenz des Werkzeugs zu prüfen, reicht nicht. Alle vier Kandidaten oben bestehen diese Prüfung mühelos. Die Bindung entsteht trotzdem, nur eben im Unterbau, und sie fällt niemandem auf, bis der Einkauf fragt oder eine Lizenzprüfung ansteht.

Was ich empfehle

Für den Alltag: k3d, weil es schnell ist und weil das Wegwerfen und Neuanlegen wirklich nichts kostet. Wenn du zusätzlich in Richtung eigener, schlanker Cluster arbeitest, bekommst du die k3s-Erfahrung gratis dazu.

Wenn dein Manifest gegen einen möglichst neutralen Cluster laufen soll: kind, weil es nichts mitbringt, was dein Ergebnis schönt.

Wenn du in einem Konzern unter macOS oder Windows sitzt und keine Lizenzdiskussion führen willst: minikube mit einem Treiber, der ohne Docker Desktop auskommt, oder k3d auf Rancher Desktop.

Zwei Dinge nimm auf jeden Fall mit. Erstens: Halte die lokale Kubeconfig getrennt, dann kann ein Test nie im falschen Cluster landen. Zweitens: Wisse, welche Distribution du lokal eigentlich startest. Ein bestandener Test auf k3s ist eine Aussage über k3s, nicht automatisch über deinen Zielcluster.

Beides zusammen ist genau das Muster, um das es hier immer geht: Die offene Lizenz gibt dir die Freiheit, und das technische Verständnis sagt dir, was du damit tatsächlich in der Hand hast.

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.