Updating the cluster from hetzner-apalla-1-36-v4 to hetzner-apalla-1-36-v6

A Cluster Stack release bundles the Kubernetes patch version, the in-cluster components, and the node image under one version number, tested together before any node boots. Updating within a Kubernetes minor moves your cluster from one release to the next on that same minor, here from hetzner-apalla-1-36-v4 to hetzner-apalla-1-36-v6. The Kubernetes minor itself does not change.

Before you update

• See what your current release ships and where it stands on security. The Cluster Stack Release for hetzner-apalla-1-36-v4 lists every component in it, with its CVEs and how each one is assessed, so you can tell what the newer release changes before you move.
• Run the pre-flight checks .

Editing the cluster object

In this case, you only need to update one version. Change your cluster's spec.topology.classRef.name to hetzner-apalla-1-36-v6 and spec.topology.version to v1.36.4, as shown below. Both belong to the same release — set them together and you're done.

		apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: mycluster
spec:
  topology:
    classRef:
      name: hetzner-apalla-1-36-v6
    version: v1.36.4
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: workeramd64hcloud
          name: md-0
          replicas: 1
          failureDomain: nbg1
          variables:
            overrides:
              - name: workerMachineTypeHcloud
                value: cpx42
    variables:
      - name: region
        value: nbg1
      - name: controlPlaneMachineTypeHcloud
        value: cpx42
	

This can be achieved either by editing the resource inside the management cluster, or by updating it in your GitOps repository.

Once you apply it, the cluster rolls to the ClusterStack release you specified: new nodes come up and the old ones are removed, one at a time. This is the same node replacement that happens during routine self-healing, so a workload set up to tolerate it — replicas spread across nodes with a PodDisruptionBudget — rides through the roll without downtime. If your workloads are not set up that way yet, see Prepare workloads for upgrades ; it applies to any node replacement, not just updates.

If you need to update to another version, wait for the current update to finish. You can check if it's done by checking the nodes in your cluster:

		$ kubectl get nodes
	

If you still have old nodes, this means the update is in progress. In this case, wait until the output shows only new nodes.

Moving to a new Kubernetes minor instead of a new release on your current one?

See Upgrading the cluster to a new Kubernetes version .

Not sure which release your cluster is on?

Check the Kubernetes version and Cluster Stack for your cluster.