Kubernetes 1.25 released in August 2022 with a significant breaking change: the removal of several API versions that had been deprecated since Kubernetes 1.16. The event was a useful reminder of how breaking changes work in a mature platform.
What was removed
Kubernetes 1.25 removed PodSecurityPolicy (PSP), the API versions beta/v1 for batch and networking resources, and other long-deprecated resources. PSP in particular was widely used. The replacement, Pod Security Admission (PSA), was available since 1.22. Migration from PSP to PSA was documented but required planning.
The three-year deprecation window
Kubernetes maintains deprecated APIs for a minimum of three releases (approximately one year) before removal. PSP was deprecated in 1.21 (April 2021) and removed in 1.25 (August 2022), a 16-month window. The standard complaint was that the window was too short given the difficulty of coordinating upgrades across clusters and deployed workloads. The Kubernetes team's response is that indefinitely supporting deprecated APIs accumulates technical debt that makes the platform harder to maintain.
The upgrade planning implication
The Kubernetes removal policy means that every organisation running Kubernetes needs a policy for tracking deprecated API usage and planning migrations. kube-no-trouble (kubent) scans your cluster for use of deprecated APIs. Helm chart maintainers publish compatibility tables. The practical advice: run kubent against your cluster before every major Kubernetes version upgrade.
PSP migration to PSA
Pod Security Admission enforces pod security standards through namespace labels rather than PSP controller admission. The migration from PSP to PSA requires: auditing your existing policies, mapping them to the Privileged, Baseline, or Restricted PSA levels, applying namespace labels, and handling the edge cases where your workloads require capabilities that PSA standards would deny. For most standard workloads, the migration is mechanical.