Update kubernetes to 1.32

[dfajmon]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Bump Kubernetes to v1.32.0

Does this PR introduce a user-facing change?:

Update Kubernetes dependencies to 1.32.0

[k8s-ci-robot]

Hi @dfajmon. Thanks for your PR.

I'm waiting for a kubernetes-csi member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[jsafrane]

/ok-to-test

[jsafrane]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dfajmon, jsafrane

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:

• OWNERS [jsafrane]

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

[huww98]

Do we really need to update the deps so often? This is a lib, and does not produce executable itself. Bumping dep version forces every consumer to update transitive deps when updating this module, which is unnecessary. I think we should only update the deps when we really depend on the new feature. Consumers can still use newer version than declared in this repo.

[dfajmon]

@huww98 We update libraries once for release unless there are bug fixes that might need more bumps. It's also better to have a unified Kubernetes version across all projects in one release.

[huww98]

It's also better to have a unified Kubernetes version across all projects in one release.

I agree with this for modules that produce executable, and rarely imported by other projects. But for module like this repo, updating has no benefits, I think. Golang will pick the updated version specified in the main module anyway.

Our project is currently using client-go 1.30.0, and I just want to use the new protosanitizer (1 file changed, 56 insertions(+), 113 deletions(-)). And that go mod vendor brings me 1981 files changed, 60843 insertions(+), 117187 deletions(-) to my vendor dir, which is far more than necessary. Yes, we will upgrade eventually. But I think it is not necessary to force every project in the community to follow tightly. At least allow us to use the still maintained backport version?