Support both Proxy and VIP mode load balancing

[danwinship]

A big reason for having cloud-provider-kind is to be able to test the kube-proxy end of load balancing, but there is more code that needs to be tested in the IPMode: VIP case than in the IPMode: Proxy case that cpkind currently uses. So we should support VIP-mode load balancing as well.

(Presumably we'd use an annotation to select which type we wanted? Not sure how this would work in the e2e suite exactly... probably at first we'd have to have [Feature:CloudProviderKind] or something.

[BenTheElder]

(Presumably we'd use an annotation to select which type we wanted? Not sure how this would work in the e2e suite exactly... probably at first we'd have to have [Feature:CloudProviderKind] or something.

It sounds like the tests should be keying on [Feature: IPMode VIP] (which wouldn't be kind specific?) OR the tests are generic to both and we should just run them twice, once with cloud-provider-kind --ipmode=vip and once with cloud-provider-kind --ipmode=proxy?

(TIL https://kubernetes.io/blog/2023/12/18/kubernetes-1-29-feature-loadbalancer-ip-mode-alpha/)

[aojea]

yeah, tests should try to reflect functionality and features not implementations

[danwinship]

It sounds like the tests should be keying on [Feature: IPMode VIP]

kubernetes/enhancements#4632 talks about trying to figure out how to make LB e2e testing be provider-agnostic. I wanted to avoid having per-subfeature [Feature]s because we'd end up needing a separate subfeature for every single LB test basically 🙁. (Proposed plan in the KEP is to have the e2e tests retroactively detect whether the LB supported the feature, and skip themselves if not.)

we should just run them twice, once with cloud-provider-kind --ipmode=vip and once with cloud-provider-kind --ipmode=proxy?

Yeah, that's probably the right approach.