Kubernetes 1.30 was an upgrade planning reminder

Kubernetes 1.30 was a reminder that cluster upgrades are calendar work.

The release itself is not the point. The point is that Kubernetes moves on a schedule and the rest of the stack has to keep a calendar for it. If the team waits too long, the upgrade stops being a cluster task and becomes an application task, a tooling task, and a rollback task all at once.

I treat the cluster like a dependency with dates, owners, and a test window.

cluster_upgrade_plan:
  version: "1.30"
  owner: platform
  test_window: "two weeks"
  checks:
    - version skew
    - ingress behavior
    - storage class behavior
    - rollout restart
    - workload autoscaling

The useful part is not the release note. It is the checklist that tells application teams what might break first and who is on point when it does. A good upgrade plan says where the risk is, not just when the new version exists.

The upgrade is boring when it is planned. That is the whole goal. Boring means the calendar is doing its job before the cluster starts doing surprise work.

That usually means running a preview cluster, checking ingress and storage behavior, and making sure the control plane change does not sneak in an app-level outage. The release is not the work. The work is knowing which workloads care before the version is already live.

I want the plan to name the boring verification too: run one deployment, roll it back once, watch metrics, and only then widen the blast radius. If a cluster upgrade never makes application teams nervous, the calendar did its job.