[
https://issues.apache.org/jira/browse/HBASE-29762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18051783#comment-18051783
]
Balazs Meszaros commented on HBASE-29762:
-----------------------------------------
bq. 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?
Not necessarily. If they run their workload on kubernetes then they have no
issues, they don't have to do any workaround.
bq. 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.
There are several ways to publish an HBase cluster on kubernetes. If you have N
servers, then with N number of load balancers you can publish the HBase service
and the hosts/DNS hack might be enough. However there are some problems with
this approach:
# All of the N region server accepts connection on port 16020, you must assign
N "public" IP addresses to the cluster.
# There are several other options to publish an HBase cluster. You can use
Istio, you can use NodePort services, etc. In these cases hosts/DNS
modification is not enough, because these methods do not guarantee that the
port number remains 16020 for every RS.
# Kubernetes is a dynamic environment, so if you resize the cluster, you might
have to change hosts/DNS. If you use your own hosts file, then you have to copy
it to several places after the modification. I don't think it is a good idea to
keep this at the client side.
bq. 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.
In my PoC, I used a mapping file at the *server side*. It is a simple property
file with INTERNAL->EXTERNAL address mapping. The client passes a boolean flag
only if they need the internal or the external addresses. I tried to figure it
out automatically, but there are multiple kubernetes networking topologies
where the source address is not the real client address.
> 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)
