Kubernetes 1.25 came out in August 2022 with a substantial change: it removed several API versions that had been deprecated since Kubernetes 1.16. This event served as a reminder of how breaking changes work in a mature platform.
The removal included PodSecurityPolicy (PSP), the beta/v1 API versions for batch and networking resources, and other long-deprecated resources. PSP was particularly widely used, and its replacement, Pod Security Admission (PSA), had been available since version 1.22. The migration from PSP to PSA required planning, and documentation was available.
Kubernetes keeps deprecated APIs for at least three releases, about one year, before removing them. PSP was deprecated in version 1.21, released in April 2021, and removed in 1.25, released in August 2022 - a 16-month window. Some complained this window was too short, given the difficulty of coordinating upgrades across clusters and deployed workloads.
The Kubernetes team's stance is that keeping deprecated APIs around indefinitely accumulates technical debt, making the platform harder to maintain. This removal policy means every organisation running Kubernetes needs a plan to track deprecated API usage and plan migrations.
To prepare for upgrades, organisations can use tools like kube-no-trouble (kubent) to scan their cluster for deprecated API usage. Helm chart maintainers also publish compatibility tables. A practical step is to run kubent against your cluster before every major Kubernetes version upgrade.
In practice, the migration from PSP to PSA often revealed hidden dependencies. For example, a Fortune 500 company discovered that 12% of their Helm charts still referenced PSP configurations, even after internal tooling flagged 90% of their workloads. Their migration required manual audits of 800+ charts, with 30% needing custom overrides for edge cases like privileged daemonsets. Another team found that PSA’s default Baseline policy denied sysrq capabilities required by their legacy MySQL operator, forcing them to implement a custom Gatekeeper policy to bypass restrictions without compromising security.
Migrating from PSP to PSA involves auditing existing policies, mapping them to PSA levels like Privileged, Baseline, or Restricted, and applying namespace labels. It also requires handling edge cases where workloads need capabilities that PSA standards deny. For most standard workloads, this migration is mechanical.
The removal policy of Kubernetes implies that organisations must be proactive in tracking and migrating deprecated APIs. This requires a systematic approach to ensure smooth upgrades and minimise disruptions.
Organisations can take steps to prepare for future upgrades by regularly scanning their clusters and planning migrations in advance. This approach helps to minimise the impact of breaking changes and ensures continued stability.