deps: update registry.k8s.io/sig-storage/csi-resizer docker tag to v1.13.1

[renovate]

This PR contains the following updates:

Package	Update	Change
registry.k8s.io/sig-storage/csi-resizer	minor	v1.12.0 -> v1.13.1

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[lukasmetzner]

Kubernetes v1.32 and csi-resizer v1.13.1 have a beta feature gate on by default. This causes compatibility issues with csi-resizer v1.13.1 and Kubernetes < v1.32.

To mitigate this we could enable/disable the feature gate in the csi-resizer via a helm check against .Capabilities.KubeVersion.Minor, or make it configurable by the user.

What do you think @apricote ?

Ref:

• KEP
• Release Notes

[apricote]

Conditionally disabling the feature flag sounds like the best solution to me. If someone wants this configurable we can still add that later on.

[lukasmetzner]

Conditionally disabling the feature flag sounds like the best solution to me. If someone wants this configurable we can still add that later on.

I agree. We can also change it when the feature moves out of beta.

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[apricote]

This causes an issue, you need to make sure that it uses an empty array if nothing is defined, pretty sure we have an example for this between HCCM and csi-driver.

[lukasmetzner]

Solved it by adding the args key depending if either leading election is enabled or if the feature gate should be disabled.

[lukasmetzner]

@apricote I ran into an issue, which I first did not realize locally, due to an outdated helm version. As skaffold uses helm template and not helm install under the hood, it will always activate the feature gate, due to helm choosing the latest supported k8s version in the template subcommand.

Furthermore, I noticed that we would have to make a decision on how to move further with the snapshots. Should we enable or disable the feature gate there? I'd probably go for disabling, as it will break deployments otherwise. This though has the consequence of having to provide --kube-version v1.31.0 to the helm template command in hack/update-helm-snapshots.sh and hack/update-deployment-yamls.sh. This might get tedious to manage though.

Should we make it a feature flag in the values then?

[apricote]

As skaffold uses helm template and not helm install under the hood

Annoying. Just checked the docs, manifests.helm uses helm template | kubectl apply -f, but we could use deploy.helm instead to actually run helm install.

---

For deploy/kubernetes/hcloud-csi.yml I would disable the flag, as that needs to be compatible with Kubernetes 1.29 - 1.32 at the moment. I don't think adding the flag in our scripts is a large hassle.

---

That said, if you are keen on it, you can make it a feature flag, but needs to be documented that it will be removed when upstream removes the flag.