Failed to watch *v1beta1.PodDisruptionBudget

[apryiomka]

Which component are you using?:

EKS k8s 1.27 cluster-autoscaler component: https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

What version of the component are you using?:
1.27.2

What environment is this in?:
AWS

Getting this error form cluster-autoscaler deployment log:

I0823 18:17:31.027517       1 reflector.go:255] Listing and watching *v1beta1.PodDisruptionBudget from k8s.io/autoscaler/cluster-autoscaler/utils/kubernetes/listers.go:309
E0823 18:17:31.029219       1 reflector.go:138] k8s.io/autoscaler/cluster-autoscaler/utils/kubernetes/listers.go:309: Failed to watch *v1beta1.PodDisruptionBudget: failed to list *v1beta1.PodDisruptionBudget: the server could not find the requested resource

To my best knowladge, v1beta1.PodDisruptionBudget API was deprecated in favor of policy/v1. Why is 1.27 autoscaler trying to watch v1beta1?

Another error observed is

I0823 18:27:31.272850       1 reflector.go:255] Listing and watching *v1beta1.CSIStorageCapacity from k8s.io/client-go/informers/factory.go:134
E0823 18:27:31.274527       1 reflector.go:138] k8s.io/client-go/informers/factory.go:134: Failed to watch *v1beta1.CSIStorageCapacity: failed to list *v1beta1.CSIStorageCapacity: the server could not find the requested resource

Same issue, it should storage.k8s.io/v1 API, not v1beta1

[adrianmiron]

I can confirm the error , on AWS EKS as well.

[kyland-holmes]

I have this error on AWS EKS as well. It looks like the autoscaler is internally hardcoded to look for the PDB at the v1beta1 version but the policy schema on the control plane is v1. Perhaps there is a way to install the v1beta as a workaround?

[kevin-bates]

This appears to have been addressed in 1.25 via #4990. You might try confirming the actual deployed version in the CA POD log. We (I work with @kyland-holmes) found we had been deploying 1.17 (via helm) and updated our charts such that 1.27.2 got deployed and the issue is no longer present.

An interesting piece of the charts in this area is:

autoscaler/charts/cluster-autoscaler/templates/_helpers.tpl

Lines 78 to 88 in 8e984d7

	{{/*
	Return the appropriate apiVersion for podDisruptionBudget.
	*/}}
	{{- define "podDisruptionBudget.apiVersion" -}}
	{{- $kubeTargetVersion := default .Capabilities.KubeVersion.GitVersion .Values.kubeTargetVersionOverride }}
	{{- if semverCompare "<1.21-0" $kubeTargetVersion -}}
	{{- print "policy/v1beta1" -}}
	{{- else -}}
	{{- print "policy/v1" -}}
	{{- end -}}
	{{- end -}}

which was introduced by #4888.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[seifrajhi]

/remove-lifecycle stale

[seifrajhi]

I face the same issue
EKS v.11.25 and chart prometheus-operator v45.4.0

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[lheringer-bt]

Facing the same issue with CSIStorageCapacity and PodDisruptionBudget APIs.
EKS 1.29
Helm chart: cluster-autoscaler-9.35.0 1.29.0
CSIStorageCapacity
k8s.io/client-go/informers/factory.go:134: Failed to watch *v1beta1.CSIStorageCapacity: failed to list *v1beta1.CSIStorageCapacity: the server could not find the requested resource
PodDisruptionBudget
k8s.io/autoscaler/cluster-autoscaler/utils/kubernetes/listers.go:309: Failed to watch *v1beta1.PodDisruptionBudget: failed to list *v1beta1.PodDisruptionBudget: the server could not find the requested resource

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.