I guess the problem is that, in some k8s setup, inside the deployment, you can use the pod ips to connect to each other, that's the case for communicating insde HBase cluster, like regionServerReport, etc.
But outside the deployment, you can only access these services/pods through ingress, no matter L7 or L4, you need to use a different identifier. In our current design, there is no something like 'advertised address' for all the masters and region servers in the cluster, so there is no way for clients to use different identifiers when connecting the HBase cluster. But I think for java based client, we'd better try another way to support the native protocol, for better performance. Thanks. Bryan Beaudreault <bbeaudrea...@apache.org> 于2024年6月13日周四 19:38写道： > > Can you speak more to why HTTP would help users? > > We’ve been running hbase in 100% cloud environment for more than a decade. > We’ve never really desired an http version of the protocol. > > We also run more recently in a mixed kubernetes environment (master nodes > in kubernetes, regionserver on dedicated ec2 nodes). In this model we’ve > similarly had no real desire for http when working with services, etc. > > One case where it’s been useful to have http endpoint is readiness checks. > We’ve built a /health endpoint into the hmaster and regionserver to that > end, which I plan to upstream at some point. > > To me creating a totally compatible http based protocol seems like a huge > lift. So I’m curious what it’d really help for these cloud users. > > On Thu, Jun 13, 2024 at 1:07 AM Ankit Singhal <ankitsingha...@gmail.com> > wrote: > > > Hello, > > > > *Context for discussion*: > > > > These classes were recently relocated from "src/main" to "src/test" under > > HBASE-24115, aligning with the original contributor's initial intention of > > using them only for testing. Therefore, I'm raising this in an email to > > initiate discussion with the updated information. > > > > At Cloudera, we've noticed a growing adoption of HBase in cloud > > environments. This shift has highlighted concerns regarding network > > connectivity requirements between clients and HBase regionservers, > > particularly for remote clients. To address these concerns, we are looking > > to utilize standard web protocols such as HTTP. These protocols enable > > easier integration with various cloud services by providing a single > > endpoint for access and simplifying networking needs. As a result, more > > users are interested in using REST servers to meet their requirements. > > Istvan has put considerable effort into testing and improving the > > performance of REST servers, as seen in JIRAs like HBASE-28646, > > HBASE-28613, HBASE-28626, and HBASE-28556 to achieve this target. > > > > *Issue*: > > > > However, Users with applications currently using the Java client are > > encountering challenges in transitioning to REST due to the significant > > code rewriting required. By implementing the Admin and Table interfaces, we > > can enable these users to migrate to REST with minimal adjustments. > > > > *Other Protocol Implementations with Java Public APIs: * > > Similar interfaces have recently been developed for Thrift under > > HBASE-21661. > > > > *Proposed Changes:* Currently, Istvan focuses on addressing the performance > > and security aspects of these implementations, with efforts like > > HBASE-28540 and rewriting Rest Client to support different authentication > > options, etc. via HBASE-28501,HBASE-28649, and HBASE-28500, which > > significantly strengthened the implementation. Hence, we want to go ahead > > and move this implementation back to "src/main". > > > > Please inform us of any concerns you may have, otherwise, we would like to > > proceed with the PR. > > > > > > Regards, > > > > Ankit Singhal > >
