Changelog for Kubernetes 1.36

Versions

The deployed Kubernetes patch version varies based on when your cluster is deployed or upgraded. We strive to use the latest versions available.

Current release leverages Kubernetes 1.36. Official release blogpost found here with corresponding official changelog.

Optional addons

• cert-manager is provided with version v1.21.2
• Envoy Gateway is provided with version v1.9.0

Major changes

• New clusters are created on Kubernetes 1.36 unless you ask for another version.
• Clusters are upgraded one minor version at a time, so a 1.34 cluster is upgraded to 1.35 first. All changes in the Kubernetes 1.35 changelog apply, including the revocable kubeconfig: please download the new kubeconfig after the upgrade to 1.35.

Noteworthy changes in upcoming versions

Announcement of changes in future versions.

Scheduled for upcoming releases:

• We’ll remove the legacy nodelocaldns where still deployed. Relevant only if the cluster was created before v1.26.

Is downtime expected

The cluster control plane should remain available during the upgrade; however, pods will be restarted when workloads are migrated to new nodes. Plan for short pod restarts during the upgrade.

Known issues

Custom node taints and labels lost during upgrade.

Custom taints and labels on worker and control-plane nodes may be lost during the upgrade. We recommend auditing and reapplying any critical custom taints/labels via automation (e.g., cluster bootstrap, configuration management, or a post-upgrade job).

There is a label that is persistent across upgrades that can be used to direct workload to particular nodegroups. Example on how to use it:

spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodegroup.node.cluster.x-k8s.io
                operator: In
                values:
                - worker1

Snapshots are not working.

There is currently a limitation in the snapshot controller: it is not topology-aware. As a result, snapshot behavior may be unreliable for topology-sensitive volumes. Avoid depending on snapshots for cross-zone/region recovery until a topology-aware snapshot controller is available or confirm your storage driver’s snapshot semantics.