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 > > > >
