Upgrading the cluster from Kubernetes 1.34 to Kubernetes 1.35
Note
Starting from hetzner-apalla-1-35-v1, Hetzner node image builds are no longer required. Because of that, we require a common SSH key for both bare metal and cloud servers. If you did not use the same SSH key when you connected your Hetzner account , please change the secrets to ensure you have a single SSH key.
This guide will detail the process of upgrading your cluster from Kubernetes 1.34 to 1.35.
Scan for deprecated and removed APIs
Kubernetes removes API versions in minor releases. If your workloads or Helm charts still reference a removed API version, they will stop working after the upgrade.
The scans use two tools: pluto for manifests and Helm releases, and kubent for the running cluster. Install both before you start.
Run a static scan against your manifests and Helm releases:
$ pluto detect-files -d ./manifests
$ pluto detect-helm
Run a live scan against the running cluster for objects using soon-to-be-removed APIs:
$ kubent
Fix every finding before you proceed. Updating a manifest after the API is removed requires extra recovery steps.
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-35
spec:
provider: hetzner
name: apalla
kubernetesVersion: "1.35"
channel: stable
autoSubscribe: true
providerRef:
name: hetzner-apalla-1-35
kind: HetznerClusterStackReleaseTemplate
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
---
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
kind: HetznerClusterStackReleaseTemplate
metadata:
name: hetzner-apalla-1-35
spec:
template:
spec:
nodeImages: []
apiVersion: clusterstack.x-k8s.io/v1alpha1
kind: ClusterStack
metadata:
name: hetzner-apalla-1-35
spec:
provider: hetzner
name: apalla
kubernetesVersion: "1.35"
channel: stable
autoSubscribe: false
versions: ["v7"]
providerRef:
name: hetzner-apalla-1-35
kind: HetznerClusterStackReleaseTemplate
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
---
apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1
kind: HetznerClusterStackReleaseTemplate
metadata:
name: hetzner-apalla-1-35
spec:
template:
spec:
nodeImages: []
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-34-v13 v1.34.13 true 2d
hetzner-apalla-1-35-v7 v1.35.10 true 1m
Note down the value of the NAME column from the release you want to upgrade to.
Now we edit our cluster and change the spec.topology.class to match the NAME 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-35-v7
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.
Note
Managing your cluster with GitOps: Syself Autopilot sets spec.topology.version from the release that spec.topology.class points at. A version stored in Git therefore goes stale at every update and shows up as drift. Either configure your GitOps tool to ignore the field or change it to v1.35.10 together with the class. See Fields Syself Autopilot sets for you .
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?
Run this against the Syself Autopilot management cluster, not the workload cluster:
$ kubectl get clusters -A
The CLUSTERCLASS column shows the Cluster Stack release and VERSION shows the Kubernetes version. Select that version in the picker at the top of this page.