[
https://issues.apache.org/jira/browse/HBASE-29762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18051433#comment-18051433
]
Duo Zhang commented on HBASE-29762:
-----------------------------------
I do not think this is workable solution...
As you listed above, we already have bunch of RPC methods which take ServerName
as a parameter, and in the future the number could increase/decrease, it will
be really hard to developers to remember we also need to change a coprocessor
implementation, and then the feature will be broken.
And even more, we have lots of other places where we pass a ServerName, like in
metrics, may be even returned from http request, from jmx... These things are
not covered by coprocessor, so the proposal here does not help, but you can not
stop the operators implement op-tools based on metrics right?
So I strongly disagree that we go with this direction. As I said above, there
are bunch of ways to solve the K8s network problems, if we do not have a clean
solution, we should not implement it in HBase, as users also have bunch of ways
to fix the problem by themselves...
Thanks.
> 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)
