We do something similar in our k8s deployments for discovery. I think the ask for a restful/http client comes from users’ understanding that the http protocol is universally well supported by any and all k8s ecosystem component you may want in your system architecture, and some other binary protocol running on some random ports is harder to deal with. Never mind that our current rest gateway can only ever provide poor performance relative to either our Java or thrift clients. It is a suboptimal concession to laziness (excuse me.. “developer experience”). That said, http/https being first class above all in protocol support of, well, everything, is true. If we do want to properly provide http/https protocol support then we must really build it based on http v2, which I believe did not exist as a standard when our current rest gateway was implemented. It’s a relic.
> On Jun 13, 2024, at 6:19 AM, Bryan Beaudreault <bbeaudrea...@apache.org> > wrote: > > We deploy kube-proxy on all of our non-kube ec2 nodes. So any client can > still use the Services we've defined to talk to the pods. Our HMaster(s) is > a Deployment with a Service; our NameNode(s) is a StatefulSet, and we have > a dedicated service per namenode identifier; etc. > > In our hbase-site.xml, we set the bootstrap nodes to the HMaster Service. > In our hdfs-site.xml we configure each namenode to point at the specific > namenode service. > > This all works well for us, even with a mixed topology. But yea, that seems > less about what protocol (http vs protobuf) and more about discovery. > >> On Thu, Jun 13, 2024 at 9:08 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: >> >> 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 >>>> >>
