Overview

One binary, one payload

The release artifact is a single executable with a ZIP payload appended to it:

stratum  =  ELF (supervisor + operator)
            └── payload
                ├── bin/      component binaries (kubelet, containerd, …)
                └── images/   OCI archive: control-plane + add-on images

stratum stage unpacks the payload to /var/lib/stratum. Nothing is fetched. The images are imported into containerd on first start, which is why a cluster reaches Ready with no registry reachable.

Static pods for the control plane, a supervisor for the rest

The control plane — etcd, kube-apiserver, kube-controller-manager, kube-scheduler, and kube-vip when a VIP is configured — runs as kubelet-managed static pods, rendered by stratum into /var/lib/stratum/config/manifests/. It is visible as mirror pods in kubectl get pods -n kube-system and supervised by the same kubelet machinery as every workload.

What has to be a host process — containerd, kubelet, and the operator — runs as a child process of the running stratum command, restarted with backoff and driven through a root-only control socket at /run/stratum/stratum.sock speaking restart/stop/start/status.

Systemd has one job: starting stratum up again after a reboot. stratum up installs and enables a single unit, /etc/systemd/system/stratum.service. From there the chain restarts itself: systemd starts the supervisor, the supervisor starts kubelet, and kubelet starts the static pods. There is no unit per component, because the supervisor already restarts them.

That split has consequences worth knowing:

• Manifests are rendered on every start. stratum is the sole writer of the manifest directory: the flags a component runs with are generated from config each time, hand-edits are overwritten, and nothing drifts between what is configured and what is running.
• stratum hardening check audits those rendered manifests — it reads what kubelet actually runs, not a template of what it should have been.
• Cert rotation, snapshot restore and node upgrades bounce control-plane components by re-rendering their manifests (kubelet recreates the pod on content change), and host processes through the socket — one component at a time, without restarting the node's control plane.

One node model

stratum up runs the hyperconverged default: the node runs the control plane as kubelet-managed static pods and schedules workloads. Every node runs kubelet and containerd; the control plane is visible as mirror pods in kubectl get pods -n kube-system.

stratum up --worker runs a workload-only node that joins an existing cluster and carries no control plane.

Operators who want a dedicated (non-schedulable) control-plane node taint it themselves:

kubectl taint nodes <node> node-role.kubernetes.io/control-plane:NoSchedule

Configuration and state

Two files, with different jobs:

Component flags are generated from these two.

Cluster formation

# the first control-plane node
stratum up [--config /etc/stratum/config.yaml]

# mint a join token on that controller
stratum token create

# a workload-only node
stratum up --worker --server https://<vip-or-controller>:6443 \
  --token <token> --discovery-token-ca-cert-hash sha256:<pin>

# an additional control-plane node, for HA
stratum token create --control-plane   # writes the certificate key to a 0600 file, prints its path
stratum up --join https://<vip>:6443 \
  --token <token> --discovery-token-ca-cert-hash sha256:<pin> \
  --certificate-key-file <path>   # copy the key file from the first controller

Workers TLS-bootstrap their certificates; the operator approves a join only for a node name not already registered, and serving certificates only for addresses the node owns. Joining controllers download the shared CA material over an encrypted channel and join etcd live.

Both join paths authenticate the cluster before trusting it: the CA a joining node receives is verified against a signature over the discovery document and against the hash printed in the join command. A join that cannot verify both fails rather than proceeding.

What is deliberately not here

• An SSH fleet-provisioning CLI. stratum upgrade --cluster performs rolling upgrades over the Kubernetes API with the skew rules encoded; provisioning machines from zero over SSH is left to the tools that already do it.
• A second CNI, kube-proxy, or a SQL datastore. One dataplane, one datastore.
• A fleet manager. The dashboard shows one cluster — the one serving it — and the binary deploys it with the cluster, from an image in the payload. Managing many clusters from one pane is not part of the engine; it is what Stratum PRO adds, on top of this same engine rather than instead of it.