Replies: 4 comments 4 replies
-
I don't know JMX much. If you would want to expose it to outside your cluster, you will probably need to create some load balancer, node port or similar services for it to expose it. Strimzi does not expose it to the outside on its own and IMHO the JMX security is relatively weak so I would not do it. |
Beta Was this translation helpful? Give feedback.
-
This would also help troubleshoot JVM further deeply with JMX RMI tools. Currently default behaviour for strimzi to set java.rmi.server.hostname JMX configuration to Pod's IP address, which makes impossible to connect JMX RMI interface from outside world (behind NAT or Port-Forwarded proxy like kubectl) If this is intended (to be only routable within the kubernetes network) then jmxOptions should expose a configuration for those who want change this behaviour enabling us to start a troubleshooting session. If it does not advertise Pod IP or advertise 127.0.0.1 or localhost then this would not be a problem. -javaagent would not be affected since it is also another local process. |
Beta Was this translation helpful? Give feedback.
-
Putting it behind a Loadbalancer would not work because once initial connection is made, RMI advertise the IP address of the Pod, unless modified by the loadbalancer (I could not able to find a way to do it other than https://github.com/marcin-wolak/SimpleRmiDiscoverer?tab=readme-ov-file#simplermidiscoverer) client would try to connect that IP. |
Beta Was this translation helpful? Give feedback.
-
Correct, but not because it is ephemeral, Strimzi explicitly set RMI port to as same as JMX > 9999, it is not ephemeral. |
Beta Was this translation helpful? Give feedback.
-
Hi,
When setting
jmxOptions: {}
it exposes JMX metrics (on port 9999) which are accessible only from other pods but not from outside k8s (due to ephemeral rmi port...) - Is that correct?Beta Was this translation helpful? Give feedback.
All reactions