Clusters

A cluster is a Cluster object in your Environment. Everything else — the control plane, the worker VMs, the machine templates — is created for you from it, and is not yours to write directly.

That is the whole operating model, and it has one practical consequence worth internalising: you drive a cluster by editing its Cluster object. Patching the MachineDeployment that was generated from it appears to work and is then reverted.

What you get

A control plane	api-server, controller-manager, scheduler and konnectivity-server, running as pods on the platform rather than on machines you own. There are no control-plane nodes to log into or to size.
Worker nodes	Virtual machines on the platform's hardware, built from a golden image, with their disks on real storage — so a worker survives the loss of the host it was running on.
cluster-admin	Full administrative rights inside the cluster. Your own RBAC, your own operators, your own CRDs.

The control plane is cheap to create and cheap to run, which is the point. Standing a cluster up is scheduling pods, not provisioning three machines — so a cluster per environment, or per team, is a reasonable thing to do rather than an extravagance.

The lifecycle

Create Clusters — the Cluster object, the topology variables you choose, and getting the kubeconfig out.

Scale Clusters — worker replicas through the topology, and what the control plane does and does not expose.

Upgrade Clusters — bump the version on the topology and watch the rollout.

Maintenance — reading health, draining a node, and parking a cluster at zero workers instead of deleting it.

Delete Clusters — one delete, what cascades from it, and what does not.

Before you create your first one

Three things have to exist in your Environment, and none of them are things you fix from inside a cluster:

A subnet	Your clusters' machines get addresses from it. Without a Ready one, workers have nowhere to attach.
A control-plane address	The endpoint your kubeconfig and your workers connect to.
Quota	For the cluster itself, and for the storage your workloads claim — and, on some platforms, for the disks your worker nodes boot from.

Your platform team may have set all three up at onboarding, or may expect you to claim them — see Create Clusters.

What bounds you

Your tenant is capped, and the caps refuse the request rather than accepting it and failing later:

• How many clusters you may run, across every Environment you own.
• How much storage, aggregated the same way. Whether your worker nodes' own boot disks count against it depends on how your platform named its storage classes, so read status.used rather than assuming either way.
• How many external addresses you may hold.

A cluster creation refused for quota is telling you the truth immediately, which is deliberate. Ask for more, or free something.