Upgrade the fleet

One edit to the Cluster moves every machine to a new release. Each machine downloads the release, verifies every artifact, and reboots when the cluster grants its turn. You do not rebuild the media, and you do not touch the machines.

1. Find the release

The channel at releases.liken.sh lists every release. The cluster also polls the channel:

kubectl get clusters

The AVAILABLE column shows the latest version that the channel announces. To make the cluster poll the channel now, set the liken.sh/check-releases annotation to a new value:

kubectl annotate cluster --all --overwrite liken.sh/check-releases="$(date -Is)"

The value of the annotation has no meaning. The change of the value is the request.

An upgrade needs two facts: the version, and the digest of that release’s release.yaml. The release’s page on GitHub gives both, as a catalog entry you can copy. To compute the digest yourself:

curl -fsSL https://releases.liken.sh/<version>/release.yaml | sha256sum

2. Catalog the release and set the target

kubectl edit cluster

Add the release to spec.releases.catalog, and point spec.version at it:

spec:
  version: "2026.07.20-001"
  releases:
    source: https://releases.liken.sh
    catalog:
      - version: "2026.07.20-001"
        digest: sha256:<hex>

If spec.version names no catalog entry, the API refuses the change while your edit is still open. The digest is the start of the trust chain. The digest names the release document, and the release document names the artifacts. Each machine checks every downloaded byte against one or the other.

3. The rollout

Each machine that runs a different version:

  1. Downloads the release into the boot slot it does not run from, and verifies each artifact against the digest chain.
  2. Stages the change and asks the cluster for a reboot turn.
  3. Cordons and drains its node when the cluster grants the turn. The PodDisruptionBudgets of the workloads apply during the drain. A pod that holds a DRA claim leaves before the pod that serves its driver. The driver stays to answer the kubelet’s unprepare call.
  4. Reboots into the new slot one time, as a trial. The trial is a success when the OS starts and rejoins the cluster, and the machine then boots that slot from then on. If the trial fails, the machine returns to the other slot without help: Roll back describes this.

The cluster grants turns within spec.disruption.maxUnavailable (the default is one machine at a time). Only one leader is down at a time, whatever the budget says, because the datastore needs a majority of the leaders.

If a machine’s rebootPolicy is Manual (the default), the machine stages the change, reports RebootPending, and waits for you. Grant the reboot with liken approve-reboot:

liken approve-reboot mycluster <machine>

The machine then takes its turn under the same disruption budget as an Auto machine: it drains first, and only one leader is ever down at a time. Set rebootPolicy: Auto on machines that must take their turn without an operator.

4. Watch the rollout

kubectl get machines

The LIKEN column changes to the new version one machine at a time, and the phase of each machine shows its step in the rollout. The phase of the Cluster shows Updating during the rollout, and Ready when the rollout is complete.

If a machine with a granted turn does not return, the cluster sets its Progressing condition to False with the reason RolloutStalled, and grants no more turns until you examine the machine.