Documentation is tailored to each Cluster Stack release. Pick the one your cluster runs. {#if release === stack.latest} ## You are here You are seeing the documentation for Kubernetes 1.34, Cluster Stack release hetzner-apalla-1-36-v2 — the newest release Syself Autopilot offers right now. If your cluster is already on this release, there's nothing to do. Not on this release? Pick your cluster's actual version in the picker above to jump straight to the guide that applies to it. ## Not sure which Cluster Stack release your cluster is on? If you are unsure which Cluster Stack release your cluster is currently running, do the following: Check in your cluster Run these commands against the Syself Autopilot management cluster, not the workload cluster. To check one cluster: ```console $ kubectl get cluster -n \ -o jsonpath='{.spec.topology.classRef.name}{"\n"}' ``` The command returns the Cluster Stack release name: ```console vars hetzner-apalla-1-34-v10 ``` The name includes the provider, stack, Kubernetes minor version, and Cluster Stack release. The final `vN` segment identifies the Cluster Stack release. To check every cluster: ```console $ kubectl get clusters -A \ -o custom-columns='NAMESPACE:.metadata.namespace,CLUSTER:.metadata.name,CLUSTERSTACK:.spec.topology.classRef.name,KUBERNETES:.spec.topology.version' ``` **If the management cluster serves `cluster.x-k8s.io/v1beta1`**: If the Syself Autopilot management cluster serves `cluster.x-k8s.io/v1beta1` instead of `v1beta2`, use `spec.topology.class` instead of `spec.topology.classRef.name`. To check one cluster with `cluster.x-k8s.io/v1beta1`: ```console $ kubectl get cluster -n \ -o jsonpath='{.spec.topology.class}{"\n"}' ``` To check every cluster with `cluster.x-k8s.io/v1beta1`: ```console $ kubectl get clusters -A \ -o custom-columns='NAMESPACE:.metadata.namespace,CLUSTER:.metadata.name,CLUSTERSTACK:.spec.topology.class,KUBERNETES:.spec.topology.version' ``` If it doesn't match, change your version in the version picker If either one doesn't match hetzner-apalla-1-36-v2 / 1.34, switch the docs to your cluster's actual version using the picker below: An update guide scoped to that version will show you the real update steps. ## Explore further Exactly which components and versions hetzner-apalla-1-36-v2 ships. Every maintained Kubernetes minor and Cluster Stack release, including 1.36's full history, with support windows and what changed between them. ## Moving to a new Kubernetes minor instead of a new release on your current one? See [Upgrading the cluster to a new Kubernetes version](/docs/hetzner/apalla/clusters/upgrades/upgrade-to-a-new-kubernetes-version). {:else if release === minor.latest} Right now you are on the latest ClusterStackRelease available for Kubernetes 1.34. ## Your options - **Upgrade Kubernetes**: To move from Kubernetes 1.34 toward Kubernetes 1.36, follow [Upgrading the cluster to a new Kubernetes version](/docs/hetzner/apalla/clusters/upgrades/upgrade-to-a-new-kubernetes-version). - **Update an older ClusterStackRelease**: If your cluster uses an older release, select its actual version in the picker at the top of this page. The version-specific guide will show the relevant update steps. - **Check your cluster's version**: If you are not sure which Kubernetes version and Cluster Stack your cluster uses, [check the Kubernetes version and Cluster Stack](/docs/hetzner/apalla/clusters/configure/how-to-check-the-kubernetes-version-and-stack). {:else} 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-34-v10 to hetzner-apalla-1-34-v10. The Kubernetes minor itself does not change. Not sure which release your cluster is on? [Check the Kubernetes version and Cluster Stack](/docs/hetzner/apalla/clusters/configure/how-to-check-the-kubernetes-version-and-stack) for your cluster. {#if release.hasArmImages} ## 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](/docs/hetzner/apalla/servers-and-nodes/provision/migrate-arm-to-x86) for instructions. {/if} ## Preparing the clusterstack object Check if `autoSubscribe` is set to `true` or `false` in your clusterstack object and follow the steps for your case: > [!NOTE] > The `autoSubscribe` key in the clusterstack object indicates that Syself Autopilot will automatically fetch the latest ClusterStackRelease version and make it available for use. {#if upgrade.toMinorLatest.length === 1} The latest version is automatically available for you. You don't need to do anything. Keep reading the next steps. {:else} The latest version is automatically available for you, but you still need to specify the versions in between. For that, add [] to the `spec.versions` array in your Cluster Stack: ```yaml vars persistBlur title="clusterstack.yaml" 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 versions: [] providerRef: name: hetzner-apalla-1-34 kind: HetznerClusterStackReleaseTemplate apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1 ``` {/if} {#if upgrade.toMinorLatest.length === 1} You can go to the latest version directly. To make it available, add v10 to the versions array in your Cluster Stack object: ```yaml vars persistBlur title="clusterstack.yaml" 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 ``` {:else} You need to specify the ClusterStackRelease versions in between using the `spec.versions` array in your Cluster Stack object. The following is the complete (and shortest) tested upgrade path to go from your current version to hetzner-apalla-1-34-v10: ```yaml vars persistBlur title="clusterstack.yaml" 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: [] providerRef: name: hetzner-apalla-1-34 kind: HetznerClusterStackReleaseTemplate apiVersion: infrastructure.clusterstack.x-k8s.io/v1alpha1 ``` {/if} ## Checking the available ClusterStackReleases Check if the `ClusterStackReleases` you need are available with: {#if upgrade.toMinorLatest.length === 1} ```console vars $ kubectl get clusterstackrelease NAME K8S VERSION READY AGE REASON MESSAGE hetzner-apalla-1-34-v10 v1.34.10 true 2d hetzner-apalla-1-34-v10 v1.34.10 true 1m ``` {:else} ```console vars $ kubectl get clusterstackrelease NAME K8S VERSION READY AGE REASON MESSAGE hetzner-apalla-1-34-v10 v1.34.10 true 2d ... ... true 1m hetzner-apalla-1-34-v10 v1.34.10 true 1m ``` {/if} 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-34-v10 and v1.34.10. ## 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. {#if upgrade.toMinorLatest[0]?.kubernetes === minor.latest.kubernetes} In this case, you only need to update one 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](/docs/hetzner/apalla/clusters/upgrades/migrate-a-manifest-to-v1beta2) for more information. ```yaml vars persistBlur title="cluster.yaml" apiVersion: cluster.x-k8s.io/v1beta2 kind: Cluster metadata: name: mycluster spec: topology: classRef: name: {upgrade.toMinorLatest[0]?.name} version: {upgrade.toMinorLatest[0]?.kubernetes} 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 ``` {:else} {/if} 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](/docs/hetzner/apalla/clusters/availability/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: ```console $ 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. {/if}