feat: add InfraAnnotations to CloudConfig

[pthuriot-corti]

What this PR does

Adds an InfraAnnotations field to CloudConfig, mirroring the existing InfraLabels behavior. The operator can set default annotations applied to every mirror Service created in the infra cluster.

InfraAnnotations overrides any tenant-Service annotation of the same key, matching the precedence already used for InfraLabels.

Why

Today, tenant Services have to carry infra-cluster-specific annotations (e.g. cloud provider zone, private network ID, LB class) for the mirror Service to be provisioned correctly by the infra cluster's CCM. This leaks infra topology into tenant workloads and prevents global operator-side defaults.

With InfraAnnotations, the cluster operator can set these once in the CCM's cloud-config:

namespace: my-tenant-ns
infraAnnotations:
  service.beta.kubernetes.io/scw-loadbalancer-zone: fr-par-1
  service.beta.kubernetes.io/scw-loadbalancer-pn-ids: 0381c50d-...

Changes

• CloudConfig.InfraAnnotations map[string]string
• Plumbed through loadbalancer and applied during EnsureLoadBalancer
• Unit test covering override precedence

Tests

• go test ./pkg/provider/... passes
• Existing InfraLabels path untouched

[kubevirt-bot]

Hi @pthuriot-corti. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Details

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.

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign orenc1 for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[qinqon]

@pthuriot-corti do you know if something similar is done for other providers ?

[pthuriot-corti]

@qinqon Well, kubevirt CCM is quite unique in the sense that it creates a mirror k8s service in another cluster.
But other providers also allow setting defaults to be applied to all provisioned resources (OpenStack CCM: subnet-id, floating-network-id, flavor-id. Hetzner CCM: type, network-zone, location. Etc ...).
As an operator, I think it makes sense to be able to set defaults and not have to annotate each service individually.

[pthuriot-corti]

Hey @qinqon , any chance we can move forward on this?