Kubernetes
DevOps
CI/CD
Cloud Infrastructure
Version Upgrade

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/v1beta1 Ingress had to move to networking.k8s.io/v1
  • batch/v1beta1 CronJob had to move to batch/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:

yaml
1apiVersion: networking.k8s.io/v1beta1
2kind: Ingress
3metadata:
4  name: app
5spec:
6  rules:
7    - host: example.com
8      http:
9        paths:
10          - path: /
11            backend:
12              serviceName: app
13              servicePort: 80

New style:

yaml
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app
5spec:
6  rules:
7    - host: example.com
8      http:
9        paths:
10          - path: /
11            pathType: Prefix
12            backend:
13              service:
14                name: app
15                port:
16                  number: 80

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 kubectl or 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.

bash
helm template myapp ./chart | kubectl apply --dry-run=server -f -

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 apiVersion strings 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.22 broke 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.

Course illustration
Course illustration

All Rights Reserved.