add subresource status for vpa

[wu0407]

What type of PR is this?

What this PR does / why we need it:

Current vpa crd has empty subresource field, that leads to metadata.generation increase on vpa status update.
The controller-runtime has GenerationChangedPredicate to filter out update status event for cr, but it not work for vpa.
This PR add status field in subresource on crd yaml and add new ClusterRole system:vpa-actor to patch /status subresource.
The metadata.generation only increase on vpa spec update.

Which issue(s) this PR fixes:

Fixes: #5675

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Added the /status subresource to VPA
action required: If you're installing VPA with different means than the `hack/vpa-up.sh` script, you need to add the ClusterRole `system:vpa-status-actor` and corresponding ClusterRoleBinding yourself. Otherwise VPA will no longer be able to update the recommendations!

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: wu0407 / name: wowqing (50653fb)

[k8s-ci-robot]

Welcome @wu0407!

It looks like this is your first PR to kubernetes/autoscaler 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/autoscaler has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[voelzmo]

Good catch, thanks! Just a few comments from my side, mostly dealing with semantics.

[voelzmo]

Thanks for the changes! The only thing missing from my side is a release note pointing people to the new, required permissions. There are lots of people using different means to deploy the VPA (e.g. Helm charts or home-grown scripts/code), we need to point them and the maintainers of these solutions to the changes they need to make to their solutions.
What about something like this

Added the /status subresource to VPA
action required: If you're installing VPA with different means than the `hack/vpa-up.sh` script, you need to add the ClusterRole `system:vpa-status-actor` and corresponding ClusterRoleBinding yourself. Otherwise VPA will no longer be able to update the recommendations!

@jbartosik: I don't think we're adding these release notes automatically to the github releases yet, but I guess this would be helpful when compiling the release notes? WDYT?

[jbartosik]

Thanks for the changes! The only thing missing from my side is a release note pointing people to the new, required permissions. There are lots of people using different means to deploy the VPA (e.g. Helm charts or home-grown scripts/code), we need to point them and the maintainers of these solutions to the changes they need to make to their solutions. What about something like this

Added the /status subresource to VPA
action required: If you're installing VPA with different means than the `hack/vpa-up.sh` script, you need to add the ClusterRole `system:vpa-status-actor` and corresponding ClusterRoleBinding yourself. Otherwise VPA will no longer be able to update the recommendations!

Joachim: I don't think we're adding these release notes automatically to the github releases yet, but I guess this would be helpful when compiling the release notes? WDYT?

Release notes from PR descriptions aren't automatically added to Github releases. But they make writing release notes easier. Please add

[jbartosik]

Also if I understand correctly the point here is that there will be user-visible API change.

Could you explain what will change? It's not clear to me from reading the isse

[jbartosik]

Please fix the commit message. I think you can't reference issues / PRs in commit messages. You can (and should and do) do that in PR mesages

[voelzmo]

Also if I understand correctly the point here is that there will be user-visible API change.

I don't think anything will change for users, except that currently metadata.generation is increased on every new recommendation, which isn't necessary. Another aspect is that the recommender has permissions to change all VPA .specs, which it doesn't need – permissions for changing /status is sufficient.

For operators, though, we need to ensure that they update CRD, RBAC rules and VPA version at the same time, otherwise this will just stop working.

[wu0407]

Thanks for the changes! The only thing missing from my side is a release note pointing people to the new, required permissions. There are lots of people using different means to deploy the VPA (e.g. Helm charts or home-grown scripts/code), we need to point them and the maintainers of these solutions to the changes they need to make to their solutions. What about something like this

Added the /status subresource to VPA
action required: If you're installing VPA with different means than the `hack/vpa-up.sh` script, you need to add the ClusterRole `system:vpa-status-actor` and corresponding ClusterRoleBinding yourself. Otherwise VPA will no longer be able to update the recommendations!

Joachim: I don't think we're adding these release notes automatically to the github releases yet, but I guess this would be helpful when compiling the release notes? WDYT?

Release notes from PR descriptions aren't automatically added to Github releases. But they make writing release notes easier. Please add

Added detail what to do in this pr and commit

[voelzmo]

The release notes look good so far, they just need to mention that operators also need to update their CRD. Sorry I missed that in the first suggestion I had about the notes.

[mwielgus]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mwielgus, wu0407

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• vertical-pod-autoscaler/OWNERS [mwielgus]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment