A helm upgrade fails with 'no matches for kind "Ingress" in version "networking.k8s.io/v1beta1"' — what is the cluster telling you?

### Where the sentence comes from Every Kubernetes client — `kubectl`, a controller, and Helm alike — has to turn the pair (`apiVersion`, `kind`) written at the top of a manifest into a concrete REST endpoint. It does that by fetching the API server's discovery document, which lists every group/version the cluster currently serves and the resources inside each, and building a mapper from it. The string `no matches for kind "Ingress" in version "networking.k8s.io/v1beta1"` is what that mapper returns when the group/version it was handed is not in the list. That matters for how you read the error. Nothing is malformed. The YAML parsed, the indentation is fine, the field names are spelled correctly, and RBAC never entered the picture — Helm never got as far as making a request. The cluster simply has no `networking.k8s.io/v1beta1` endpoint to talk to, because a Kubernetes release retired that beta group/version and the cluster has since been upgraded onto it. Beta APIs are removed on a published schedule; the day someone upgrades the cluster is the day any manifest still naming the beta version stops resolving. ### The other cause of the same sentence The identical message appears for an unrelated reason: a custom resource whose CustomResourceDefinition is not installed. Helm's message often appends a hint about ensuring CRDs are installed first, which sends people hunting for a missing operator when the real cause is a retired built-in API. Read the group inside the quotes to tell them apart. A well-known Kubernetes group with a beta suffix on a kind you recognise as built-in — `networking.k8s.io/v1beta1` for `Ingress`, `policy/v1beta1` for `PodDisruptionBudget`, `batch/v1beta1` for `CronJob` — is a retired built-in, and the fix is a newer `apiVersion`. A vendor group you do not recognise on a kind you do not recognise is a missing CRD, and the fix is installing the operator that owns it. ### Which manifest is at fault Helm reads two manifests during an upgrade: the one it renders from the chart you passed, and the one it stored when the release was last installed or upgraded. Both are plain text; either can name a version the cluster no longer serves. Distinguishing them is the whole job on this error, because the repairs are completely different. If the **new render** is at fault, the chart is out of date and the fix is a chart bump — a newer chart version that emits the supported `apiVersion`. You can see it without touching the cluster: ``` helm template ./platform -n payments | grep -n 'networking.k8s.io' ``` If the **stored manifest** is at fault, the chart may already be perfect and the upgrade still fails, because Helm has to decode the previous release's manifest before it can work out what changed. That copy is frozen at the text it was written with and nothing rewrites it retroactively — not the API server, not a later `helm repo update`, not the fact that the live object is perfectly healthy. You see it with: ``` helm get manifest fraud-scoring -n payments | grep -n 'networking.k8s.io' ``` The live object being fine is the part that confuses people. When a cluster stops serving a version, the objects themselves do not disappear; the API server keeps serving them under a version it still supports, and `kubectl get ingress` works normally. Helm's problem is with its own recorded text, not with the running resource. ### What to do first Run both greps before changing anything. They cost nothing, they need no cluster write access, and between them they tell you whether you are fixing a chart or repairing a release record. If only the render is stale, upgrade the chart dependency or bump the subchart and re-run. If the stored manifest carries it, a chart bump alone will not clear the error, and you are into repairing the stored release record — rewriting the retired version inside it, or dropping the release history and re-adopting the live objects. One piece of timing advice that this error teaches better than any doc: if you know a version is about to be retired and your chart already renders the supported one, upgrade the release **now**, while the old version still resolves. The upgrade succeeds, the new revision's stored manifest carries the supported version, and the problem never happens. After the cluster has dropped the API you have the same fix plus a broken release to repair first.