Upgrading the cluster from Kubernetes 1.27 to Kubernetes 1.28
Check for ARM-based nodes
If your cluster isn't running ARM-based nodes, skip this step. ARM-based (CAX) nodes are temporarily not supported. If your cluster has any, the upgrade will fail unless you migrate them to x86 nodes first — see Migrate ARM servers to x86 in your cluster for instructions.
This guide will detail the process of upgrading your cluster from Kubernetes 1.27 to 1.28.
Upgrading the cluster
Adding a new Cluster Stack
Add a new ClusterStack and HetznerClusterStackReleaseTemplate for the newer Kubernetes minor version:
apiVersion: clusterstack.x-k8s.io/v1alpha1
kind: ClusterStack
metadata:
name: hetzner-apalla-1-28
spec:
provider: hetzner
name: apalla
kubernetesVersion: "1.28"
channel: stable
autoSubscribe: true
providerRef:
name: hetzner-apalla-1-28
kind: HetznerClusterStackReleaseTemplate
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
---
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
kind: HetznerClusterStackReleaseTemplate
metadata:
name: hetzner-apalla-1-28
spec:
template:
spec:
nodeImages:
- controlplaneamd64hcloud
- workeramd64hcloud
apiVersion: clusterstack.x-k8s.io/v1alpha1
kind: ClusterStack
metadata:
name: hetzner-apalla-1-28
spec:
provider: hetzner
name: apalla
kubernetesVersion: "1.28"
channel: stable
autoSubscribe: false
versions: ["v11"]
providerRef:
name: hetzner-apalla-1-28
kind: HetznerClusterStackReleaseTemplate
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
---
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
kind: HetznerClusterStackReleaseTemplate
metadata:
name: hetzner-apalla-1-28
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-27-v19 v1.27.16 true 2d
hetzner-apalla-1-28-v11 v1.28.15 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:
Note
The manifest below uses cluster.x-k8s.io/v1beta2, the current API version for cluster manifests. v1beta1 keeps working for now, but Syself recommends migrating: see Migrate a manifest to v1beta2 .
apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
name: mycluster
spec:
topology:
classRef:
name: hetzner-apalla-1-28-v11
version: v1.28.15
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.
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, leave the spec in place and contact support.
If you are no longer using the old ClusterStack and HetznerClusterStackReleaseTemplate anymore, you can remove them now.
Not sure which Kubernetes minor and Cluster Stack release your cluster uses?
Check the Kubernetes version and Cluster Stack of your cluster.