Why I Replaced Multipass with OrbStack and what an M1 vs M4 Mac taught me about local Kubernetes.

Part 1 of 7 — “The Mac Kubernetes Lab: A Production-Mirror Setup from Scratch.”

Here’s something nobody warned me about running Kubernetes on Apple Silicon: the same lab setup will work on one chip and fail silently on another. I learned this twice.

The first time was when my Multipass-based cluster broke after I moved from an M1 Pro to an M4. Everything I’d put together over months — four VMs, a kubeadm cluster, the lot — stopped working in a way the error messages couldn’t quite explain. The QEMU drivers Multipass relies on weren’t compatible with the M4’s hardware, and there was no quick fix. The setup was gone.

The second time was months later. I’d long since replaced Multipass with OrbStack on the M4, and it had been working beautifully. Out of curiosity, I tried to put the same OrbStack cluster on my old M1. The VMs came up fine. kubeadm finished. Calico installed. And then everything sat in NotReady for an entire evening while I read kernel docs to figure out why iptables NAT was silently misbehaving inside an unprivileged LXC container on one chip but not the other.

What I ended up with is a Kubernetes lab that runs on either chip, mirrors a real EKS production cluster, and taught me more about Apple’s Virtualization Framework and Linux container capabilities than I ever wanted to know.

This is part one of a seven-part series walking through that setup from scratch. By the end, you’ll have a dual-cluster Kubernetes environment on your Mac — one fast daily-driver cluster for iteration, one full VM-based cluster that mirrors production EKS, complete with Vault PKI, Istio, and Crossplane. We’ll start by replacing Multipass.

The Multipass setup that worked, then didn’t.

For most of 202,4 my local Kubernetes setup was on Multipass. Four Ubuntu VMs on my M1 Pro, a kubeadm cluster, and a working developer loop. It wasn’t fast, Multipass VMs took 30 to 60 seconds to boot and pre-allocated memory, whether you used it or not, but it worked, and it was familiar. Then I upgraded to an M4, and it stopped.

Multipass on macOS uses QEMU under the hood. The QEMU driver bundled with the version of Multipass I had didn’t play nicely with the M4’s silicon. VMs failed to launch with errors that didn’t map cleanly to anything actionable. I spent a weekend on the Multipass GitHub issues looking for someone with the same problem and a fix. That weekend is when I tried OrbStack instead, and I never went back.

What OrbStack is, and why the switch wasn’t just about boot time.

OrbStack is a macOS-native tool for running Linux VMs and Docker containers. The thing that matters for our purposes is that it’s built specifically for Apple Silicon, using Apple’s Virtualization Framework, written in Swift, Go, Rust, and C — not a port of something originally designed for x86.

The numbers that made me commit:

The boot time alone is a different category of experience. Spinning up a four-VM cluster used to be a “go make coffee” event. With OrbStack, the whole cluster is up in under 15 seconds.

But the part I underestimated was the networking. OrbStack shiwith a built-in Kubernetes cluster: one command and you have a working cluster with real LoadBalancer IPs and wildcard DNS out of the box. No MetalLB, and/etc/hosts editing. You apply a Service of type LoadBalancer, and you can hit it from your Mac browser at something.k8s.orb.local. The first time it just worked, I genuinely thought I had misconfigured it.

One pricing note — OrbStack is free for personal use, which covers everything in this series. If you’re rolling it out across a team or using it commercially at work, check orbstack.dev/pricing. The grey area worth knowing: a home lab on your own Mac is free. A work laptop doing your day job is commercial use.

The architecture: two clusters, one tool.

After a few weeks, I settled on a dual-cluster setup. Two clusters for two different jobs.

Cluster 1 — OrbStack native K8s, the daily driver. Single-node, always on, sips memory. This is where I do fast iteration: Helm chart testing, Crossplane composition development, and Istio Gateway experiments. The wildcard DNS and real LoadBalancer IPs mean I can ship a service and open it in a browser in under a minute. I break things in this cluster constantly, and that’s the point of having it.

Cluster 2 — A VM-based kubeadm cluster. Four OrbStack Linux VMs running a real kubeadm-bootstrapped cluster on Kubernetes 1.34. This is where the production-mirror lives: Vault PKI is the cluster’s certificate authority, Istio with revision-based upgrades (the same way I manage it in EKS at work), Crossplane with the AWS provider, ArgoCD for my GitOps, and multi-node topology so I can actually test pod disruption budgets, node affinity, and disk-pressure scenarios. This cluster is also where I do my CKS exam preparation, because it’s a real kubeadm cluster — not a magic single-node abstraction.

