The M2 Air.
the node I already owned.

A homelab built from what was lying around. Which meant getting a real Linux onto Apple hardware, and finding out that the hard part is not the install. It is convincing the machine to let you.

The premise. Build with what you have.

Most homelab writeups start with a shopping list. A rack, a switch, three mini PCs, a NAS. That is a fine way to build one, and it is not the way this one is getting built.

The rule here is simpler. Use the hardware already in the house. Not because buying is wrong, but because the constraint is more interesting. Idle hardware is the cheapest hardware there is, and working around what it cannot do teaches you more than working with something purpose-built.

Which brings us to a MacBook Air that had stopped being anyone’s daily driver.

Why an M2 Air is a good node

On paper it is an odd choice for a server. No ethernet, a battery, a lid that wants to sleep. But look at what it actually brings:

• arm64, natively. The same architecture as a Raspberry Pi, with none of the performance apology.
• Low idle draw. A machine that sips power is a machine you leave on.
• Fanless and silent. It can live somewhere a mini PC cannot.
• A built-in UPS. The battery is not a bug for a server. It is an hour of runtime through a power cut.
• Fast NVMe. etcd and container image pulls both care about this more than you would think.

That is a genuinely good k3s node. The problem is the operating system on it.

Concept review. Why macOS will not do.

You can run containers on macOS. You cannot run them on macOS. Docker Desktop and its relatives spin up a Linux VM and run everything inside that. The kernel doing the work is always a Linux kernel, just a hidden one.

Kubernetes wants the real thing. Namespaces, cgroups v2, and systemd are Linux kernel features, and k3s expects to talk to them directly. Wrapping that in a VM means a hypervisor between the scheduler and the hardware, memory carved off in advance, and a networking layer that has to be translated twice.

For a laptop that is fine. For a cluster node that is meant to behave like every other node, it is not. If the goal is bare-metal Kubernetes, the metal has to actually run Linux.

Which leaves Asahi

Asahi Linux is the project reverse-engineering Apple Silicon and writing the drivers nobody else has. Fedora Asahi Remix is its flagship distribution, and for now it is the only realistic way to get a working Linux onto an M-series Mac.

Going in, I expected the install to be the hard part. Partitioning a boot disk, driver gaps, the usual. That was not it.

The hard part is that Apple Silicon cannot boot from external media at all. There is no USB stick. There is no live environment to fall back into. The installer is a shell script you run from inside macOS, against the internal drive, on the machine you are currently sitting at. And the step that actually authorizes a custom bootloader has to happen from a specific recovery mode, entered a specific way, or it fails with an error that tells you the password was wrong.

The password was not wrong. That one cost four attempts and most of an evening.

Where this goes

The Air is one node. The plan is a small k3s cluster across the Mac hardware in the house, with Flux handling gitops, and the build log going into kubecraft as it happens. Confidence levels included, especially the low ones.

Part 2 is the runbook. Every prompt, every command, and all seven failures with their causes, written so that the next person does not lose the same evening.