Currently (Pulsar 2.4.1), there is the possibility to use the Proxy component to hardcode alternate Broker URLs to be then used in discovery and sent back to clients which cannot use the primary Broker URLs (e.g. when these are Kubernetes Cluster IP type).
However this has the following drawbacks:
- only one alternate type is supported, e.g. I have to choose whether I support my AWS-internal or my AWS-external clients, but I cannot support both with the same Proxy
- there's no autodiscovery and the user has to manually manage this
- one whole component (the Proxy) is necessary to support this, this could be removed
The solution could go along these lines:
- when connecting to a Pulsar Broker (i.e.
pulsar://), user should be able to set a "context" (or the type of my origin) e.g. "external", "internal", "tunnel", etc. (perhaps via pulsar@context-name:// ? or via the client API). This context info is sent to the Broker with the initial request.
- the Broker has multiple context lookup "providers" defined, i.e.:
- hardcoded URL provider (comes from the config; currently provided by the Proxy component)
- discovered URL provider; e.g. AWS k8s Pulsar culster will provide 3 URLs:
-
- Cluster IP:port from within Kubernetes
-
- AWS internal (private) node IP:port (if the k8s NodePort service for Broker is defined)
-
- AWS external (public) node IP:port (if the k8s NodePort service for Broker is defined)
- when a redirection to another Broker is necessary, the Broker matches the client-provided context with a defined provider (by name, e.g. "aws-external"), and returns the correct other-Broker's URL for the client to (correctly) redirect to.
Currently (Pulsar 2.4.1), there is the possibility to use the Proxy component to hardcode alternate Broker URLs to be then used in discovery and sent back to clients which cannot use the primary Broker URLs (e.g. when these are Kubernetes Cluster IP type).
However this has the following drawbacks:
The solution could go along these lines:
pulsar://), user should be able to set a "context" (or the type of my origin) e.g. "external", "internal", "tunnel", etc. (perhaps viapulsar@context-name://? or via the client API). This context info is sent to the Broker with the initial request.