Introduction

This error appears when a Knative Serving manifest references the HorizontalPodAutoscaler resource in an API version that your cluster does not serve. In practice, the fix is almost never "edit one line and hope"; you need to check cluster compatibility, installed APIs, and the Knative release you are applying.

Why the Error Happens

Kubernetes resources are versioned by API group and version, such as apps/v1 or autoscaling/v2. When kubectl applies a manifest, the API server must recognize that exact combination. If the manifest contains apiVersion: autoscaling/v2 but the cluster only supports an older HPA version, the server rejects it with the "no matches for kind" message.

This often happens in one of three situations:

1. The Kubernetes cluster is older than the manifest expects.
2. The Knative Serving release targets a different Kubernetes support window.
3. You are applying manifests against the wrong cluster or context.

Before changing YAML, confirm what the cluster can actually serve.

1kubectl config current-context
2kubectl version --short
3kubectl api-resources | grep HorizontalPodAutoscaler
4kubectl explain hpa --api-version=autoscaling/v2

If the last command fails, the cluster does not support that version of the HPA API.

Verifying Knative and Cluster Compatibility

Knative releases are tested against specific Kubernetes versions. That matters because Knative depends on resources that may move from beta to stable APIs over time. If you install a newer Knative release on an older cluster, resource mismatches like this one are expected.

A safer workflow is:

1. Check the Kubernetes version running in the cluster.
2. Check the support matrix for the Knative release you plan to install.
3. Apply the exact manifests for that supported combination.

The following command pattern is common when installing from a published release:

kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.15.1/serving-crds.yaml
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.15.1/serving-core.yaml

The important part is not the specific version string in this example. The important part is that the release assets must match a Kubernetes version range your cluster actually satisfies.

Fixing the Problem the Right Way

The cleanest fix is usually to upgrade the cluster or install a Knative release compatible with the cluster you already have. Hand-editing Knative manifests from autoscaling/v2 to an older API version can work for a single plain HPA object, but it is risky in a platform install because schema details and controller expectations may differ.

For comparison, a valid HPA manifest using autoscaling/v2 looks like this:

1apiVersion: autoscaling/v2
2kind: HorizontalPodAutoscaler
3metadata:
4  name: example-hpa
5spec:
6  scaleTargetRef:
7    apiVersion: apps/v1
8    kind: Deployment
9    name: example-app
10  minReplicas: 1
11  maxReplicas: 10
12  metrics:
13    - type: Resource
14      resource:
15        name: cpu
16        target:
17          type: Utilization
18          averageUtilization: 70

If your cluster only supports autoscaling/v2beta2 or autoscaling/v1, simply changing the apiVersion field may still be insufficient because the metric schema can differ. That is why compatibility checks should come before manual edits.

Common Pitfalls

One common mistake is assuming that kubectl client version alone determines support. It does not. The API server version and enabled resources on the cluster are what matter.

Another mistake is applying manifests from blog posts or copied snippets without checking whether they belong to the same Knative release. Mixing CRDs and core components from different releases creates hard-to-debug failures that look unrelated at first.

A third issue is forgetting the current context. Engineers often troubleshoot API support on one cluster and apply manifests to another. Running kubectl config current-context before every install is a simple habit that prevents wasted time.

Summary

• The error means the cluster API server does not recognize HorizontalPodAutoscaler in autoscaling/v2.
• Confirm support with kubectl api-resources and kubectl explain before editing manifests.
• Match your Knative Serving release to the Kubernetes version range supported by that release.
• Prefer upgrading the cluster or choosing a compatible Knative version over manually downgrading API fields.
• Check the active kubectl context, because applying to the wrong cluster can produce misleading results.