Upgrading the cluster from Kubernetes 1.33 to Kubernetes 1.34
Documentation is tailored to each Cluster Stack release. Pick the one your cluster runs.
This guide will detail the process of upgrading your cluster from Kubernetes 1.33 to 1.34.
Not sure which Kubernetes minor and Cluster Stack release your cluster uses? Check the Kubernetes version and Cluster Stack of your cluster.
Upgrading the cluster#
Adding a new Cluster Stack #
Add a new ClusterStack and HetznerClusterStackReleaseTemplate for the newer Kubernetes minor version:
Note
The cluster manifest below uses cluster.x-k8s.io/v1beta2, the current default API version for CAPI core resources. See Cluster API v1beta2 for more information.
apiVersion: clusterstack.x-k8s.io/v1alpha1
kind: ClusterStack
metadata:
name: hetzner-apalla-1-34
spec:
provider: hetzner
name: apalla
kubernetesVersion: "1.34"
channel: stable
autoSubscribe: true
providerRef:
name: hetzner-apalla-1-34
kind: HetznerClusterStackReleaseTemplate
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
---
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
kind: HetznerClusterStackReleaseTemplate
metadata:
name: hetzner-apalla-1-34
spec:
template:
spec:
nodeImages:
- controlplaneamd64hcloud
- workeramd64hcloud
apiVersion: clusterstack.x-k8s.io/v1alpha1
kind: ClusterStack
metadata:
name: hetzner-apalla-1-34
spec:
provider: hetzner
name: apalla
kubernetesVersion: "1.34"
channel: stable
autoSubscribe: false
versions: ["v10"]
providerRef:
name: hetzner-apalla-1-34
kind: HetznerClusterStackReleaseTemplate
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
---
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
kind: HetznerClusterStackReleaseTemplate
metadata:
name: hetzner-apalla-1-34
spec:
template:
spec:
nodeImages:
- controlplaneamd64hcloud
- workeramd64hcloud
Apply it to the cluster with your tool of choice.
Tip
For versions before hetzner-apalla-1-35-v1, node images for the new version will start to build. The build process takes around 5 minutes. You can check the status of the newly created Cluster Stack object if something seems wrong.
Checking the available ClusterStackReleases #
The next step is to is to check the available ClusterStackReleases:
$ kubectl get clusterstackrelease
NAME K8S VERSION READY AGE REASON MESSAGE
hetzner-apalla-1-33-v13 v1.33.13 true 2d
hetzner-apalla-1-34-v10 v1.34.10 true 1m
Note down the values of the NAME and K8S VERSION columns from the release you want to upgrade to.
Now we edit our cluster and change the spec.topology.class and spec.topology.version to match the NAME and K8S VERSION of our cluster stack release:
apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
name: mycluster
spec:
topology:
classRef:
name: hetzner-apalla-1-34-v10
version: v1.34.10
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.
Syself now rolls the cluster to the new Kubernetes minor version, one node at a time. The control plane and the API server stay available throughout. Bare-metal control-plane and worker pools run one fewer node during each step, so size them with headroom; the prechecks cover this.
When the roll finishes, confirm every node reports the new version and Ready, the control plane and etcd are healthy, and your workloads still serve traffic. If a rollout stalls, see Stuck or failed upgrade.
If you are no longer using the old ClusterStack and HetznerClusterStackReleaseTemplate anymore, you can remove them now.