| Sometimes, it is not always possible to put everything inside the same Kubernetes pod - or inside a container at all. Any of the following reasons can make it troublesome:
- Already existing tooling.
- Licensing that is not adapted to containerization or that outright does not allow containerization.
- Operating systems that cannot be containerized (i.e. macOS).
- Purchased and packaged solutions.
- Legacy systems that are either infeasible to port or too expensive to make it viable.
I am sure that there are even more reasons. A concrete example is to use Selenium from a Windows-based agent that does not reside within the Kubernetes cluster to execute tests on a server that is deployed to Kubernetes using the plugin.
How would the non-container Selenium instance know where a website is hosted within the Kubernetes pod? Thus, there is a use case for interfacing with Kubernetes containers/pods from outside the pod, in which case other containers can no longer be interacted with using `localhost`.
In order to use the Kubernetes plugin with other external (i.e. outside of the pod) Jenkins agents there must be a way of addressing the specific pod through either an IP-address or some "magic" DNS-alias. Preferably, this should work within a declarative pipeline as a scripted pipeline could read the IP from the containers using an sh command and store it in a variable for future use. |
