[
https://issues.apache.org/jira/browse/HBASE-29762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18045775#comment-18045775
]
Balazs Meszaros commented on HBASE-29762:
-----------------------------------------
{quote}The client will scan hbase:meta to find the location of a region, and
there is only one server name in the meta record. I do not think a coprocessor
based solution can solve this problem? We need to do some translating at client
side? Or maybe we should add new qualifiers in hbase:meta to support multiple
addresses for a single region server?
{quote}
Why? Client scans {{hbase:meta}} table and the coprocessor replaces
{{info:server}} and {{info:sn}} columns to the external addresses. Again, this
replacement will only take place when the client asks to do it, based on a
client connection header (HBASE-29765). So the client won't know the internal
address, it will see only the external.
It is completely doable, because co-processors can change get/scan results.
There are other RPCs which are more problematic, but they are not in the
current scope:
* {{getClusterMetrics}} (RPC behind {{status}} shell command): the coprocessor
interface was not designed to change the response and the fields are immutable.
* Any other RPCs where we pass {{ServerName}} object between the client and
server side.
> Support external client connection to kubernetized HBase cluster
> ----------------------------------------------------------------
>
> Key: HBASE-29762
> URL: https://issues.apache.org/jira/browse/HBASE-29762
> Project: HBase
> Issue Type: New Feature
> Reporter: Balazs Meszaros
> Assignee: Balazs Meszaros
> Priority: Major
>
> When HBase is deployed to kubernetes, kubernetes assigns its own hostnames to
> HBase pods. It works fine while the clients are in the same kubernetes
> environment, but can be an issue if they are coming from outside the
> kubernetes environment. Kubernetes offers several methods for exposing
> services like Istio, Load Balancers, ... Any method can be used, but these
> methods share one thing: the external addresses are different from the
> internal addresses.
> The goal is to support external HBase client connection to kubernetized HBase
> clusters. The idea is to implement a co-processor which translates the
> internal addresses to external addresses. This translation is optional based
> on a client connection header (which is coming from a configuration property).
> This task sums up these efforts:
> * [HBASE-29763] Implement co-processor host for client-meta (Zookeeper-less
> HBase discovery) service.
> * [HBASE-29764] Make client connection header attributes accessible inside
> co-processors.
> * [HBASE-29765] Make client connection header attributes configurable.
> * [HBASE-29766] Implement a co-processor which intercepts client-meta calls,
> {{hbase:meta}} table gets/scans and replaces internal addresses with external
> addresses.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