The clusters share nothing. Different contexts, different DNS, different LoadBalancer implementations. I switch between them with kubectx orbstack and kubectx lab-cluster. The native cluster is kubectx orbstack; the VM cluster I'll set up in Parts 3 and 4.

The second surprise: M1 vs M4.

This is the part I didn’t see coming until I tried it.

OrbStack works flawlessly on M4. I built the entire dual-cluster setup, including the kubeadm VM cluster, and every component came up on the first try. Months later, on a whim, I tried to replicate the same setup on my M1 Pro. The VMs booted, kubeadm initialised and I installed Calico.

Nothing worked!!

Nodes stayed NotReady. kube-proxy crashed in a loop. The tigera-operator pod logged dial tcp 10.96.0.1:443: connect: connection refused. The Calico pods looked healthy from the outside, but were completely non-functional from the inside.

The root cause turned out to be a kernel capability difference:

OrbStack VMs run as unprivileged LXC containers on both chips. On M4, the iptables NAT table is fully writable from inside the container. On M1, M2, and M3, it isn’t! Kube-proxy can’t write the KUBE-SERVICES chain, which means ClusterIP services aren't reachable, which means any CNI plugin that tries to call the Kubernetes API server through the ClusterIP 10.96.0.1 fails to start. Calico is one of those plugins. So is half the ecosystem!

The fix is Cilium, which uses eBPF-based service routing instead of iptables and completely replaces kube-proxy. I’ll cover the full debugging walk-through and the Cilium install in Part 4, because it’s the most technically interesting thing in this series — and probably useful to anyone running unprivileged Linux containers in restricted environments, not just OrbStack on Apple Silicon.

What you’ll need to follow along

• An Apple Silicon Mac (M1, M2, M3, or M4)
• Homebrew
• At least 16 GB of RAM — 8 GB will technically work, but you’ll feel it once all four VMs are running
• Roughly 20 GB of free disk.

Pre-checks:

# 💻 Mac — check your chip
system_profiler SPHardwareDataType | grep Chip

# Check available disk
df -h 

If you’re on an Intel Mac, this series isn’t for you — none of it depends on x86, but the whole point is the Apple Silicon experience, and I haven’t tested any of it on Intel.

The Multipass → OrbStack migration, if you’re coming from Multipass.

The command mapping in short:

Install OrbStack and clean out Multipass:

# 💻 Mac
brew install orbstack
open -a OrbStack   # required once for first-time GUI setup

# Remove Multipass and its leftover state
brew uninstall multipass
sudo rm -rf /var/root/Library/Application\ Support/multipassd
sudo rm -rf ~/Library/Application\ Support/multipass

OrbStack auto-installs orb, docker, and kubectl on your PATH. If you already have any of those installed via Homebrew, you may want to check which version comes first in your shell.

What’s coming in the rest of the series

• Part 2 — Cluster 1: the native K8s daily driver, with Istio, Vault, and Crossplane installed and running in under 10 minutes.
• Part 3 — Cluster 2: creating the four VMs, networking them, and standing up a 3-tier Vault PKI that will sign every certificate in the kubeadm cluster.
• Part 4 — kubeadm 1.34 on OrbStack: the full M1 vs M4 CNI deep dive, including the Cilium debugging walkthrough.
• Part 5 — Istio with revision-based upgrades and MetalLB on the VM cluster.
• Part 6 — Vault Kubernetes auth and Crossplane with the AWS provider, completing the EKS mirror.
• Part 7 — Day 2 operations: stop/start without losing state, CKS exam scenarios, and the shell setup that makes the whole thing pleasant.

If you’ve been running a Multipass setup that’s no longer working — whether because of an M4 upgrade like mine, or just because the boot times finally wore you out, this is the series I wish I had when I started. Part 2 picks up the moment OrbStack is installed: one command, working Kubernetes cluster, Istio talking to your browser through wildcard DNS.

Part 2: One Command, One Working Kubernetes Cluster! Building My Daily-Driver Lab on OrbStack →

I’m Noah Makau, a DevSecOps engineer based in Nairobi. I run a small DevOps consultancy and hold CKA, CKAD, and AWS Solutions Architect Professional certifications, currently preparing for CKS. I write about Kubernetes, Vault, Crossplane, and the day-to-day of running platforms that actually have to stay up.

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN.dev() & get similar stories in your inbox each week for free!