As Kubernetes continues its rapid evolution—with new minor releases every few months—cluster administrators face a recurring challenge: upgrading safely without disrupting workloads. One of the biggest risks during an upgrade is deprecated or removed APIs. If your deployments, DaemonSets, Ingresses, or other resources still reference API versions that have been phased out, the upgrade can lead to broken resources, failed admissions, or even unavailable applications.
This is where Kube No Trouble, commonly known as kubent, shines. It’s an open-source tool designed to scan your cluster for usage of deprecated Kubernetes APIs, giving you a clear heads-up before you pull the trigger on a cluster upgrade.
Why Deprecated APIs Are a Major Upgrade Roadblock
Kubernetes follows a strict deprecation policy: beta APIs are supported for a limited time (typically 9 months or 3 releases) before removal, while stable APIs get longer notice. Recent examples include:
- The removal of many beta extensions in v1.22 (e.g., Ingress from networking.k8s.io/v1beta1).
- Further cleanups in v1.25 and v1.26.
- As of late 2025 (Kubernetes v1.35 era), ongoing removals like cgroup v1 support and IPVS proxy mode highlight the need for vigilance.
The problem? Kubernetes stores resources in their preferred storage version, not the original apiVersion from your manifests. So, even if a resource appears up-to-date via kubectl get, it might have been created with a now-deprecated version—especially if deployed via kubectl apply or Helm.
When you upgrade the cluster, those old APIs vanish, and your resources can break silently or loudly.
Enter kubent: Your Pre-Upgrade Safety Net
Maintained by DoIt International (repo: github.com/doitintl/kube-no-trouble), kubent intelligently collects the original manifests stored in the cluster:
- kubectl.kubernetes.io/last-applied-configuration annotations (from imperative kubectl apply).
- Helm release secrets/configmaps (for Helm v2/v3 deployments).
It then checks them against built-in Rego policies for known deprecations, tailored to your current cluster version and potential future targets.
Typical output looks like this:
>>> Kube No Trouble `kubent` <<< Initializing collectors and retrieving data Retrieved XX resources from collector name=Cluster Loaded ruleset name=deprecated-1.XX.rego >>> Deprecated APIs <<< KIND NAMESPACE NAME API_VERSION Deployment default my-app apps/v1beta1 Ingress kube-system legacy-ingress networking.k8s.io/v1beta1
How to Use kubent
Installation is straightforward:
- Homebrew: brew install kubent
- curl script: sh -c “$(curl -sSL https://git.io/install-kubent)”
- Docker: docker run –rm ghcr.io/doitintl/kube-no-trouble:latest
Run it against your cluster (uses your current kubeconfig):
kubent
Key flags:
- -t <version>: Check against a specific target Kubernetes version (e.g., the one you’re upgrading to).
- -o json: Machine-readable output for CI/CD integration.
- -e: Exit with non-zero code if issues found (great for pipelines).
Pro tip: Integrate kubent into your CI/CD or pre-upgrade checklist. Tools like Testkube even have built-in executors for running it as a test.
Best Practices for Smooth Kubernetes Upgrades
- Run kubent early — Before planning any upgrade, scan your cluster.
- Fix identified resources — Update manifests to stable API versions (e.g., apps/v1 for Deployments).
- Test in staging — Replicate production as closely as possible and run the upgrade there first.
- Review release notes — Always check Kubernetes changelog for breaking changes.
- Use blue-green or canary strategies for high-availability clusters.
Conclusion
Upgrading Kubernetes shouldn’t feel like defusing a bomb. With kubent in your toolkit, you can proactively identify and remediate deprecated API usage, making cluster upgrades predictable and low-risk.
Next time you’re eyeing that new Kubernetes version for its shiny features or critical security patches, start with kubent. Your workloads—and your on-call rotations—will thank you.
Follow us for more Updates
