Kubernetes

Kubernetes

The Kubernetes section is Apple's container k8s: local Kubernetes development clusters, each a VM on one Mac, on This Mac and on paired hosts. It was called Clusters until beta 4; the name follows the command, because "Clusters" alone did not say what kind and "K8s" is shorthand some people will not know.

A band at the top says Experimental, in the section's own words. container k8s --help calls the family experimental, and its output has no machine-readable form: Flotilla reads the printed table, so a change in a later container will show up here first. A section built on a command that may change under it should say so where you are, not only in a commit.

Three things to know first

Kubernetes needs Rosetta on the Mac that runs the cluster. container 1.5's k8s create always turns Rosetta on for the cluster's VM, and has no flag to turn it off. Rosetta is not on an Apple silicon Mac until something installs it, so on a Mac without it, creating fails. Flotilla catches that and says it plainly, naming the Mac, rather than passing on the virtualisation framework's raw error. Install it on that Mac — an administrator is asked — and create the cluster again:

softwareupdate --install-rosetta --agree-to-license

On a host, that means at the host's keyboard, or by your usual way of running a command there; Flotilla cannot install Rosetta for you.

container 1.5 cannot restart a cluster — only recreate it. Version 1.5.0 removed k8s start, because restarting a stopped cluster was unreliable, especially after its node came back on a new address, and there has never been a command that stops a cluster without destroying it. So there is no Start and no Stop here. See Recreate.

kubectl on your admin Mac cannot reach a host's cluster. A cluster's API server listens on its own Mac's VM network. kubectl on that Mac reaches it; from the admin it is not reachable yet, so Flotilla does not offer a kubeconfig for it — that would be a promise the admin cannot keep. Use kubectl on the host.

The list

One row per cluster: Name, Host once a host is paired, Role, CPUs, Memory, Address and Ports, and the actions. Two Macs' dev clusters are two rows. A host's clusters arrive on its regular 30-second check and show beside This Mac's; a host's row older than a fresh answer is shown with its age rather than dropped. The host filter narrows the list to one Mac.

It is a flat list, and that is the CLI's shape rather than a simplification: each cluster is also its single node, so there is no cluster-to-node hierarchy to draw.

New Cluster

+ ▸ New Cluster…, File ▸ New Cluster… (⌃⌘K), or a suggestion from + ▸ Suggestions…:

• Create on — This Mac or a host, once you have one. A cluster is a VM on one Mac.
• Name — it becomes the kubectl context name, so kubectl --context <name> is how you reach it. The CLI defaults this to k8s-dev when it is omitted; Flotilla always sends a name, because a default-named cluster is one you create twice by accident.
• Set CPUs and memory — whole cores, and memory with a K, M or G suffix such as 4G. Off, the CLI's defaults apply.
• Node image — optional. Left empty, the CLI uses its own digest-pinned default, which is how you get a reproducible version rather than whatever is newest. If you set one it needs a tag: since container 1.5 the tag also picks the Kubernetes version, and an untagged or digest-only image is refused.
• Remove the cluster when it stops — --rm. Useful for a throwaway cluster; wrong for one you mean to keep.

On This Mac, creating streams container's own progress lines into its task in Tasks, and takes several minutes. It returns you to the list at once. The task has no Stop, deliberately: a create stopped half way leaves a VM and a kubeconfig entry behind, and k8s delete wants a cluster that finished being made. A Cancel that produced that would be worse than none.

On a host, creating shows no progress until it finishes. A create there is one request, because a peer may only follow a command that declares a stream. It can take several minutes; wait for the result before deciding it failed. k8s create writes the host's own ~/.kube/config.

Recreate

A cluster that is not running has Recreate… as its first button, where Start used to be. It deletes the cluster and creates it again, which is Apple's documented recovery. Starting the node container directly is not a substitute: it skips Kubernetes' own repair, readiness and kubeconfig steps.

It always asks first, whatever Confirm destructive actions says, and the confirmation says what survives before anything happens:

• Kept: the name, the CPU count and the memory — what k8s list reports.
• Lost: everything inside — deployments, pods, loaded images and stored data. A custom node image or network plugin is not recorded anywhere Flotilla can read, so the new cluster uses the defaults.

The reason comes first in that message, so that someone who has only ever pressed Start knows why it is gone, rather than reading Recreate as Flotilla being heavy-handed. Recreate works on hosts too.

Delete removes a cluster and everything running in it, and asks first.

Load Image and Write Kubeconfig — This Mac only

• Load Image… copies an image from This Mac's store into a running cluster, so a pod can run something you built without pushing it to a registry. It copies; it does not pull — build or pull the image first.
• Write Kubeconfig… writes the cluster's context to a kubeconfig of Flotilla's own, in its Application Support folder, and shows how to use it:

KUBECONFIG="<that file>" kubectl --context dev get nodes

That file has no current context, so kubectl needs --context. It is an extra copy holding one cluster and nothing else, not a way to keep container out of ~/.kube/config: k8s create writes there itself when the cluster is made, with no flag to stop it.

Both stay local by design. One reads this Mac's image store; the other writes a file this Mac's tools read. Neither means anything for a cluster on another Mac.

Not yet: reaching a host's cluster from the admin needs the tunnels planned for 2.0.