Kubernetes on a Mac in 2026: kubectl, k9s and local clusters

The workflow that fits a Mac

A Kubernetes cluster on a laptop is a copy of something that really runs elsewhere. For a lot of platform and application work you don’t need that copy: you need fast feedback on the container itself, the services it talks to, and a terminal open on the real cluster. On an Apple silicon Mac that splits into four jobs.

kubectl and k9s against your clusters

kubectl and k9s read the same kubeconfig, so whatever you can reach with one you can browse with the other. Cloud CLIs write contexts into it for you: aws eks update-kubeconfig, az aks get-credentials and gcloud container clusters get-credentials each add a context.

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

Install k9s with Homebrew or MacPorts, as its install page documents. Keep separate kubeconfig files per environment and pick one with KUBECONFIG=~/.kube/staging k9s when you want production out of reach.

Build images for the cluster

Most clusters run amd64 nodes, and your Mac is arm64. Buildx on Oxcart builds both from one Dockerfile on the default 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

Pass --platform linux/amd64 when you run an amd64-only image you built locally. For deployment, push one tag per platform, or let CI publish a multi-architecture manifest that selects the right image for each node:

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 are quick: Oxcart measured 341 ms for an uncached build of a small local context and 121 ms cached, the fastest of the three runtimes we tested. docker login keeps registry passwords in the macOS Keychain.

Run the app’s dependencies with Compose

While the service you are changing talks to a remote cluster, its database, cache and queue can run on your Mac. A compose.yaml with healthchecks and depends_on: condition: service_healthy comes up with docker compose up -d --wait and returns only when every service is healthy. See Docker Compose on Apple silicon for a full example. Containers start fast enough to tear down between test runs: 42 ms for docker run --rm and 77 ms to stop and remove 20 containers.

A real Kubernetes API on your Mac with kwok

kwok (Kubernetes WithOut Kubelet) starts the real control-plane components as containers and simulates nodes and pods. On Oxcart, kwokctl brought up etcd, kube-apiserver, kube-scheduler and kube-controller-manager (v1.36.1) in about 15 seconds including the image pulls, and kubectl and k9s on the Mac connected to it.

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

Use it to check that manifests apply, that RBAC rules allow what you expect, that a controller or operator talks to the API correctly, and to learn k9s without touching a shared cluster. No container from your Deployment actually runs: the pods are records in the API server, marked Running by kwok.

Choose where your cluster lives

Keep your fast feedback loop on the Mac and use the cluster that fits your team. A shared development cluster gives everyone the same controllers, policies and cloud integrations. A local cluster is useful when you need real pods while disconnected from that environment.

Oxcart supports privileged containers for workloads that need elevated permissions inside Linux. A full Kubernetes cluster also depends on the cluster tool’s networking and runtime configuration. For a cluster bundled into a desktop app, see the Mac container app comparison; for day-to-day app development, the Compose, Buildx and kwok workflows above keep iteration local.

Cloud clusters from your Mac

• EKS: build and push to ECR, then aws eks update-kubeconfig. See AWS ECS, EKS, Fargate and Lambda locally.
• AKS: push to Azure Container Registry, then az aks get-credentials. See Azure Container Apps and AKS locally.
• GKE and Cloud Run: push to Artifact Registry; Cloud Run needs linux/amd64. See Cloud Run locally.

Questions

How does Oxcart fit a Kubernetes workflow?

Use Oxcart to build your images, run the app and its dependencies locally, and test manifests with a local kwok API server. Privileged containers are part of the platform. Use kubectl and k9s on your Mac for your shared or cloud cluster; Oxcart does not bundle a Kubernetes cluster.

Is there any local Kubernetes API I can use with Oxcart?

Yes. kwok runs a real Kubernetes control plane (etcd, kube-apiserver, kube-scheduler and kube-controller-manager, v1.36 in our test) as Oxcart containers, and kubectl and k9s on your Mac connect to it. Its nodes and pods are simulated, so it is for testing manifests, RBAC and API behaviour, not for running your app’s containers.

Do kubectl and k9s work on an Apple silicon Mac?

Yes. Both are native macOS command-line tools. They use your kubeconfig, so they work with any cluster it points to: EKS, AKS, GKE, a cluster at work, or a local API server. k9s documents installation with Homebrew and MacPorts.

How do I build images for an amd64 Kubernetes cluster on an Apple silicon Mac?

Use Buildx with --platform linux/amd64, or --platform linux/amd64,linux/arm64 for both. On Oxcart the multi-platform build completes on the default builder and both architectures run locally. Pushing a multi-platform image from Oxcart is not supported, so push one tag per platform or let CI publish the multi-arch manifest.

Where can I run a full local Kubernetes cluster on a Mac?

Several Mac container apps bundle a single-node cluster. They are compared, with sources, on the comparisons page. Many teams instead develop against a shared or cloud cluster and run only the app’s dependencies locally, which is the workflow this guide covers.

Does k9s need a metrics server?

k9s connects without one; it logs a warning and leaves CPU and memory columns empty when the cluster has no metrics API. In our kwok test it reported “Kubernetes connectivity OK” with that warning.

Sources and method

• Local API example: Oxcart 0.1.2, Mac17,14, macOS 27.2, 2026-10-10; kwokctl v0.8.0, k9s v0.51.0 and kubectl v1.33.9.
• kwok: https://kwok.sigs.k8s.io/; k9s: https://k9scli.io/ and https://k9scli.io/topics/install/; kind: https://kind.sigs.k8s.io/docs/user/known-issues/; k3d: https://k3d.io/stable/; minikube drivers: https://minikube.sigs.k8s.io/docs/drivers/. Checked 2026-10-10.
• Build and container speed: Oxcart 0.1.2, 2026-10-10, Apple M5 Max, 8 CPUs and 12 GiB, medians of five samples; the other runtimes were measured earlier the same day on the same Mac and harness with the docker 29.4 client.