[
https://issues.apache.org/jira/browse/HBASE-29762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18053045#comment-18053045
]
Balazs Meszaros commented on HBASE-29762:
-----------------------------------------
{quote}I think we could just put it at client side and do the replacement at
client side?
{quote}
It is probably feasible, I did not dig into the client code that much regarding
this.
I have some concerns about doing it at the client side:
# There can be multiple client hosts, but only one server. So from
administration perspective, it is easier to do at the server side, because the
update can be done with only one modification, no need to distribute it to
every client host.
# HBase cluster size can be changed as new pods added/removed. This
information is available for HBase master or any Kubernetes operator which
listens HBase pod changes. So within kubernetes, it is possible to create an
automatism which regenerates the mapping on-the-fly. HBase servers can reload
the new mapping automatically, too. This dynamic reconfiguration can be done
within kubernetes, but it is complicated to do at the client side.
This is also crucial how we go forward. I agree with you, it is more
complicated to do at the server side. However looking the big picture, I see
more potential doing it on server side as I described above.
> 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)
