-
Notifications
You must be signed in to change notification settings - Fork 449
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
dualstack user guide #1357
base: main
Are you sure you want to change the base?
dualstack user guide #1357
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
--- | ||
title: "Dualstack Backends" | ||
description: >- | ||
Explains the dualstack backend feature in gRPC. | ||
--- | ||
|
||
### Overview | ||
|
||
In cases where an endpoint (i.e., a gRPC server) has both an IPv4 and | ||
IPv6 address, it is useful for clients to know both of those addresses, | ||
so that they can reach the endpoint on either of them. Because only | ||
one of the two protocols may actually be routable between a given | ||
client and endpoint, clients need to try both addresses to see which | ||
one will work. To minimize connection attempt latency, it is also | ||
desirable for clients to attempt to connect to multiple addresses in | ||
parallel, which is done using the "Happy Eyeballs" algorithm described in | ||
[RFC-8305](https://www.rfc-editor.org/rfc/rfc8305). | ||
|
||
In gRPC, it is particularly important for the [Load Balancing | ||
Policy](https://grpc.io/docs/guides/custom-load-balancing) to understand | ||
which addresses are associated with the same endpoint as opposed to | ||
being different endpoints, so that the client does not send twice as | ||
much load to a endpoint with two addresses. To that end, the [Name | ||
Resolver](https://grpc.io/docs/guides/custom-name-resolution) can return | ||
multiple addresses per endpoint (where an endpoint is a single endpoint), | ||
and that information is communicated to the Load Balancing Policy. | ||
|
||
Note that the only name resolver implementation that gRPC provides is a | ||
DNS resolver, which does not support dualstack backends. This is | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It won't be clear to users what "does not support" means here. You can use dualstack backends with pick_first. Maybe the earlier paragraph about load balancing policies needs to call out that nothing special needs to happen for the default policy, pick_first. But if using a different policy it probably needs NR support? And then you can use round_robin as an example when explaining the twice-the-load problem. |
||
because DNS inherently returns a flat list of addresses, with no way to | ||
indicate whether or not multiple addresses actually point to the same | ||
endpoint. | ||
|
||
There are two ways to use dualstack endpoints in gRPC: | ||
|
||
1. Write your own custom name resolver that returns multiple | ||
addresses per endpoint. For more information, see [Custom Name | ||
Resolution](https://grpc.io/docs/guides/custom-name-resolution). | ||
2. Use an xDS control plane that can communicate multiple addresses | ||
per endpoint to the client. For more information, consult the | ||
documentation for your xDS control plane. | ||
Comment on lines
+39
to
+41
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was going to say this should link to some grpc xds documentation for how to set up your client to talk to your control plane, but...I can't find anything appropriately user-facing. Should we link to https://github.com/grpc/proposal/blob/master/A27-xds-global-load-balancing.md for now? Should we create another guide that covers how to set up a bootstrap file and create an xds-enabled grpc client (and server, possibly separately)? |
||
|
||
For more information on gRPC dualstack backend support, see [gRFC | ||
A61](https://github.com/grpc/proposal/blob/master/A61-IPv4-IPv6-dualstack-backends.md). | ||
|
||
### Custom Resolver Dualstack Examples | ||
|
||
| Language | Example | Notes | | ||
|----------|------------------|----------------------------------------| | ||
| C++ | | C++ resolver API not yet public. | | ||
| Go | | Go dualstack support not yet complete. | | ||
| Java | [Java example] | | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe indicate that both Java and Go have only experimental support for custom LB policies? |
||
| Python | | Python resolver API not yet available. | | ||
|
||
[Java example]: https://github.com/grpc/grpc-java/tree/master/examples/example-dualstack |
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 is also desirable" doesn't say what is actually done or who is responsible for it. "To minimize connection attempt latency, gRPC clients will attempt..."?