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.