DevOps CI/CD pipelines broken after Kubernetes upgrade to v1.22
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Kubernetes v1.22 broke many CI/CD pipelines not because deployment logic suddenly changed, but because several long-deprecated beta APIs were finally removed. If your manifests, Helm charts, admission webhooks, or deployment tools still generated old API versions, pipeline steps that had worked in earlier clusters started failing during validation or apply.
The Main Breaking Change Was API Removal
The highest-signal thing to check after a v1.22 upgrade is manifest API version usage. Common removals included beta versions for resources such as Ingress and CronJob.
Typical examples:
networking.k8s.io/v1beta1Ingresshad to move tonetworking.k8s.io/v1batch/v1beta1CronJobhad to move tobatch/v1- several admissionregistration, authentication, and certificate APIs also lost older beta forms
A pipeline that still templates removed API versions may fail during kubectl apply, server-side validation, or Helm install even if the YAML shape looks mostly familiar.
Fix the Manifests First
A representative Ingress migration looks like this.
Old style:
New style:
This is not just an API version string change. The schema changed too.
Check Your Tooling, Not Only the YAML Repository
Even if your main manifests are updated, the pipeline can still break because some generator in the chain is producing outdated output. Common offenders are:
- old Helm chart versions,
- stale Kustomize bases,
- custom operators or templates embedded in CI repositories,
- pinned
kubectlor deployment plugins that assume older APIs.
That is why the right debugging step is to inspect the fully rendered manifests produced by the pipeline, not only the source templates you think are being used.
Validate Against the Target Cluster Version Early
A robust pipeline should validate manifests against the destination Kubernetes version before the deploy stage. For example, a render-plus-dry-run step can catch removed APIs before a release window.
If the cluster or API server used for validation matches the real target environment, this catches many version-related failures earlier and with better error messages.
Watch for Security and Policy Side Effects
Some upgrades expose policy dependencies too. PodSecurityPolicy deprecation and removal paths often affected clusters whose pipeline expected a specific security controller behavior. Even when the pipeline itself was syntactically correct, deployments could start failing because the cluster’s admission behavior changed.
That means an upgrade review should include both API compatibility and policy enforcement changes.
Common Pitfalls
- Updating only
apiVersionstrings without updating the resource schema beneath them. - Fixing checked-in manifests while leaving old Helm charts or generated templates untouched.
- Validating only with client-side tools instead of against the real cluster API behavior.
- Assuming the failure is in the CI system when the rendered manifest is simply not valid in
v1.22. - Treating security-policy and admission changes as unrelated to deployment failures.
Summary
- Kubernetes
v1.22broke many pipelines by removing long-deprecated beta APIs. - Ingress and CronJob migrations were especially common failure points.
- Rendered pipeline output matters more than assumptions about source templates.
- Server-side validation against the target cluster version should be part of the pipeline.
- Successful upgrades require checking manifests, generators, and policy behavior together.

