Introduction

When Cluster Autoscaler logs Failed to watch *v1.CSIDriver, it usually means its informer could not list or watch the CSIDriver resource from the Kubernetes API. In practice, the root causes are usually RBAC permissions, API/version compatibility, or running a Cluster Autoscaler version that does not match the Kubernetes version closely enough.

What Resource Is Actually Failing

CSIDriver is a resource in the storage.k8s.io API group. Cluster Autoscaler watches several Kubernetes resources to understand scheduling constraints and node behavior. If it cannot watch CSIDriver, it may not understand storage-related scheduling details correctly.

So the error is not saying "your CSI driver is broken." It is saying:

• autoscaler tried to watch the CSIDriver resource
• the watch setup failed

That points first to API access and compatibility rather than to persistent volume data itself.

Check RBAC First

The most common fix is to ensure the Cluster Autoscaler service account can list and watch csidrivers.

A relevant ClusterRole rule looks like this:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: cluster-autoscaler
5rules:
6  - apiGroups: ["storage.k8s.io"]
7    resources: ["csidrivers", "csinodes", "storageclasses"]
8    verbs: ["get", "list", "watch"]

And the service account must be bound to that ClusterRole:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRoleBinding
3metadata:
4  name: cluster-autoscaler
5roleRef:
6  apiGroup: rbac.authorization.k8s.io
7  kind: ClusterRole
8  name: cluster-autoscaler
9subjects:
10  - kind: ServiceAccount
11    name: cluster-autoscaler
12    namespace: kube-system

If those permissions are missing, the watch fails even though the autoscaler pod itself is running.

Verify the Autoscaler Version Matches the Cluster

Cluster Autoscaler is version-sensitive. Running a version too far from the Kubernetes control-plane version is a common way to get informer and API mismatch issues.

A practical rule is:

• use the Cluster Autoscaler release intended for your Kubernetes minor version

If your cluster is newer than the autoscaler expects, resources or API behavior may not line up cleanly.

So after RBAC, the next thing to verify is the deployed autoscaler image tag and the Kubernetes server version.

Confirm the API Resource Exists

You should also confirm that the API server exposes the resource you think it does:

kubectl api-resources | grep CSIDriver

and:

kubectl get csidrivers

If the resource is unavailable, disabled, or behaving unexpectedly in your cluster distribution, that changes the troubleshooting path. But in most modern clusters, CSIDriver should be present in storage.k8s.io.

Inspect the Actual Error Detail

The log line after Failed to watch *v1.CSIDriver matters. Common patterns include:

• forbidden
• not found
• the server could not find the requested resource
• connection or TLS-related watch errors

Those imply different fixes:

• 'forbidden: RBAC'
• resource not found: API/version mismatch
• transport issues: API connectivity or certificate problem

Do not stop at the headline log line. The reason string usually narrows the diagnosis dramatically.

Example Deployment Check

Make sure the autoscaler is actually running with the expected service account:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: cluster-autoscaler
5  namespace: kube-system
6spec:
7  template:
8    spec:
9      serviceAccountName: cluster-autoscaler
10      containers:
11        - name: cluster-autoscaler
12          image: registry.k8s.io/autoscaling/cluster-autoscaler:v1.31.0

If the deployment points at the wrong service account or an unexpected image version, your RBAC fixes may appear to do nothing because the running pod is not using the identity or release you think it is.

Managed Clusters Still Need Correct Permissions

On managed Kubernetes services, people sometimes assume the platform wires everything automatically. Often it wires some of it, but not necessarily custom or manually installed autoscaler manifests.

If you installed Cluster Autoscaler yourself:

• inspect the manifest
• inspect the service account
• inspect the ClusterRole
• inspect the image version

That is usually faster than assuming the storage system is the problem.

Common Pitfalls

The biggest mistake is treating Failed to watch *v1.CSIDriver as a CSI storage failure instead of an autoscaler watch failure. The first debugging target should be API access and compatibility.

Another issue is forgetting the storage.k8s.io RBAC rules for csidrivers. The autoscaler may have broad core-resource access and still miss this specific API group.

Developers also often run an autoscaler version that does not match the Kubernetes minor version closely enough. Informer problems then show up as watch failures.

Finally, always read the rest of the log line. forbidden, not found, and transport errors point to different root causes and should not be debugged the same way.

Summary

• This error usually means Cluster Autoscaler could not list or watch the CSIDriver resource.
• Start by checking RBAC permissions for storage.k8s.io resources.
• Make sure the deployed autoscaler version matches the Kubernetes cluster version.
• Confirm the autoscaler pod is using the expected service account and manifest.
• Use the exact error detail after the log headline to distinguish RBAC, API mismatch, and connectivity problems.