[
https://issues.apache.org/jira/browse/HBASE-29762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18051276#comment-18051276
]
Balazs Meszaros commented on HBASE-29762:
-----------------------------------------
Hi [~zhangduo], sorry for the late reply. I was pretty inactive in the past
week.
{quote}It will be really difficult to maintain as we may add new methods in the
future. Consider this, maybe we should change the implementation of ServerName?
Where we have multiple hostname/port pairs?
{quote}
That's what I would like to avoid at all costs. If we change the implementation
of {{ServerName}} then we would have to pass the mapping everywhere where we
construct a new {{ServerName}} object. I think it is better to keep this
feature in a coprocessor.
{quote}We even have some methods in Admin interface where we pass a ServerName
from client to server, like getRegions, compact, etc, so here means we should
do the replacement in all these methods?
{quote}
Yes, but the replacement is done by the coprocessor, not by those methods. We
have several approaches here:
# Do not do anything: this is the easiest behavior, but the clients will
receive weird error messages when we cannot identify the server addresses at
server side.
# We throw an exception from the coprocessor: if we throw an exception from
the coprocessor saying "this method is not available for external kubernetes
clients" then the users can execute the requests with a client which is in
kubernetes.
# Do the replacement at coprocessor level. This requires the most work,
because:
## We have to modify our coprocessor interfaces, or
## We have to change the incoming request and outgoing response parameters.
These parameters can be immutable, so we have to modify those objects.
All of the steps are doable, however the costs of them are different. While
doing #1 or #2 is relatively easy, #3 is very difficult, because our
coprocessor interfaces were not designed to do that.
I collected the usage of {{ServerName}} objects in our RPCs:
* {{{}ClientMetaService.*{}}}: it can be done easily, because HBASE-29763 was
designed this way.
* {{{}MasterService.GetClusterStatus{}}}: it should be done.
* {{{}BootstrapNodeService.GetAllBootstrapNodes{}}}: it should be done
probably, but I don't know while we have a similar service to
{{{}ClientMetaService{}}}.
* Some other Master RPCs. I don't know if we should support these RPCs for
external clients.
** {{MasterService.MoveRegion}}
** {{MasterService.ListDecommissionedRegionServers}}
** {{MasterSerivce.DecommissionRegionServers}}
** {{MasterService.RecommissionRegionServer}}
** {{MasterService.ClearDeadServers}}
** {{MasterService.ClearDeadServers}}
* HBCK RPCs. I don't think we should support external clients for now:
** {{HbckService.ScheduleServerCrashProcedure}}
* Region server status RPCs. These are used by the HBase Servers, so no need
for external client support.
* {{{}AdminService.GetServerInfo{}}}: we should support it.
* Other Admin RPCs: I don't think we should support external clients for now:
** {{AdminService.OpenRegion}}
** {{AdminService.CloseRegion}}
** {{AdminService.UpdateFavoredNodes}}
* RS Group RPCs: these RPCs also use {{{}ServerName{}}}. I don't think we
should support them for now.
When I wrote "should support it" then I though we must support it in phase1
(HBASE-29766). For the other RPCs, we can throw an exception from the
coprocessor, so clients/users can move their workload to kubernetes in this
case. If we can agree with this scope, I think it is completely manageable in
phase1. If we want to support other RPCs as well, it might require bigger
coprocessor interface modifications, because the current interfaces do not give
full control to the coprocessor regarding request/response modification.
> 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)
