Hi Andrew, I believe that we handle this issue by wrapping the UIs in a rewriting proxy. We have to do the same for the DataNodes. It would be nice to have native support for this kind of thing, but I'm not familiar with whatever guidance the Kubernetes community provides. Your approach does seem like the logical choice, but I also agree it feels heavy-handed. Hopefully someone else can chime in with their experiences.
Your proposal reminds me vaguely of the config `hbase.unsafe.regionserver.hostname` and HBASE-12954. As I understand it, that mechanism monkeys with the hostname used in the RPC layer. Maybe it makes sense to also use it for the web UIs? Or maybe not, because routing internal RPC requests through the external-facing network stack is wasteful. Thanks, Nick On Thu, Apr 24, 2025 at 3:42 PM Andrew Kenworthy <andrew.kenwor...@stackable.tech.invalid> wrote: > > Hi, > > I am running HBase clusters on Kubernetes and have been looking at how to > patch the code (version 2.6.1) so that the links on the master and > regionserver UIs are resolvable. My approach involves extending the > ServerName struct to include two new fields (e.g. externalHostname and > externalPort), which are filled with e.g. the node IP and externally > resolvable port, prepared by my operator and stored in custom config > settings. This means that I can use this information whenever a ServerName > object is retrieved for the active master, and I have patched the relevant > jsp pages to use this information instead of the internal name. However, it > is a) fairly invasive, and b) not a complete solution, as at some points in > the code (e.g. the regionServers collection in RegionServerTracker) only > the hostname of the struct is used and not the whole struct (so additional > fields are not available). I'm aware that things will change as of 4.0.0 > anyway, when some of the meta data will be stored in an HBase table instead > of ZooKeeper. Has anyone else started thinking about or working on this? Is > there a work-in-progress that we could support upstream? > > Andrew
