Proxied RPCs in Kudu

You can configure RPC endpoints for Kudu servers to separate internal and external traffic in a Kudu cluster to enable inter-cluster communications.

You can separate the internal and the external traffic in a Kudu cluster while providing the connectivity for Kudu clients running in external networks where the internal traffic is never routed through a proxy's or a loadbalancer's endpoint. Essentially, it allows for the internal traffic (for example, the traffic between tablet servers and masters) to bypass advertised RPC addresses, using alternative addresses for inter-cluster communications.

You can configure additional RPC endpoints for Kudu servers to handle traffic proxied from external networks. So, when a Kudu server receives an RPC request, it possesses enough information to decide whether to handle the request as arriving from an internal network or an external network. All the communications of Kudu components within the cluster's internal network are routed through the standard RPC endpoints. But the requests proxied from external networks are routed through those dedicated RPC endpoints.When a Kudu server receives an RPC request through such an endpoint, it sends a response where the internal RPC addresses of Kudu servers are substituted with corresponding RPC addresses reachable to Kudu clients outside the cluster through a TCP proxy.

To support proxied RPCs, the following flags are introduced; both flags accepting comma-separated list of strings in the <hostname>:<port> form:
  • --rpc_proxy_advertised_addresses

    Sets the server's RPC endpoints exposed to the external network through a TCP proxy.

  • --rpc_proxied_addresses

    Defines RPC endpoints in the internal network to handle RPC requests forwarded or proxied from external networks. It is possible to use a wild card for IP address (for example, and the port number (for example, 0) for the elements of this address list.

The --rpc_proxy_advertised_addresses flag is orthogonal to the --rpc_advertised_addresses flag, so it is possible to use both simultaneously. For example, it might be useful if the network environment for docker containers in the private internal network is configured in some special way that mandates using the RPC-advertised addresses instead of the real RPC addresses for Kudu servers.