At the time of writing, the container that performs the JNDI connection to the Jenkins master and the default build container are the same. To customize a build container, I can currently pick from multiple non-ideal solutions:

(1) Overwrite the container named `jndi` with a custom container. This is bad because it requires me to put Java and the JNLP client into that container image, e.g. if I need another Java version for my builds than the one required by Jenkins. And it makes the images unnecessarily big.

(2) Surround my build steps with a `container` block. This is bad because the pipeline code would be coupled to the container structure.

I'd rather prefer a third solution where the pipeline doesn't need to know anything about whether it runs in pods:

• The JNLP container should run nothing but the JNLP slave. By doing this, we can make the underlying image as small as possible – it can even just be a distroless image with nothing but the JNLP slave.
• There should be a default build container that runs as a sidecar. It's name should be something like `build` or configurable via "Configure Jenkins". The pipeline code itself should not know about the container hierarchy. The build container doesn't need to contain the JNLP slave.
• Thus, an agent pod would contain at least two pods, `jnlp` and `build`.