Containers, Kubernetes, Ephemeral Injectors, and Infrastructure Automation: Core Concepts and Mental Model

1. The practical problem: “works in my shell” is not an injector specification

A workstation has JMeter 5.6.3, one developer plugin, an untracked Java update, a CSV beside the JMX and a writable home directory. The same test is started in CI from an image called jmeter:latest. It cannot find the CSV, writes JTL into the container layer, has half the CPU quota and resolves localhost to itself rather than the target. Containerization did not create reproducibility because the important state was never specified.

2. Mental model: package, runtime, execution and evidence are separate

flowchart TD
A[Pinned Java base + verified JMeter binary + optional plugins] --> I[Injector image]
J[JMX + properties + synthetic data] --> M[Read-only mounted inputs]
I --> C[Ephemeral container / Job Pod]
M --> C
Q[CPU / memory / PID / filesystem / network limits] --> C
C --> E[JMeter CLI engine]
E --> H[HTTP protocol/session]
H --> T[Private target service]
E --> R[JTL + jmeter.log]
E --> X[Process exit status]
R --> P[Persistent host volume / collected artifact]
X --> P
T --> S[Target telemetry/events]
S --> P
K[Container/Kubernetes lifecycle] --> C

The image packages Java/JMeter binaries and any deliberately baked plugins. Versioned JMX/data/config are separate inputs mounted into the running injector. Docker/Kubernetes creates an ephemeral process environment with CPU/memory/filesystem/network constraints. JMeter still creates the same Thread Groups and protocol sessions as outside a container. The target sees traffic from the container/pod network. JTL/jmeter.log and exit state must leave the ephemeral filesystem before cleanup. Deleting a container/Pod is an infrastructure lifecycle event; it does not redefine what a JMeter thread, loop or sample means.

3. New infrastructure terms

4. Apache JMeter distribution versus a container image

Apache publishes JMeter binaries and integrity material. The mandatory path builds a custom container from that verified Apache tarball; it does not claim any community JMeter image is maintained by Apache. The Java base is the Docker Official Image for Eclipse Temurin at a version-specific Java 17.0.20+8 tag. Record its resolved digest before building.

The resulting local JMeter image has two provenance anchors: the base image's resolved registry digest and the Apache JMeter tarball's published SHA-512.

5. Container lifetime is not thread lifetime

One container can run one JMeter process containing 5 threads; two Kubernetes Pods each running that plan configure 10 total threads, not five. A Job retry can run the program again and create additional target work. Therefore:

• container count/Job parallelism belongs in configured-load math;
• JMeter Thread Group threads/loops still belong inside each process;
• orchestrator retries/deadlines/evictions belong in infrastructure validity;
• target counts and per-injector labels prove achieved work.

6. Mount JMX/data/config read-only

Docker bind mounts are read-write by default, so use the readonly/ro option for plans/data/config. This prevents a compromised/mistaken sampler/script from modifying the source assets through the container. Artifacts get a separate write mount.

7. Ephemeral filesystems and evidence

If JMeter writes /work/results.jtl only inside the container, deleting the container can delete the experiment. The required pattern is:

• inputs: immutable/read-only;
• /tmp: disposable scratch;
• /artifacts: host bind mount/PVC/explicit artifact collection;
• JTL and matching jmeter.log: always outside the ephemeral layer before cleanup;
• target events/telemetry and container exit state: retained with the run manifest.

8. Container localhost is not host/sibling localhost

Inside the JMeter container, 127.0.0.1 points to the JMeter container itself. A sibling fixture is reached by its service/container name on the private network, e.g. p27-fixture:8027. Kubernetes uses Service/DNS names similarly. This is namespace semantics, not a JMeter DNS bug.

9. Resource limits are part of generator sizing

Chapter 26 measured usable generator capacity. A Docker --cpus/--memory or Kubernetes CPU/memory limit can move that capacity ceiling even when the physical host is idle. Record the container limit and keep Java heap below the memory limit with enough native/metaspace/thread/socket headroom.

10. State checklist before an ephemeral run

11. Read-only inspection first

PowerShell / portable Docker commands:

docker version
docker info --format "{{json .SecurityOptions}}"

docker pull eclipse-temurin:17.0.20_8-jre-jammy
docker image inspect eclipse-temurin:17.0.20_8-jre-jammy `
  --format "{{json .RepoDigests}}"

docker image ls --digests
docker network ls
docker ps -a

kind version
kubectl version --client
kubectl config current-context

If the current Kubernetes context is not the disposable local cluster you intended, stop. Do not apply a teaching Job to a shared/production cluster.

12. DevOps connection

Ephemeral injectors improve repeatability only when the artifact has a supply chain and the runtime has a contract. Image provenance, immutable inputs, network target identity, resource quotas, secrets, exit status and evidence retention are as important as the JMX itself.

Knowledge check

Official references and version notes

• Apache JMeter downloads — JMeter 5.6.3, Java requirement, SHA-512/PGP integrity verification.
• Apache-published JMeter 5.6.3 SHA-512 — checksum used by the lab Dockerfile.
• Eclipse Temurin Docker Official Image — version-specific Java 17.0.20+8 JRE base used by the custom injector image.
• Docker bind mounts — read-only input mounts and writable host artifact mounts.
• Docker run reference — read-only root filesystem, CPU/memory limits, mounts, networks and exit-state inspection.
• Kubernetes Jobs — run-to-completion semantics, parallelism/completions, restartPolicy, backoff and active deadlines.
• kind Quick Start — local cluster lifecycle and loading locally built images.