-
Notifications
You must be signed in to change notification settings - Fork 51
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
Add docs for clusterset IP feature #1181
base: devel
Are you sure you want to change the base?
Conversation
🤖 Created branch: z_pr1181/tpantelis/clusterset_ip |
1bfdc7e
to
75f49b3
Compare
Lighthouse DNS will return the cluster set virtual IP from queries instead of a constituent cluster IP address. However, Submariner | ||
does not perform load balancing and relies on some external component to do so. |
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.
This gives the impression that the virtual IP won’t work unless the user does something else — is that so?
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.
yes. This is for Istio support - they need a VIP and will handle the rest. We could also not document this feature.
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.
How is the routing handled for the virtualIP? Are we adding any iptable rules to support the datapath?
Lighthouse DNS will return the cluster set virtual IP from queries instead of a constituent cluster IP address. However, Submariner does not perform load balancing and relies on some external component to do so.
Normally when we return the clusterIP itself (or the associated GlobalIngressIP) kube-proxy does the load-balancing once the remote traffic lands in the local cluster (where the service is exprted). Can you please eloborate how this use-case works with virtualIP?
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.
Currently we're not doing any routing. This feature currently will be used only by Istio and it will take care of routing. Current submariner connectivity doesn't support this use case.
This use case can also be used by someone using Lighthouse-only for MCS service discovery and using their own MCS controller for datapath.
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 seems to me that this should be documented because users could end up shooting themselves in the foot.
Can we make the caveat more general? It’s not just load balancing, it’s any kind of routing.
Lighthouse DNS will return the cluster set virtual IP from queries instead of a constituent cluster IP address. However, Submariner | |
does not perform load balancing and relies on some external component to do so. | |
Lighthouse DNS will return the cluster set virtual IP from queries instead of a constituent cluster IP address. However, Submariner | |
does not route this virtual IP and relies on some external component to do so. |
User guide and subctl commands. Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
75f49b3
to
addbbc8
Compare
User guide and subctl commands.