Description of problem: The "vpa-recommender" correctly adds a "recommendation" but never seems to take any action to actually scale the Pods. * vpa-updater logs at the time we expect the pods to be evicted: ~~~ I1116 14:45:32.477853 1 main.go:73] Vertical Pod Autoscaler 0.8.0 Updater I1116 14:45:32.586672 1 fetcher.go:100] Initial sync of CronJob completed I1116 14:45:32.687371 1 fetcher.go:100] Initial sync of DaemonSet completed I1116 14:45:32.787849 1 fetcher.go:100] Initial sync of Deployment completed I1116 14:45:32.888267 1 fetcher.go:100] Initial sync of ReplicaSet completed I1116 14:45:32.988791 1 fetcher.go:100] Initial sync of StatefulSet completed I1116 14:45:33.089079 1 fetcher.go:100] Initial sync of ReplicationController completed I1116 14:45:33.190080 1 fetcher.go:100] Initial sync of Job completed I1116 14:45:33.394133 1 updater.go:241] Rate limit disabled I1116 14:45:33.795215 1 api.go:94] Initial VPA synced successfully E1116 14:46:33.809364 1 updater.go:116] Error getting Admission Controller status: leases.coordination.k8s.io "vpa-admission-controller" not found. Skipping eviction loop E1116 14:47:33.806088 1 updater.go:116] Error getting Admission Controller status: leases.coordination.k8s.io "vpa-admission-controller" not found. Skipping eviction loop E1116 14:48:33.803952 1 updater.go:116] Error getting Admission Controller status: leases.coordination.k8s.io "vpa-admission-controller" not found. Skipping eviction loop E1116 14:49:33.818845 1 updater.go:116] Error getting Admission Controller status: leases.coordination.k8s.io "vpa-admission-controller" not found. Skipping eviction loop ~~~ # vpa status ~~~ updatePolicy: updateMode: Auto status: conditions: - lastTransitionTime: "2020-11-16T14:47:33Z" status: "True" type: RecommendationProvided ~~~ Version-Release number of selected component (if applicable): How reproducible: Always Actual results: VPA isn't taking any actions per the recommendation. Expected results: VPA should take action as per the recommendation.
Hi, I see that your stateful set has only one replica. VPA as configured in OpenShift will never kill your pod if you have just one replica. The system does not want to cause downtime for your application and assumes that killing and replacing a lone pod (in order to update the resource requests) is a bad idea. If you restart the pod manually, does the new pod start with the recommended limits? Also, if the application can run with two replicas, you might try retrying your test with two or more replicas and see if VPA will kill and replace pods that need updated resource requests.
*** Bug 1938949 has been marked as a duplicate of this bug. ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days