Der passende Workflow für den Mac
Ein Kubernetes-Cluster auf einem Laptop ist eine Kopie von etwas, das eigentlich anderswo läuft. Für viele Plattform- und Anwendungsaufgaben brauchst du diese Kopie nicht: Du brauchst schnelle Rückmeldung zum Container selbst, zu den Diensten, mit denen er kommuniziert, und ein Terminal am echten Cluster. Auf einem Mac mit Apple-Chip ergeben sich daraus vier Aufgaben.
| Aufgabe | Tool | Auf Oxcart |
|---|---|---|
| Cluster untersuchen und verwalten | kubectl, k9s | Native Mac-Werkzeuge; Verbindung zu jedem kubeconfig-Kontext |
| Images für den Cluster bauen | docker buildx build | amd64- und arm64-Images gemeinsam bauen |
| Die App und ihre Abhängigkeiten ausführen | docker compose | Deinen Stack mit Healthchecks, up --wait und veröffentlichten Ports starten |
| Manifeste gegen einen API-Server testen | kwok | Manifeste gegen eine echte Control Plane mit simulierten Nodes und Pods prüfen |
kubectl und k9s mit deinen Clustern verwenden
kubectl und k9s lesen dieselbe kubeconfig. Was du mit einem erreichen kannst, kannst du daher mit dem anderen durchsuchen. Cloud-CLIs schreiben die Kontexte für dich hinein: aws eks update-kubeconfig, az aks get-credentials und gcloud container clusters get-credentials fügen jeweils einen Kontext hinzu.
kubectl config get-contexts # every cluster in your kubeconfig
kubectl config use-context my-eks # switch the current context
kubectl get pods -A # works against the current context
k9s # the same context, in a terminal UI
k9s --context my-aks --readonly # another context, read-only Installiere k9s mit Homebrew oder MacPorts, wie auf der Installationsseite beschrieben. Halte getrennte kubeconfig-Dateien pro Umgebung vor und wähle mit KUBECONFIG=~/.kube/staging k9s eine aus, wenn die Produktionsumgebung außer Reichweite bleiben soll.
Images für den Cluster bauen
Die meisten Cluster verwenden amd64-Nodes, dein Mac dagegen arm64. Buildx auf Oxcart baut beide aus einem Dockerfile mit dem Standard-Builder:
docker buildx ls # default builder: linux/amd64, linux/arm64
docker buildx build --platform linux/amd64,linux/arm64 -t myapp:dev .
docker run --rm --platform linux/amd64 myapp:dev # runs through Rosetta
docker run --rm --platform linux/arm64 myapp:dev # runs natively Übergib --platform linux/amd64, wenn du ein lokal gebautes, nur für amd64 verfügbares Image ausführst. Pushe für die Bereitstellung einen Tag pro Plattform oder lass CI ein Manifest für mehrere Architekturen veröffentlichen, das für jeden Node das richtige Image auswählt:
docker buildx build --platform linux/amd64 --load -t registry.example.com/myapp:1.4.0-amd64 .
docker push registry.example.com/myapp:1.4.0-amd64 Builds sind schnell: Oxcart erreichte 341 ms für einen Build ohne Cache mit kleinem lokalem Kontext und 121 ms mit Cache, am schnellsten unter den drei getesteten Laufzeitumgebungen. docker login speichert Registry-Passwörter im macOS-Schlüsselbund.
Die Abhängigkeiten der App mit Compose ausführen
Während der Service, an dem du arbeitest, mit einem entfernten Cluster kommuniziert, können seine Datenbank, sein Cache und seine Queue auf deinem Mac laufen. Eine compose.yaml mit Healthchecks und depends_on: condition: service_healthy startet mit docker compose up -d --wait; der Befehl kehrt erst zurück, wenn jeder Service gesund ist. Ein vollständiges Beispiel findest du unter Docker Compose auf Apple-Chips. Container starten schnell genug, um sie zwischen Testläufen abzubauen: 42 ms für docker run --rm und 77 ms zum Stoppen und Entfernen von 20 Containern.
Eine echte Kubernetes-API auf deinem Mac mit kwok
kwok (Kubernetes WithOut Kubelet) startet die echten Komponenten der Control Plane als Container und simuliert Nodes und Pods. Auf Oxcart startete kwokctl etcd, kube-apiserver, kube-scheduler und kube-controller-manager (v1.36.1) in etwa 15 Sekunden einschließlich der Image-Downloads, und kubectl sowie k9s auf dem Mac stellten die Verbindung her.
kwokctl create cluster --name dev --runtime docker
kwokctl scale node --replicas 2 --name dev
kubectl apply -f deploy.yaml
kubectl rollout status deploy/web # "successfully rolled out"
kubectl get pods -o wide # 3/3 Running on simulated nodes
k9s # browse it like any cluster
kwokctl delete cluster --name dev Prüfe damit, ob sich Manifeste anwenden lassen, RBAC-Regeln die erwarteten Aktionen erlauben und ein Controller oder Operator richtig mit der API kommuniziert, oder lerne k9s, ohne einen gemeinsam genutzten Cluster zu berühren. Kein Container aus deinem Deployment läuft tatsächlich: Die Pods sind Datensätze im API-Server, die kwok als Running markiert.
Wähle, wo dein Cluster läuft
Behalte deinen schnellen Entwicklungszyklus auf dem Mac und nutze den Cluster, der zu deinem Team passt. Ein gemeinsam genutzter Entwicklungscluster bietet allen dieselben Controller, Richtlinien und Cloud-Integrationen. Ein lokaler Cluster ist nützlich, wenn du echte Pods brauchst, ohne mit dieser Umgebung verbunden zu sein.
Oxcart unterstützt privilegierte Container für Workloads, die erhöhte Berechtigungen innerhalb von Linux benötigen. Ein vollständiger Kubernetes-Cluster hängt außerdem von der Netzwerk- und Laufzeitkonfiguration des Clusterwerkzeugs ab. Für einen in eine Desktop-App integrierten Cluster siehe den Vergleich von Container-Apps für den Mac; für die tägliche App-Entwicklung halten die oben beschriebenen Workflows mit Compose, Buildx und kwok die Iteration lokal.
Cloud-Cluster von deinem Mac aus
- EKS: Baue und pushe nach ECR, dann
aws eks update-kubeconfig. Siehe AWS ECS, EKS, Fargate und Lambda lokal. - AKS: Pushe in Azure Container Registry, dann
az aks get-credentials. Siehe Azure Container Apps und AKS lokal. - GKE und Cloud Run: Pushe in Artifact Registry; Cloud Run benötigt
linux/amd64. Siehe Cloud Run lokal.
Fragen
Wie passt Oxcart in einen Kubernetes-Workflow?
Nutze Oxcart, um Images zu bauen, die App und ihre Abhängigkeiten lokal auszuführen und Manifeste mit einem lokalen kwok-API-Server zu testen. Privilegierte Container gehören zur Plattform. Nutze kubectl und k9s auf deinem Mac für deinen gemeinsam genutzten oder Cloud-Cluster; Oxcart enthält keinen Kubernetes-Cluster.
Gibt es eine lokale Kubernetes-API, die ich mit Oxcart verwenden kann?
Ja. kwok führt eine echte Kubernetes-Control-Plane (etcd, kube-apiserver, kube-scheduler und kube-controller-manager, v1.36 in unserem Test) als Oxcart-Container aus, und kubectl sowie k9s auf deinem Mac verbinden sich damit. Nodes und Pods werden simuliert. Sie dient daher zum Testen von Manifesten, RBAC und API-Verhalten, nicht zum Ausführen der Container deiner App.
Funktionieren kubectl und k9s auf einem Mac mit Apple-Chip?
Ja. Beide sind native macOS-Kommandozeilenwerkzeuge. Sie verwenden deine kubeconfig und funktionieren daher mit jedem Cluster, auf den sie verweist: EKS, AKS, GKE, einem Cluster bei der Arbeit oder einem lokalen API-Server. k9s dokumentiert die Installation mit Homebrew und MacPorts.
Wie baue ich auf einem Mac mit Apple-Chip Images für einen amd64-Kubernetes-Cluster?
Verwende Buildx mit --platform linux/amd64 oder mit --platform linux/amd64,linux/arm64 für beide. Auf Oxcart wird der Build für mehrere Plattformen mit dem Standard-Builder abgeschlossen, und beide Architekturen laufen lokal. Das Pushen eines Images für mehrere Plattformen aus Oxcart wird nicht unterstützt. Pushe daher einen Tag pro Plattform oder lass CI das Manifest für mehrere Architekturen veröffentlichen.
Wo kann ich einen vollständigen lokalen Kubernetes-Cluster auf dem Mac ausführen?
Mehrere Container-Apps für den Mac enthalten einen Cluster mit einem Node. Sie werden mit Quellen auf der Vergleichsseite gegenübergestellt. Viele Teams entwickeln stattdessen mit einem gemeinsam genutzten oder Cloud-Cluster und führen nur die Abhängigkeiten der App lokal aus. Diesen Workflow behandelt diese Anleitung.
Braucht k9s einen Metrics-Server?
k9s verbindet sich auch ohne ihn; es protokolliert eine Warnung und lässt die CPU- und Speicherspalten leer, wenn der Cluster keine Metrics-API hat. In unserem kwok-Test meldete es „Kubernetes connectivity OK“ zusammen mit dieser Warnung.
Quellen und Methode
- Beispiel für eine lokale API: Oxcart 0.1.2, Mac17,14, macOS 27.2, 2026-10-10; kwokctl v0.8.0, k9s v0.51.0 und kubectl v1.33.9.
- kwok: https://kwok.sigs.k8s.io/; k9s: https://k9scli.io/ und https://k9scli.io/topics/install/; kind: https://kind.sigs.k8s.io/docs/user/known-issues/; k3d: https://k3d.io/stable/; minikube-Treiber: https://minikube.sigs.k8s.io/docs/drivers/. Geprüft am 2026-10-10.
- Build- und Containergeschwindigkeit: Oxcart 0.1.2, 2026-10-10, Apple M5 Max, 8 CPUs und 12 GiB, Mediane aus fünf Messungen; die anderen Laufzeitumgebungen wurden früher am selben Tag auf demselben Mac mit demselben Messaufbau und dem docker-Client 29.4 gemessen.