You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Alexey Serbin (Jira)" <ji...@apache.org> on 2022/11/11 19:19:00 UTC

[jira] [Updated] (KUDU-3357) Allow servers to not use the advertised RPC addresses

     [ https://issues.apache.org/jira/browse/KUDU-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Serbin updated KUDU-3357:
--------------------------------
    Code Review: https://gerrit.cloudera.org/#/c/19231/

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