cloud-provider-kind icon indicating copy to clipboard operation
cloud-provider-kind copied to clipboard

Published 20 hours ago • verified publisher icon kubernetes-sigs

Support both `Proxy` and `VIP` mode load balancing

Open danwinship opened this issue 1 year ago • 6 comments
trafficstars

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.

danwinship avatar May 22 '24 21:05 danwinship

(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/)

BenTheElder avatar May 23 '24 19:05 BenTheElder

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

aojea avatar May 23 '24 20:05 aojea

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

https://github.com/kubernetes/enhancements/pull/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 :slightly_frowning_face:. (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.

danwinship avatar Jun 03 '24 15:06 danwinship

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle stale
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot avatar Sep 01 '24 16:09 k8s-triage-robot

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle rotten
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

k8s-triage-robot avatar Oct 01 '24 17:10 k8s-triage-robot

/lifecycle frozen

I don't think we want to stop tracking this, but it may be a bit before it's resolved.

BenTheElder avatar Oct 02 '24 15:10 BenTheElder