Skip to content
Signpost
Rolling outInfrastructure

Kubernetes 1.31 upgrade

Cluster-wide upgrade to Kubernetes 1.31. Workloads still using removed beta APIs will stop working when their cluster is upgraded.

Lifecycle

Next: generally available on 16 November 2026, in 6 weeks.

  1. Proposed9 months ago
  2. In development7 months ago
  3. Rolling out (current stage)5 weeks ago
  4. Generally availableplanned, in 6 weeks

Detail

Why we are doing this

Our clusters are two minor versions behind upstream support. Staying there means we stop receiving security patches and cannot adopt the scheduling improvements that several teams have asked for.

Who this affects

Every team deploying to a shared cluster. The practical impact is narrow: the only breaking removal that touches our workloads is the beta Ingress API. Teams already on the golden path templates are on the supported API and need to do nothing.

What we need from you

Check your manifests against the migration guide before 1 October. If your service cannot be migrated in time, tell us in #devops and we will schedule your cluster in the final wave.

Updates

Breakingtakes effect

Production clusters upgrade from 1 October — Ingress v1beta1 is removed

Production upgrades run in three waves starting 1 October. Any workload still declaring networking.k8s.io/v1beta1 Ingress objects will fail to deploy once its cluster is upgraded.

Run kubectl deprecations --context <your-cluster> to see whether you are affected. The migration guide has the before-and-after manifests.

What you need to do

  • Run kubectl deprecations --context <your-cluster> against every cluster your team owns.
  • Move any v1beta1 Ingress objects to networking.k8s.io/v1, using the before-and-after manifests.
  • Tell us in #devops if you cannot make 1 October, before the waves start.
Info

All staging clusters are running 1.31

Staging has been stable for two weeks. This is the window to catch problems before the production waves begin.

Info

Upgrade plan agreed, work has started