[
https://issues.apache.org/jira/browse/HBASE-29762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18051466#comment-18051466
]
Balazs Meszaros commented on HBASE-29762:
-----------------------------------------
{quote}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.
{quote}
It is the same for every other coprocessor, like AccessController for example.
Users also can have their own coprocessors which can be broken sometimes by us
if we change our coprocessor interfaces.
{quote}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
{quote}
This initiative covers our RPCs, not the HTTP/JMX interface.
{quote}so the proposal here does not help, but you can not stop the operators
implement op-tools based on metrics right?
{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}As I said above, there are bunch of ways to solve the K8s network
problems
{quote}
What are those ways? I wrote 3 approaches above, but two of them do not work
out of the box with HBase.
{quote}And seems the solution here is to let client pass some configurations to
server side and then do the translation at the server side, will it increase
the security risks?
{quote}
Why? There are two things:
# It is not possible to override any existing ConnectionHeader attribute. So
if we set up a client to use codec for example, that setting cannot be
overwritten.
# We pass only {{hbase.client.header}} prefixed configuration parameters while
{*}keeping the prefix{*}. It means two things:
## Other configuration parameters like {{hbase.zookeeper.quorum}} is not
passed.
## If we pass something, it will have the {{hbase.client.header}} prefix in
the name. We do not have any headers/configuration entries with this prefix, so
clients cannot change any existing behavior.
> 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)
