RKE2/K3s on macOS + Apple Containers

The RKE2/K3s project on macOS utilizes Apple's container project as the runtime for each process. RKE2-silicon runs a single Kubernetes node on Apple silicon. The project starts the control plane as Apple containers and returns. A per-user LaunchAgent maintains the node's readiness and starts each pod as a separate container. All containers are Linux micro-VMs.

The cluster operates on the 192.168.128.0/24 network, with the Mac's IP set to 192.168.128.1. The cluster's binaries include etcd, kube-apiserver, kube-controller-manager, and kube-scheduler, which are configured through config.yaml. The node has no rke2 binary, containerd, or kubelet. The up command writes certificates, mounts ~/.rke2-silicon at /var/lib/rke2-silicon, and starts Rancher's hardened images using the Apple container CLI.

The LaunchAgent functions as the kubelet, heartbeats the node, and starts pods. The control plane and workloads run on 192.168.128.0/24, with the Mac's IP as 192.168.128.1. Kubectl interacts with the cluster using https://127.0.0.1:6443. Pods communicate within the network, access host directories via virtiofs, and connect to the GPU broker at 192.168.128.1:10443.

The broker is a host process with a concurrency limit of four. LAN clients utilize a different address, with ingress-address serving as a /32 alias on the LAN interface. The root LaunchDaemon opens ports 80 and 443 for Traefik and connects to it on 8080 and 8443. The RKE2 catalog determines the version and images to use, and up creates the containers accordingly.

The system does not install CNI, kube-proxy, or CoreDNS. A sample workload involves a persistent volume mounted as a directory on the Mac, which a pod appends to through virtiofs. The volume retains its data upon deletion, demonstrating that the file persists even after the pod is removed. The cluster can be stopped or uninstalled, leaving the data directory and ingress alias intact for future use.