Most failed upgrades were predictable: removed APIs, blocking budgets, incompatible add-ons.

✓Deprecated APIs. Use EKS upgrade insights, pluto or kubent, and the API server deprecation metric.

✓Add-on compatibility. Check the target versions exist for the new Kubernetes version.

✓PodDisruptionBudgets. Ensure at least one Pod can be evicted per workload.

✓Free IPs. The control plane needs a few free addresses in the cluster subnets.

✓Webhooks and CRDs. Controllers, meshes and policy engines support the new version.

✓Backup and rollback plan. Know what you will do if verification fails.

find what will break

$ aws eks list-insights --cluster-name shop-eu \
    --filter kubernetesVersions=1.32
$ kubectl get --raw /metrics | \
    grep apiserver_requested_deprecated_apis
$ pluto detect-helm -o wide --target-versions k8s=v1.32.0
$ kubectl get pdb -A
$ aws ec2 describe-subnets --subnet-ids $SUBNETS \
    --query 'Subnets[].AvailableIpAddressCount'

Automate these checks in CI so every upgrade ticket starts from a green or a known-red report.

Pre-upgrade checks that catch most failures

A large majority of upgrade incidents can be found before you start. Removed API versions are the top cause: a manifest or Helm chart that references an API the new control plane no longer serves fails outright. EKS provides upgrade insights that flag deprecated API usage and some other readiness issues, and tools such as pluto and kubent scan manifests and Helm releases. The API server metric apiserver_requested_deprecated_apis shows what live clients are still calling.

Add-on compatibility is next: confirm that the versions you will update to are available for the target Kubernetes version. Then PodDisruptionBudgets: any workload whose budget allows zero disruptions will block draining. Check that the cluster subnets still have enough free IP addresses, since the control plane upgrade creates temporary network interfaces. Finally check the controllers that sit in the admission path, like service meshes and policy engines, support the new version, because an incompatible webhook can break every Pod creation.

Reveal the six checks one at a time. Put the checks in CI as a job that outputs a report before each upgrade ticket is opened, so engineers start from facts, not memory.

The commands are representative; flags and output formats change between tool versions. Verify against the current tool documentation.