-
Notifications
You must be signed in to change notification settings - Fork 595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[occm] KEP-1860: Add support for LoadBalancer ipMode #2587
Conversation
Welcome @kbudde! |
Hi @kbudde. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the 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/test-infra repository. |
@gryf, you might want to check this out. |
/ok-to-test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: zetaab 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:
Approvers can indicate their approval by writing |
/lgtm @dulek maybe you can check this again before merge |
// Set the LoadBalancerIPMode to Proxy to prevent kube-proxy from injecting an iptables bypass. | ||
// https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/1860-kube-proxy-IP-node-binding | ||
ipMode = corev1.LoadBalancerIPModeProxy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so reading [1] this seems pretty much correct, but reading [2] I would argue we should always set IPMode to Proxy, because following is true for both Amphora and OVN:
Setting this to "Proxy" indicates that traffic is delivered to the node or pod with the destination set to the node's IP and node port or the pod's IP and port. Service implementations may use this information to adjust traffic routing.
What am I missing?
Also - doesn't this apply to other Amphora functions, like TLS termination or XForwardedFor
header injection?
[1] https://kubernetes.io/blog/2023/12/18/kubernetes-1-29-feature-loadbalancer-ip-mode-alpha/
[2] https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#loadbalanceringress-v1-core
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
afaik 1 is how I understood this should work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. 1 is how it is supposed to work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ipMode field should only be set, if the loadbalancer IP is used and not an Hostname.
LoadBalancer with IngressHostname are not optimized in terms of traffic flow as kube-proxy would need to do a dns query before writing the firewall rules (and update it every time dns changes).
status.Ingress = []corev1.LoadBalancerIngress{{IP: addr}} | ||
status.Ingress = []corev1.LoadBalancerIngress{{ | ||
IP: addr, | ||
IPMode: &ipMode, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens when the feature gate is off and this is set? Is it a no-op? Should we have this behind a feature gate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's save, the field is just ignored if the feature is not enabed.
Disable the feature flag ("downgrade")
Edit kube-apiserver manifest and disable the feature flag
Edit kube-proxy configmap, disable the feature and restart kube-proxy Pods
Confirmed that both iptables rules are present, even if the ipMode field was still set as Proxy, confirming the feature is disabled. Both accesses are working
I added a bunch of questions. |
/hold cancel |
What this PR does / why we need it:
This PR adds support for ipMode in LoadBalancer status field introduced in KEP-1860.
This enables the usage of Proxy Protocol without workaround (EnableIngressHostname + IngressHostnameSuffix).
The workarounds were introducing new issues, e.g. externalDNS was not functional with a loadbalancer with ingress Hostname set.
Which issue this PR fixes(if applicable):
There is no open issue as a workaround was introduced.
Special notes for reviewers:
Tthe ipMode field is available even if IpMode is still behind a featureGate, so this change could be backported to 1.29.
Release note: