Updating the cluster from hetzner-apalla-1-30-v4 to hetzner-apalla-1-30-v9

Documentation is tailored to each Cluster Stack release. Pick the one your cluster runs.

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-30-v4 to hetzner-apalla-1-30-v9. The Kubernetes minor itself does not change.

Not sure which release your cluster is on? Check the Kubernetes version and Cluster Stack for your cluster.

Check for ARM-based nodes#

If your cluster isn't running ARM-based nodes, skip this step. ARM is temporarily not supported on this release. If your cluster has any, the update will fail unless you migrate them to x86 nodes first — see Migrate ARM servers to x86 in your cluster for instructions.

Preparing the clusterstack object#

Check if autoSubscribe is set to true or false in your clusterstack object and follow the steps for your case:

		apiVersion: clusterstack.x-k8s.io/v1alpha1
kind: ClusterStack
metadata:
  name: hetzner-apalla-1-30
spec:
  provider: hetzner
  name: apalla
  kubernetesVersion: "1.30"
  channel: stable
  autoSubscribe: false
  versions: ["v9"] 
  providerRef:
    name: hetzner-apalla-1-30
    kind: HetznerClusterStackReleaseTemplate
    apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
	

Checking the available ClusterStackReleases#

Check if the ClusterStackReleases you need are available with:

		$ kubectl get clusterstackrelease
NAME                      K8S VERSION   READY   AGE   REASON   MESSAGE
hetzner-apalla-1-30-v4    v1.30.6       true    2d
hetzner-apalla-1-30-v9    v1.30.12      true    1m
	

Note down the values of the NAME and K8S VERSION columns from the release you want to upgrade to. In this case, hetzner-apalla-1-30-v9 and v1.30.12.

Upgrading the cluster object#

Edit your cluster and change the spec.topology.class and spec.topology.version to match the NAME and K8S VERSION of the ClusterStackRelease, respectively.

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

In this case, you only need to update one version.

		apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: mycluster
spec:
  topology:
    classRef:
      name: hetzner-apalla-1-30-v9
    version: v1.30.12
    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
	

Once you apply it, the cluster rolls to the cluster stack version 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 process 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.