Is k3sm a Certified Kubernetes Distribution?#

No. k3sm cannot pass the CNCF [Conformance] suite, which assumes Linux containers, cgroups, CNI, and network namespaces. k3sm has none of them. See Limitations.

Does k3sm Use a Container Engine or a VM?#

No. By default Pods run as native Darwin processes, so there is no Linux, no containers and no VM. An optional vm RuntimeClass runs linux/arm64 Pods in a per-Pod micro-VM to isolate untrusted workloads. See Limitations.

Can I Run My Existing OCI Linux Images?#

No, on the default path. Those images carry a Linux userland, and a k3sm Pod there is a Darwin process. An unmodified linux/arm64 image (or a multi-arch image that includes it) runs instead under the vm RuntimeClass, single-node. Outside that path a Linux image is refused at pull, naming the platforms it offers and the one this node needs; linux/amd64 is refused on both paths today.

You can still use images, and the usual toolchain around them: build a darwin/arm64 binary, package it with k3sm build, then k3sm image load it or k3sm image push it to a registry the node pulls from. Tags, digests, imagePullPolicy and imagePullSecrets all behave normally. The short version is What runs; the reference is Images; see also Limitations.

Why Did My Container Exit and Not Restart?#

On the default runtime it should have. restartPolicy is honored, with an upstream-shaped CrashLoopBackOff. Two cases break that. A plain (non-sidecar) init container is not re-run in place, and a node started with --runtime hostprocess, the rootless-dev opt-out, reaps an exited container without respawning it. See Limitations.

Does Cluster DNS Work Inside a Pod?#

On the default runtime, yes. Cluster Service names, headless Services, StatefulSet per-Pod names, SRV and PTR all resolve from inside a Pod. Two caveats apply. The resolver is k3sm’s own, not CoreDNS (IPv4/A only, no AAAA), and the getaddrinfo shim that redirects a Pod’s lookups cannot load into a restricted binary. Host shells (/bin/sh, bash, zsh, dash, env), tar and the common file utilities run as re-signed copies that keep the shim; any other restricted main process (the system python3, for example) gets a ShimInactive Event and still resolves fully qualified and <svc>.<ns>.svc names through the node resolver. In-pod cluster DNS is not wired on --runtime hostprocess; on the vm RuntimeClass it works. See Limitations.

Do UDP Services Work?#

Only cluster DNS on :53. General UDP Services (ClusterIP and NodePort) are deferred. See Limitations.

Are Pods Isolated From Each Other?#

Not by uid. Same-node Pods share one _k3sm trust domain. Untrusted workloads belong on the vm RuntimeClass; see Limitations for what it supports today.

Is Multi-Node / HA Production-Ready?#

No. Multi-node ships EXPERIMENTAL; see Multi-node. A multi-server (HA) control plane is not available in v0.1.6: a cluster runs one server, and a second server cannot join yet. See HA.

Which Kubernetes Version Does k3sm Track?#

See Versions, and read the live pin from k3sm version.

How Do I Upgrade?#

Re-run the install script, curl -fsSL https://k3sm.io/install.sh | sh, which installs the latest release and restarts the daemons. Homebrew (brew upgrade) is the second install generation and is planned; the k3sm-io/tap is not published yet. A multi-node cluster rolls node-by-node. See Upgrade.

Do I Need `sudo` Every Time?#

No, only the one-time sudo k3sm install. See Install.