Einführung

Minikube betreibt einen echten Upstream-Kubernetes-Cluster auf Ihrem Laptop — und trotz des Namens ist es seit v1.10 aus dem Jahr 2020 nicht mehr auf einen einzelnen Node beschränkt. 2026 ist es neben kind und k3d eine von drei ernstzunehmenden Optionen für lokales Kubernetes, und die richtige Wahl hängt davon ab, was Sie vorhaben. Eine veraltete Vorstellung sollten Sie zuerst verwerfen: Sie brauchen keinen Hypervisor. Der Docker-Driver ist seit Jahren der Standard- und bevorzugte Driver von Minikube; der Cluster läuft in einem Container auf der Docker Engine, die Sie ohnehin schon haben. VirtualBox und Hyper-V stehen als Driver weiterhin zur Verfügung, sind aber der Legacy-Pfad und keine Voraussetzung.

Minikube installieren

Wählen Sie Ihre Plattform:

# macOS
brew install minikube

# Windows
winget install Kubernetes.minikube

# Linux
curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

Falls Sie kubectl nicht installiert haben: Minikube bringt eines mit — starten Sie es als minikube kubectl -- get nodes, oder legen Sie einen Alias an und vergessen Sie das Thema.

Quickstart: Von null zum laufenden Service

Starten Sie den Cluster und deployen Sie etwas — ein Tutorial, das bei kubectl get nodes aufhört, hat Ihnen Kubernetes noch nicht gezeigt:

minikube start --driver=docker
kubectl get nodes

kubectl create deployment web --image=nginx:1.27
kubectl expose deployment web --type=NodePort --port=80
minikube service web

Der letzte Befehl öffnet den Service in Ihrem Browser und tunnelt dabei zum NodePort im Cluster. Ab hier sind es die Addons, mit denen Minikube seinen Platz verdient — je ein Befehl für Komponenten, die Sie sonst von Hand installieren müssten:

minikube addons enable ingress
minikube addons enable metrics-server
minikube dashboard

Der Schritt, an dem die meisten Einsteiger stolpern, ist das Ausführen des eigenen Codes: Der Cluster kann Images nicht sehen, die nur im Docker-Daemon Ihres Hosts existieren. Ein schlichtes kubectl create deployment gegen einen lokal gebauten Tag scheitert daher mit ImagePullBackOff. Laden Sie das Image nach dem Build entweder in den Cluster, oder richten Sie den Docker-Client Ihrer Shell auf die Runtime von Minikube und bauen Sie direkt darin:

# Option 1: auf dem Host bauen, dann hineinkopieren
minikube image load shop-api:dev

# Option 2: direkt in die Runtime des Clusters bauen
eval $(minikube docker-env)
docker build -t shop-api:dev .

Setzen Sie in beiden Fällen imagePullPolicy: IfNotPresent im Deployment, damit Kubernetes das lokale Image verwendet, statt es aus einer Registry ziehen zu wollen.

Sie möchten Scheduling-Verhalten, Pod Disruption Budgets oder Node-Ausfälle proben? Erstellen Sie einen Multi-Node-Cluster und pinnen Sie die Kubernetes-Version passend zur Produktion:

minikube start --nodes 3 --kubernetes-version=v1.33.1 -p lab
kubectl get nodes
minikube stop -p lab      # Cluster pausieren
minikube delete -p lab    # vollständig entfernen

Minikube vs. kind vs. k3d

Alle drei sind gut; sie optimieren nur auf unterschiedliche Dinge.

  • minikube bietet das vollständigste lokale Erlebnis: Upstream-Kubernetes, einen Addon-Katalog (Ingress, metrics-server, Registry), mehrere Driver und Container-Runtimes sowie wählbare Kubernetes-Versionen. Ideal zum Lernen, für die tägliche Entwicklung und um Produktionsverhalten lokal zu reproduzieren.
  • kind (Kubernetes-in-Docker) wurde gebaut, um Kubernetes selbst zu testen. Cluster werden in einer kleinen YAML-Datei definiert, starten schnell und sind trivial wegwerfbar — weshalb es die CI/CD-Pipelines dominiert, die pro Testlauf einen Cluster gegen mehrere Kubernetes-Versionen hochfahren müssen. Weniger Komfort: kein Addon-System, und um Ingress oder einen Load Balancer kümmern Sie sich selbst.
  • k3d betreibt k3s — die leichtgewichtige, CNCF-zertifizierte Distribution — in Docker. Es startet am schnellsten, ist am sparsamsten beim RAM, bringt einen eingebauten Load Balancer mit und ist die natürliche Wahl, wenn Ihre Edge- oder Produktionsumgebung ohnehin k3s einsetzt.

Faustregel: Zum Entwickeln und Lernen nehmen Sie Minikube; für Wegwerf-Cluster in der CI nehmen Sie kind; für k3s-Parität oder einen schwachen Laptop nehmen Sie k3d.

Fazit

Ein lokaler Cluster ist ein hervorragendes Entwicklungswerkzeug und eine schlechte Produktions-Generalprobe — er zeigt Ihnen weder die Eigenheiten von Load Balancern noch IAM-Grenzen oder Upgrade-Schmerzen, die eine echte Umgebung offenlegt. Wenn Sie für diesen Schritt bereit sind: Unsere Notizen zu Kubernetes in der Praxis beschreiben, was sich ändert, und unser DevOps-Team hilft Teams dabei, den Weg von minikube start zu einem produktionsreifen Cluster zu gestalten.

Sie betreiben so etwas in Produktion? Unser AWS Managed Services-Team betreibt solche Umgebungen rund um die Uhr — Monitoring, Incident Response, Patching und Kostenkontrolle durch namentlich benannte Senior Engineers, ab €3.000/Monat.

Tags: #Kubernetes #DevOps #Docker #LokaleEntwicklung