[
https://issues.apache.org/jira/browse/HBASE-29762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18051552#comment-18051552
]
Duo Zhang commented on HBASE-29762:
-----------------------------------
{quote}
Why do I stop our operators to implement their own tools? They previously had
and still have the opportunity to implement their own tools. If they run HBase
on kubernetes, then they already have the limitation to run the workloads
within kubernetes. This feature does not break any existing behavior if the
workloads are run within the cluster, but gives the opportunity to run external
workloads without any "networking hack". This change can be the first step
forward integrating HBase service to existing (and de-facto standard)
kubernetes services like Istio.
{quote}
If the operators could implement the their op-tools without the solution here,
it means they have a workaround to solve the network problem right? What I mean
is that, your solution can not solve the op-tools problem if they want to use
the region server's address from the metrics record. FWIW, you said it solve
the problem but users find out it can not, this is what I mean, not a clean
solution.
{quote}
What are those ways? I wrote 3 approaches above, but two of them do not work
out of the box with HBase.
{quote}
Just add some entries in /etc/hosts to resolve the internal addresses to
external ips at client side? Not everything needs to be done inside HBase,
especially this is an environment problem for deploying HBase on K8s, not a
problem for HBase itself...
And about the security risks, you need to read the configurations at server
side and do some replacements right? I'm not sure how we plan to replace it,
for example, if we use regex, a malicious client will be easier to just pass
some malformed replace pattern to make DOS attack. This is just one thing, we
need to be careful here...
> 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)
