JenkinsRuleNonLocalhost was not a great idea to begin with. https://github.com/jenkinsci/kubernetes-plugin/pull/1567#pullrequestreview-2090682601 has some related discussion, but briefly: the problem is that K8s agents are inbound (JNLPLauncher, whether TCP or WebSocket) and when the controller runs outside the cluster they would not be able to access it easily because they are not both on localhost, and the host IP is not readily accessible. CI tests do not have quite the same issue because they run mvn test inside the cluster so there is a well-defined host name, but it is still not on loopback. I think this does not matter for the TCP port, but the current hack is to expose the Jenkins HTTP port to all network interfaces, which is not supported in JTH pending https://github.com/jenkinsci/jenkins-test-harness/pull/289#issuecomment-809560892 (since it is so easy to expose yourself to a serious vulnerability unless you take care to ensure that every single test enables security with a strong random password). And so the plugin’s fork of JenkinsRule is awkward to maintain.
It would be safer and more robust to use ktunnel or some similar system to set up a reverse proxy for both ports that allows agent pods running inside the cluster to contact the controller, without exposing the controller’s HTTP port to outside traffic. Ideally this would also be available for hpi:run but at worst you can just add a Thread.sleep to some test, wait for it to pause, and then experiment interactively.
Task
Major
Basil Crow
created issue -
Basil Crow
made changes -
JenkinsRuleNonLocalhost was not a great idea to begin with. https://github.com/jenkinsci/kubernetes-plugin/pull/1567#pullrequestreview-2090682601 has some related discussion, but briefly: the problem is that K8s agents are inbound (JNLPLauncher, whether TCP or WebSocket) and when the controller runs outside the cluster they would not be able to access it easily because they are not both on localhost, and the host IP is not readily accessible. CI tests do not have quite the same issue because they run mvn test inside the cluster so there is a well-defined host name, but it is still not on loopback. I think this does not matter for the TCP port, but the current hack is to expose the Jenkins HTTP port to all network interfaces, which is not supported in JTH pending https://github.com/jenkinsci/jenkins-test-harness/pull/289#issuecomment-809560892 (since it is so easy to expose yourself to a serious vulnerability unless you take care to ensure that every single test enables security with a strong random password). And so the plugin’s fork of JenkinsRule is awkward to maintain.
It would be safer and more robust to use ktunnel or some similar system to set up a reverse proxy for both ports that allows agent pods running inside the cluster to contact the controller, without exposing the controller’s HTTP port to outside traffic. Ideally this would also be available for hpi:run but at worst you can just add a Thread.sleep to some test, wait for it to pause, and then experiment interactively.