[
https://issues.apache.org/jira/browse/KUDU-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin resolved KUDU-3357.
---------------------------------
Fix Version/s: 1.17.0
Resolution: Fixed
Addressed with
https://github.com/apache/kudu/commit/3f29b5da5f59ea96cfec0608226d5c35740884a6
There might be a couple of follow-up patches:
* address RPC proxying for multi-master Kudu clusters
* make the embedded webservers in kudu-master and kudu-tserver usable in that
sort of setup as well
> Allow servers to not use the advertised RPC addresses
> -----------------------------------------------------
>
> Key: KUDU-3357
> URL: https://issues.apache.org/jira/browse/KUDU-3357
> Project: Kudu
> Issue Type: Improvement
> Components: rpc
> Reporter: Andrew Wong
> Assignee: Alexey Serbin
> Priority: Major
> Fix For: 1.17.0
>
>
> When Kudu servers are deployed within an internal network with internal
> hostnames (e.g. in a k8s cluster), and Kudu clients are deployed outside of
> this network with a mapping of external traffic to internal ports (e.g. with
> a load balancer), it’s unclear how to route the Kudu client to the servers
> without having all traffic (including RPCs between servers) use publicly
> accessible addresses.
> For instance, all servers could be configured with the
> --rpc_advertised_addreses configuration. However, since these addresses are
> used to register servers with the Master, not only would they be used to
> indicate where clients should look for data, but they would also be used to
> indicate where replicas should heartbeat to other replicas. This would induce
> a great deal of traffic on the load balancer.
> We should consider allowing “internal” (i.e. tserver and master) traffic to
> bypass advertised addresses and use an alternate address. Or at the very
> least, introduce a policy for selecting which advertised address to use
> depending on what is available (currently, we always the first in the list).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
