Changelog for Kubernetes 1.35
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.35. Official release blogpost found here with corresponding official changelog.
Optional addons
Major changes
- Easier to revoke access: the kubeconfig is now token based, and we can revoke it and issue a new one on request. Please download the new kubeconfig from your cluster’s object storage container after the upgrade.
- Our support for ingress-nginx ends on 31 December 2026, see below.
- We have improved how we roll out our bundled addons. New addon versions can now be released on a regular basis without upgrading the Kubernetes version, so your cluster gets fixes and improvements sooner. This applies to clusters on Kubernetes 1.35 and later. Older clusters keep their current addon versions until they are upgraded.
- CoreDNS is now kept up to date together with the other addons. Before, it stayed on the version the cluster was created with.
- DNS lookups from pods for names outside the cluster now go to Elastx’s own DNS resolvers in our data centers instead of public resolvers, which keeps them within Elastx.
Introducing nodegroups on a shared network
A nodegroup can be attached to a network in another of your OpenStack projects. Contact support with the project, the network and the nodegroup, and we share the network with the cluster’s project and attach it. To remove it, contact support the same way. Your virtual machines in that project and your cluster can then talk privately, without a floating IP per machine. Available from Kubernetes 1.35. See Nodegroups on a shared network for how to prepare the network and reach your Services from your virtual machines.
- Each nodegroup can use one shared network, and reaches only its own subnet on it.
- The shared subnet must not overlap the cluster’s node, pod or service ranges, and needs room for the nodegroup’s maximum size plus one address per availability zone.
- Give the shared network the same MTU as the cluster network. With a smaller MTU, pods on those nodes get a smaller MTU too, and large UDP packets to them are dropped.
Introducing optional cluster settings
- Service range: a new cluster can be created with a Service range of your choice, between /12 and /24, for example to avoid overlapping a network you want to share with the cluster. It cannot be changed once the cluster exists.
- Encryption of Secrets at rest: Secrets stored in etcd can be encrypted, on request. Turning it on for a running cluster replaces the control plane nodes twice, without downtime for your workloads. Once turned on, it cannot be turned off. Existing Secrets are encrypted the next time they are written.
End of support for ingress-nginx
The ingress-nginx project has been retired upstream, and our support for it ends on 31 December 2026.
- We will not remove ingress-nginx from any cluster, and it keeps running as it does today.
- No newer version of ingress-nginx is planned.
- We recommend Gateway API with our Envoy Gateway addon, which we support and keep up to date. Moving your ingresses to Gateway API is done by you, as announced in the Kubernetes 1.34 changelog.
Noteworthy changes in upcoming versions
Announcement of changes in future versions.
Scheduled for upcoming releases:
- We’ll remove the legacy
nodelocaldnswhere 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.