Change default lease name for vpa-recommender to "vpa-recommender-lease" to avoid conflicts #781
Conversation
…se" to avoid lock conflicts.
|
Good catch. What I can do is to use the same namespace as VPA for the lease and maybe the chart release name as the lease name. I don't understand the PR that introduced that change as there is another lease for the admission controller which is in the VPA namespace. |
There's different kinds of leases used for different things in VPA: There is the lease renewed by the admission-controller, which is checked by the updater to ensure that the admission-controller is up and running before evicting any Pods. That lease is managed by the admission-controller's The other kinds of leases introduced recently are for leader election, so you can run the VPA components in primary-secondary HA mode. For recommender and updater we need to ensure that only one instance is active at the same time, so they use their own leader election leases. The default names of those leases collide with a lease that's already present in GKE, so we're trying to make sure people installing open-source VPA on GKE don't see problems they cannot fix on their own. Does this make sense? |
|
Hi @voelzmo my comment was not about the other leases but the fact that this one is using kube-system namespace by default. I will wait for an official new release of VPA to see how the change will be managed and either it's breaking thing or not. |
See kubernetes/autoscaler#7461.
The default lock name can sometimes conflict with a managed deployment of VPA/HPA which can cause issues on your cluster.
Here we are proposing changing the flag value in the Helm chart to a new name (
vpa-recommender-lease). We are keeping the old resource name in the RBAC to avoid disruptions or issues during upgrade.I am totally open to thoughts or ideas on how we can make this better and smoother :)