Cluster Stacks
A cluster stack is everything below your workloads, captured as one version. Point a cluster at a release name like hetzner-apalla-1-36-v2 and you have fixed the node operating system, the cluster's shape, and every component that runs inside it, all together. Syself builds and tests that exact combination before any node boots. Architecture covers why Syself builds every layer.
Why it is one version#
The parts of a Kubernetes cluster mostly work on their own. What breaks is the combination: a CNI that will not load on a particular kernel, a storage driver that fails against a certain control-plane version. Each part passed its own tests, and together they still fall over. So Syself tests the whole set as one and releases it under a single number, and a cluster only ever runs parts proven to work together.
What one version pins#
A release pins three layers, and they always move together:
- The node operating system: Syself Linux , immutable, with the kernel, container runtime, kubelet, and etcd fixed to exact versions.
- The cluster's shape: the topology and its defaults. You still choose replica counts, machine types, and region per cluster.
- The cluster components: the CNI, cloud integration, DNS, storage, and admission guards, pinned and installed for you.
You track one release name instead of a version for each part, and the Kubernetes version comes with it. The name, hetzner-apalla-1-36-v2, pins the Kubernetes minor version and the specific release within it.
What a new release changes#
What a release touches decides what happens when you move to it:
- Change only the components, and moving to the release updates them in the running cluster and leaves your nodes alone.
- Change the node image (a new kernel, runtime, kubelet, or Kubernetes version), and every node is replaced from the new image. A node is never patched in place.
Updates and upgrades covers what rolls, in what order, and when.
You can only run what was tested#
A release earns its name only after it passes Syself's tests, and a cluster can point only at a name that exists, so a cluster can never run a combination Syself has not tested. What you run is the exact artifact that was tested, and its content hash lets you confirm a node runs it byte for byte. How Syself tests a cluster stack release shows what that testing involves.
A cluster keeps running the release it names until you move it on purpose, one node at a time, so a fix in a newer release reaches you only once you advance the pin. Update within a version is the step-by-step.
Next: Declarative cluster management , the one Cluster object that points at a release and the controllers that keep your cluster matching it.
Inside a Workload Cluster
What a running workload cluster is made of: what sits on a control-plane node, what sits on a worker, how KubeGate fronts the API server, and how the pieces connect over the public internet.
Declarative Cluster Management
Your whole cluster is one Kubernetes object, and Syself's controllers keep the running cluster matching it continuously, not just at apply time.