Kubernetes lokal auf dem eigenen Rechner zu betreiben ist der schnellste Weg, die Technik wirklich zu lernen. Du brauchst dafür keine Serverfarm: Minikube, kind und k3s starten einen vollständigen Cluster in einem Container oder einer kleinen VM auf deinem Notebook, und du arbeitest darauf mit demselben kubectl wie später in Produktion. Welches Werkzeug passt, hängt davon ab, ob du lernen, mehrere Nodes simulieren oder etwas dauerhaft laufen lassen willst.
Der lokale Cluster ist nur eine Simulation eines verteilten Systems. Rechenleistung und Größe enden bei deinem Rechner, und einige Themen wie Node-Ausfälle oder echtes Netzwerk zwischen Servern lassen sich damit nur begrenzt nachstellen. Für fast alles, was du in den ersten Monaten mit Kubernetes machst, reicht das trotzdem völlig aus.
Ich betreibe Kubernetes-Cluster produktiv, und mein Kubernetes-Praxisbuch bei Rheinwerk (2024) baut komplett auf einem lokalen Minikube auf, weil jeder Leser damit sofort loslegen kann. Alle meine Beiträge zum Thema findest du gesammelt auf der Seite Kubernetes.
Welches Werkzeug für welchen Zweck: Minikube, kind, k3s oder Docker Desktop
Alle vier Werkzeuge liefern dir einen echten Kubernetes-API-Server, den kubectl nicht von einem Cluster in der Cloud unterscheiden kann. Der Unterschied liegt darin, wie sie den Cluster aufbauen, wie viele Nodes sie können und was drumherum mitgeliefert wird.
| Werkzeug |
Wie der Cluster läuft |
Mehrere Nodes |
Wofür ich es nutze |
| Minikube |
Ein Container oder eine VM, wahlweise mehrere |
ja, mit --nodes |
Lernen, Buchbeispiele, Addons wie Registry, Ingress und Dashboard |
| kind |
Jede Node ist ein Docker-Container |
ja, über eine YAML-Datei |
Mehrere Nodes ohne Hardware, Tests in CI-Pipelines |
| k3s |
Ein einzelnes Binary direkt auf dem Betriebssystem |
ja, Server und Agents |
Dauerbetrieb auf Linux-Servern und Raspberry Pis |
| Docker Desktop |
Ein Cluster in der Docker-VM, per Schalter aktiviert |
nein |
Schneller Test, wenn Docker Desktop ohnehin läuft |
Meine Empfehlung für den Einstieg ist Minikube. Es funktioniert auf allen drei Betriebssystemen gleich, bringt die nützlichsten Erweiterungen mit und hat eine Fehlerausgabe, die dir sagt, was zu tun ist. kind nimmst du, wenn du gezielt mehrere Nodes brauchst oder einen Cluster in einer Pipeline hochziehen willst. k3s ist das Werkzeug, wenn der Cluster nicht auf dem Notebook, sondern auf einem kleinen Server oder Raspberry Pi wohnen soll.
Voraussetzungen auf macOS, Windows und Linux
Für Minikube und kind brauchst du eine laufende Docker Engine. Auf macOS und Windows ist das in der Regel Docker Desktop. Prüfe vorher, ob du dafür eine Lizenz brauchst: Docker Desktop ist für größere Unternehmen kostenpflichtig, und die Bedingungen ändern sich gelegentlich. Alternativen wie Podman oder Colima funktionieren mit Minikube ebenfalls, aber die Anleitung hier bleibt bei Docker, weil das die wenigsten Überraschungen bringt.
Auf Linux reicht die Docker Engine ohne Desktop-Oberfläche. Wenn du k3s nutzen willst, brauchst du nicht einmal Docker: k3s bringt seine Container-Runtime mit.
Ein Hinweis aus vielen Schulungen: Firmenrechner mit strengen Sicherheitsrichtlinien sind für diese Anleitungen ein häufiges Problem. Eingeschränkte Rechte, geblockte Ports oder ein Proxy, der den Image-Download verhindert, kosten oft mehr Zeit als die eigentliche Installation. Wenn du kannst, nimm einen Rechner, den nicht deine IT verwaltet. Wenn nicht, sprich vorher mit deinem Administrator.
Bei den Ressourcen nennt die Minikube-Dokumentation als Minimum zwei CPU-Kerne, 2 GB freien Arbeitsspeicher und 20 GB Plattenplatz. In der Praxis ist Arbeitsspeicher der Engpass: Sobald du eine echte Anwendung mit Datenbank deployst, willst du dem Cluster mehr geben. Auf Apple-Silicon-Macs läuft Minikube nativ als ARM-Variante, das musst du beim manuellen Download beachten.
|
Minikube |
k3s |
| Gedacht für |
Entwicklung auf dem eigenen Rechner |
dauerhaften Betrieb auf kleiner Hardware |
| Läuft in |
einer VM oder einem Container |
direkt auf dem Betriebssystem |
| Cluster wegwerfen |
minikube delete, Sekunden |
Deinstallation je Knoten |
| Mehrere Knoten |
möglich, aber selten nötig |
der Normalfall |
| Passt, wenn |
du ein Manifest ausprobieren willst |
du etwas laufen lassen willst |
Wer nur ein Manifest testen will, bleibt bei Minikube. Wer einen Cluster über Wochen laufen lassen will, ist mit k3s auf eigener Hardware besser dran, dazu steht der Aufbau in Kubernetes auf dem Raspberry Pi.
Minikube installieren und Kubernetes lokal starten
Auf dem Mac ist Homebrew der einfachste Weg, auf Windows der Paketmanager winget oder Chocolatey, auf Linux das Paket für deine Distribution. Alle Varianten stehen in der Minikube-Dokumentation, hier die drei, die ich am häufigsten nutze: die erste Zeile für macOS mit Homebrew, die zweite für Windows in der PowerShell, die letzten beiden für Linux auf x86-64 als Binary.
brew install minikube
winget install Kubernetes.minikube
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
Die Paket-ID Kubernetes.minikube stammt aus der Minikube-Dokumentation; ich arbeite selbst auf macOS und Linux, den Windows-Weg habe ich nicht auf einem eigenen System durchlaufen. Mit minikube version prüfst du, ob das Werkzeug im Pfad liegt. Danach startest du den Cluster:
minikube start
Beim ersten Start lädt Minikube das Image für die Node herunter, das dauert je nach Leitung ein paar Minuten. Danach läuft auf deinem Rechner ein Kubernetes-Cluster in einem Docker-Container, und kubectl get nodes zeigt dir eine Node im Status Ready. Minikube richtet dabei den Kontext in deiner kubeconfig automatisch ein.
Im Alltag brauchst du vier Befehle: minikube pause und minikube unpause halten alle Container an, wenn du den Cluster gerade nicht brauchst, und sparen Akku. minikube stop fährt den Cluster sauber herunter und behält den Zustand, das ist der richtige Befehl vor dem Feierabend. minikube delete löscht alles und gibt dir einen frischen Cluster, was du öfter brauchen wirst, als du denkst.
Eigene Images bringst du am einfachsten ohne Registry in den Cluster. Mit eval $(minikube docker-env) zeigt dein Docker-Client auf den Docker-Daemon in Minikube; alles, was du danach baust, liegt bereits im Cluster und muss nirgends hochgeladen werden. Setze im Deployment imagePullPolicy: IfNotPresent, sonst versucht Kubernetes trotzdem, das Image aus dem Internet zu ziehen. Den eval-Befehl musst du in jeder neuen Shell wiederholen oder in deine .zshrc beziehungsweise .bashrc schreiben. Wer lieber eine echte Registry im Cluster will, aktiviert sie mit minikube addons enable registry.
kind: mehrere Nodes in Docker-Containern
kind steht für „Kubernetes in Docker" und macht genau das: Jede Node deines Clusters ist ein Docker-Container, in dem kubelet und die Container-Runtime laufen. Das macht kind sehr schnell im Start und sehr gut geeignet für alles, was mehrere Nodes braucht: Scheduling-Regeln, Taints und Tolerations, DaemonSets oder das Verhalten beim Drainen einer Node.
Die Cluster-Form beschreibst du in einer kleinen YAML-Datei. Diese Konfiguration erzeugt eine Control-Plane und zwei Worker:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
Gespeichert als kind-config.yaml startest du den Cluster mit kind create cluster --config kind-config.yaml. Nach kurzer Zeit zeigt kubectl get nodes drei Nodes, und du kannst zum Beispiel mit kubectl cordon und kubectl drain üben, wie Kubernetes Pods verschiebt. Die Details zur Konfiguration findest du in der kind-Dokumentation.
In meinen Projekten läuft kind vor allem in CI-Pipelines: Ein Cluster wird für den Testlauf erzeugt, Helm-Charts werden installiert und geprüft, danach wird alles wieder gelöscht. Auf dem Notebook ist Minikube für mich praktischer, weil die Addons für Ingress und Registry fertig daliegen. Bei kind musst du dafür selbst einen Ingress-Controller installieren und Ports in der Konfiguration durchreichen.
k3s vs. k8s: der schlanke Weg auf Server und Raspberry Pi
k3s ist kein Ersatz für Kubernetes, sondern eine zertifizierte Distribution davon. Alle Kubernetes-Komponenten stecken in einem einzigen Binary, statt etcd nutzt es standardmäßig SQLite, und einige selten gebrauchte Funktionen sind entfernt oder als Erweiterung ausgelagert. Aus Sicht von kubectl und deiner Manifeste gibt es keinen Unterschied zu einem vollständigen k8s. Der Unterschied liegt im Betrieb: k3s braucht deutlich weniger Arbeitsspeicher, startet in Sekunden und lässt sich auf ARM-Boards installieren.
Die Installation eines Servers ist ein Befehl:
curl -sfL https://get.k3s.io | sh -
Danach liegt die kubeconfig unter /etc/rancher/k3s/k3s.yaml und der Cluster läuft als Systemdienst. Um weitere Nodes anzuhängen, brauchst du das Token des Servers aus /var/lib/rancher/k3s/server/node-token und die IP-Adresse des Servers:
curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.10:6443 K3S_TOKEN=<token-vom-server> sh -
Genau so baue ich den Cluster aus Raspberry Pis, den ich im Buch beschreibe und der bei mir jahrelang als Testumgebung gelaufen ist. Und in meinen Kundenprojekten läuft k3s produktiv in deutscher Cloud mit drei Control-Plane-Nodes in drei Rechenzentren: Die schlanke Distribution ist also nicht auf das Homelab beschränkt. Wer k3s in Docker statt direkt auf dem Betriebssystem will, nimmt k3d, das denselben Ansatz wie kind verfolgt und k3s-Nodes als Container startet. Alle Optionen stehen im k3s-Projekt auf GitHub.
Das erste Deployment im lokalen Cluster
Egal für welches Werkzeug du dich entschieden hast, ab hier ist alles gleich. Ein kurzer Test, ob dein Cluster wirklich Arbeit annimmt:
kubectl create deployment hallo --image=nginx
kubectl expose deployment hallo --port=80 --type=NodePort
kubectl get pods
Das Deployment startet einen Pod mit Nginx, der Service macht ihn über einen Port an der Node erreichbar. Bei Minikube öffnet minikube service hallo direkt den Browser mit der richtigen Adresse. Bei kind und k3s liest du den Port aus kubectl get service hallo ab und rufst ihn über die IP der Node auf.
Sobald das läuft, lohnt sich der Schritt zu einem Ingress: minikube addons enable ingress installiert den Nginx-Ingress-Controller, und du kannst mit einer Ingress-Ressource Hostnamen auf Services abbilden, so wie später in Produktion. Bei k3s ist Traefik als Ingress-Controller bereits vorinstalliert. Mit diesen Grundlagen bist du bereit für den Alltag mit kubectl, den ich in kubectl Befehle: die wichtigsten im Alltag zusammengefasst habe.
Typische Fehler beim Start
Der häufigste Fehler ist ein nicht laufender Docker-Daemon. Minikube meldet dann etwas wie PROVIDER_DOCKER_NOT_RUNNING und die Frage Is the docker daemon running?. Die Lösung steht in der Meldung: Docker Desktop starten und minikube start wiederholen. Das passiert vor allem nach einem Neustart, wenn Docker nicht im Autostart liegt.
Der zweite Klassiker ist command not found: minikube direkt nach der Installation. Das Binary liegt noch nicht im Pfad, meistens hilft ein neues Terminal-Fenster. Bei der Installation von Hand unter Windows prüfst du, ob das Verzeichnis wirklich in der PATH-Variable steht.
Ein dritter Fall, den ich oft in Schulungen sehe: Der Cluster startet, aber Pods bleiben in ImagePullBackOff. Fast immer steckt ein Proxy oder eine Firewall dahinter, die den Download der Images blockiert. Auf Firmenrechnern ist das der Moment, in dem du den Administrator brauchst. Und wenn nach viel Experimentieren nichts mehr passt, ist minikube delete und ein frischer Start schneller als jede Fehlersuche.
Vom Laptop zur Produktion
Der lokale Cluster ist die Lernumgebung, nicht das Ziel. Was auf Minikube funktioniert, funktioniert in der Cloud in aller Regel auch, aber einige Dinge verhalten sich anders: Persistente Volumes kommen lokal von einem einfachen Hostpath-Provisioner, in Produktion von einem Storage-System mit ganz anderen Eigenschaften. Ein Service vom Typ LoadBalancer bleibt in Minikube ohne externe IP, solange du nicht minikube tunnel laufen lässt; k3s bringt dafür einen eigenen kleinen Load Balancer mit. Und der Ausfall einer Node ist mit einem Container nicht zu simulieren.
Deshalb empfehle ich einen Zwischenschritt, wenn dich Kubernetes ernsthaft interessiert: ein kleiner Cluster aus mehreren echten Rechnern. Wie ich meinen Cluster aus Raspberry Pis mit k3s aufgebaut habe und was du dabei über Netzwerk, Storage und Ausfälle lernst, steht in Kubernetes auf dem Raspberry Pi. Und wer verstehen will, was in den Containern von Minikube und kind eigentlich läuft, findet die Komponenten in Kubernetes-Architektur: die Komponenten.
Häufige Fragen
Minikube oder kind: was ist besser für den Einstieg?
Für den Einstieg Minikube. Es läuft auf allen Betriebssystemen gleich, bringt Registry, Ingress und Dashboard als Addons mit und gibt bei Fehlern verständliche Hinweise. kind ist besser, wenn du mehrere Nodes brauchst oder den Cluster in einer CI-Pipeline erzeugen willst. Beide lassen sich problemlos nebeneinander installieren.
Ist k3s produktionsreif oder nur für das Homelab?
k3s ist eine von der CNCF zertifizierte Kubernetes-Distribution und wird produktiv eingesetzt, auch bei mir. Für den Produktionsbetrieb ersetzt du SQLite durch etcd oder eine externe Datenbank und betreibst mehrere Server-Nodes. Die Frage k3s vs. k8s ist deshalb weniger eine Frage der Reife als der Umgebung: kleine Server, Edge und ARM sprechen für k3s, große Cloud-Umgebungen für die verwalteten Angebote der Anbieter.
Reicht Docker Desktop mit aktiviertem Kubernetes?
Für einen schnellen Test, ob ein Manifest überhaupt funktioniert, ja. Docker Desktop startet einen Cluster mit einer Node per Schalter in den Einstellungen. Sobald du Addons, mehrere Nodes oder einen sauberen Neustart des Clusters brauchst, bist du mit Minikube oder kind besser bedient.
Wie viel Arbeitsspeicher braucht Kubernetes lokal?
Die Minikube-Dokumentation nennt 2 GB freien Arbeitsspeicher als Minimum. Damit läuft der Cluster, aber wenig darauf. Bei mir bekommt Minikube auf dem Notebook deutlich mehr, weil ich Datenbanken und Monitoring mit deploye. Wie viel du wirklich brauchst, hängt von deinen Anwendungen ab, nicht von Kubernetes selbst.
Was brauche ich für ein Kubernetes Homelab?
Für den Anfang nichts außer deinem Rechner und Minikube. Wenn du einen Kubernetes-Cluster aus echter Hardware aufbauen willst, reichen zwei bis vier Raspberry Pis oder gebrauchte Mini-PCs mit k3s. Der Vorteil gegenüber dem lokalen Cluster: echtes Netzwerk, echte Ausfälle und die Möglichkeit, Dienste dauerhaft laufen zu lassen.
Wie du weitermachst
Starte heute mit minikube start und dem Deployment von oben. Wenn das läuft, arbeite dich durch die wichtigsten Befehle in kubectl Befehle: die wichtigsten im Alltag und schau dir in Kubernetes-Architektur: die Komponenten an, welche Komponenten in deiner Node gerade laufen. Wenn dich das Thema packt, ist Kubernetes auf dem Raspberry Pi der nächste Schritt.
Ausführlich mit allen Beispielen, von der Installation auf jedem Betriebssystem bis zur Container Registry in Minikube, steht das in Kapitel 2 meines Buchs „Kubernetes: Das Praxisbuch für Entwickler und DevOps-Teams" (Rheinwerk). Alle Informationen zum Buch findest du auf meiner Kubernetes-Seite.
