Kubernetes upgrade check tools: kube-upgrade-check, Pluto, kubent and KubePug compared.
Four open-source command-line tools tell you what an upgrade will break. Pluto, kubent and KubePug find deprecated and removed apiVersions, in manifests and in a cluster. kube-upgrade-check reads only a live cluster and also checks config breakers, volume plugins, node version skew and add-on versions.
Every claim about another tool links to that tool's own documentation. We make kube-upgrade-check, so check the links rather than take our word for it.
Comparison table
What each tool checks, where it reads from, and what it leaves out. Scroll sideways on a phone.
| Tool | What it checks | Live cluster vs manifests | Add-ons | Version skew | License |
|---|---|---|---|---|---|
| PlutoFairwindsOps | Deprecated and removed apiVersions, reported as DEPRECATED or REMOVED. Custom checks with --additional-versions. README · docs | Both. Repo manifests and Helm charts (detect-files), live Helm 2 and 3 releases (detect-helm), and the last-applied-configuration annotation (detect-api-resources). source | apiVersions of cert-manager and Istio resources, not whether the installed add-on version supports the target Kubernetes version. versions.yaml | Not covered. README | Apache-2.0. repo |
| kubentDoiT (kube-no-trouble) | Deprecated and removed APIs for a target version, autodetected from the cluster. Extra kinds with --additional-kind. README | Both. Local files (-f), the last-applied-configuration annotation, and Helm 3 release manifests, which needs read access to Secrets. README | Not covered beyond custom kinds you list. README | Not covered. README | MIT. repo |
| KubePugkubectl deprecations plugin | Deprecated and deleted APIs, with the replacement API and the version it was deprecated or deleted in. The database is regenerated every hour from the latest stable Kubernetes. README · database | Both. A running cluster through kubeconfig, files with --input-file, Helm through helm template. README | Not covered. README | Not covered. README | Apache-2.0. repo |
| kube-upgrade-checkRuntimez | Removed APIs (97 rules) with the managedFields writer and date, 382 config breakers, 17 in-tree volume plugins, 34 advisories. Lists every check it could not run, with the reason. README | Live cluster only, read-only. No manifests, no pull requests. README | Installed version vs the vendor support matrix for 7 add-ons: Karpenter, ingress-nginx, cert-manager, Argo CD, CoreDNS, Istio, kube-proxy. README | Yes. 8 node runtime and kubelet skew rules against the target. README | Apache-2.0. repo |
"Not covered" means the tool's own documentation does not list it. Counts for kube-upgrade-check are from its rule catalog on October 19, 2026.
Which to use when
They answer different questions, so most teams run two: one in CI, one before the upgrade.
Before a change merges
Pluto or kubent in CI. Both scan manifests and Helm charts in a repository, so they catch a deprecated apiVersion in a pull request before it reaches a cluster. kube-upgrade-check can't, because it only reads a live cluster.
A quick look from kubectl
KubePug, installed with kubectl krew install deprecations. It downloads a deprecation database regenerated every hour and names the replacement API for each finding.
Before the upgrade itself
kube-upgrade-check against the live cluster, with --target set to the next minor version. It covers what is not in git: kubelet and control-plane settings, in-tree volume plugins, node skew and add-on versions.
Why the API server can't tell you
The obvious check is to ask the API server which apiVersions are in use. It doesn't work: the API server converts objects between versions, so a Deployment created as extensions/v1beta1 comes back as apps/v1 when you ask for apps/v1. The Pluto README explains this well.
So each tool reads other evidence. Pluto and kubent read the original manifest: in files, in stored Helm releases, or in the kubectl.kubernetes.io/last-applied-configuration annotation. That annotation is only written by kubectl apply, so objects created by operators or server-side apply don't have it. kube-upgrade-check reads managedFields, which records the apiVersion each client wrote with, the client's name and the time.
None of this covers version skew. The Kubernetes version skew policy lets a kubelet be up to three minor versions older than the API server and never newer, so a control-plane upgrade can push old nodes out of the supported range without any API being involved.
Try kube-upgrade-check on your cluster.
Free, open source and read-only. Nothing leaves your machine.
kubectl krew install upgrade-checkFrequently asked questions
Still curious? hello@runtimez.io
What is the difference between Pluto and kubent?
Both find deprecated and removed Kubernetes apiVersions. Pluto, from Fairwinds, scans manifests and Helm charts in a repository, live Helm 2 and 3 releases, and the last-applied-configuration annotation, and also knows cert-manager and Istio apiVersions. kubent, from DoiT, reads local files, the same annotation and Helm 3 release manifests, and autodetects the target version.
Which Kubernetes upgrade check tool can review a pull request?
Pluto, kubent and KubePug all read manifests from files, so any of them fits a pull-request check: Pluto with detect-files, kubent with -f, KubePug with --input-file. Render Helm charts first with helm template. kube-upgrade-check reads only a live cluster, so it cannot review a pull request; run it before the upgrade.
Why can't the API server tell me which apiVersion an object uses?
The API server converts objects between versions, so a Deployment created as extensions/v1beta1 comes back as apps/v1 if you ask for apps/v1. That is why these tools read other evidence: the last-applied-configuration annotation, stored Helm releases, or, in kube-upgrade-check, the managedFields entry that names the client that wrote it.
Do these tools check add-on compatibility before a Kubernetes upgrade?
Pluto checks deprecated apiVersions of cert-manager and Istio resources, not whether the installed add-on version supports the new Kubernetes version. kubent and KubePug do not cover add-ons. kube-upgrade-check compares the installed versions of Karpenter, ingress-nginx, cert-manager, Argo CD, CoreDNS, Istio and kube-proxy against each vendor's support matrix for the target version.
Do Pluto, kubent or KubePug check node version skew?
No. All three look at the apiVersions of stored objects, not at node versions. Kubernetes lets a kubelet be up to three minor versions older than the API server and never newer, so upgrading the control plane can push old nodes out of the supported range. kube-upgrade-check compares node and kubelet versions with the target before you upgrade.
Sources
Each tool's own documentation. Checked October 19, 2026.
- Pluto README (FairwindsOps/pluto)
- Pluto docs: Advanced usage (target versions, components, custom checks)
- Pluto source: cmd/root.go (detect-files, detect-helm, detect-api-resources)
- Pluto built-in versions.yaml (k8s, cert-manager, istio)
- kubent README (doitintl/kube-no-trouble)
- kubent README: Arguments
- KubePug README (kubepug/kubepug)
- KubePug deprecation database (kubepug.xyz)
- kube-upgrade-check README (runtimez-com/kube-upgrade-check)
- Kubernetes version skew policy
Last updated