Checkpoint Lab — Containers, Kubernetes, Ephemeral Injectors, and Infrastructure Automation

1. Exact assumptions and load ceilings

2. Predictions before execution

P1 — portability: identical JMX + properties/data will produce 100 successful samples both natively and in Docker when only target/data path/injector properties are overridden.

P2 — network identity: native target host =127.0.0.1; Docker target host =p27-fixture. Using 127.0.0.1 in Docker will fail and produce zero fixture events.

P3 — persistence: deleting p27-jmeter after the run will not delete JTL/jmeter.log because /artifacts is a host bind mount.

P4 — resources: container inspect shows the declared CPU/memory/PID/read-only-root limits and exit 0/OOM false.

P5 — Kubernetes load math: two Indexed Job Pods each run 5×20=100, so configured total =200 and target should show two injector IDs with 100 each if executed.

3. Freeze provenance and inputs

1. Pull eclipse-temurin:17.0.20_8-jre-jammy and save RepoDigests.
2. Build custom JMeter image; SHA-512 verification must pass.
3. Save final JMeter image ID and docker history --no-trunc.
4. Run image jmeter -v and java -version.
5. Hash JMX/config/CSV and preserve the manifest.
6. Confirm no third-party plugin was added.

4. Execute and verify the Docker run

Use Lesson 2's exact p27-net, fixture and JMeter commands with run ID p27-check-docker. Change only:

-Jrun.id=p27-check-docker
-Jinjector.id=docker
-Jtarget.host=p27-fixture
-Jdata.file=/inputs/data/scenario.csv

Persist:

• results.jtl + matching jmeter.log from the host mount;
• target server-events.jsonl via docker cp before fixture removal;
• JMeter container inspect/mount/resource/exit-state output;
• image/input provenance files.

Verifier gate: 100 JTL +100 target events, zero failures, injector docker, exit=0, OOM=false.

5. Execute and verify the same JMX natively

Run the same JMX under native JMeter 5.6.3/Java 17 with run ID p27-check-native, injector=native, host=127.0.0.1 and the host absolute CSV path. Require 100/100 successes.

Compare:

Do not compare native versus Docker latency as a performance regression unless generator/network/resource environments are intentionally normalized and measured.

6. Optional local kind design: prepare inputs

The Kubernetes path is optional and local. Confirm context/name first:

kind version
kubectl config current-context

kind create cluster --name p27

kind load docker-image `
  devops-academy/jmeter:5.6.3-p27 `
  devops-academy/p27-fixture:1 `
  --name p27

kind documentation recommends avoiding latest for locally loaded images; the manifest uses imagePullPolicy: Never.

Create a ConfigMap from the same versioned inputs:

kubectl create configmap p27-inputs `
  --from-file=container-local.jmx=.\plans\container-local.jmx `
  --from-file=container.properties=.\config\container.properties `
  --from-file=scenario.csv=.\data\scenario.csv `
  --dry-run=client -o yaml `
  > .\k8s\p27-inputs.yaml

ConfigMap is suitable only for this tiny non-secret teaching input. Large/private data belongs in an explicitly versioned storage/image mechanism; credentials belong in Secrets/approved external secret systems.

7. Optional local fixture Deployment/Service

k8s/p27-fixture.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: p27-fixture
spec:
  replicas: 1
  selector:
    matchLabels:
      app: p27-fixture
  template:
    metadata:
      labels:
        app: p27-fixture
    spec:
      containers:
        - name: fixture
          image: devops-academy/p27-fixture:1
          imagePullPolicy: Never
          args: ["--host", "0.0.0.0", "--port", "8027", "--log", "/tmp/server-events.jsonl"]
          ports:
            - containerPort: 8027
          resources:
            requests:
              cpu: "50m"
              memory: "64Mi"
            limits:
              cpu: "250m"
              memory: "256Mi"
          volumeMounts:
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: tmp
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: p27-fixture
spec:
  selector:
    app: p27-fixture
  ports:
    - port: 8027
      targetPort: 8027

The Service is ClusterIP only—no Ingress/NodePort/LoadBalancer. Target stays inside the disposable cluster.

8. Optional Indexed Job with explicit 200-sample math

k8s/p27-job.yaml:

apiVersion: batch/v1
kind: Job
metadata:
  name: p27-jmeter
spec:
  completions: 2
  parallelism: 2
  completionMode: Indexed
  backoffLimit: 0
  activeDeadlineSeconds: 90
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: jmeter
          image: devops-academy/jmeter:5.6.3-p27
          imagePullPolicy: Never
          command: ["/bin/sh", "-ec"]
          args:
            - |
              exec /opt/jmeter/bin/jmeter \
                -n \
                -t /inputs/container-local.jmx \
                -q /inputs/container.properties \
                -Jtarget.host=p27-fixture \
                -Jtarget.port=8027 \
                -Jrun.id=p27-k8s \
                -Jinjector.id="k8s-${JOB_COMPLETION_INDEX}" \
                -Jdata.file=/inputs/scenario.csv \
                -l "/artifacts/results-${JOB_COMPLETION_INDEX}.jtl" \
                -j "/artifacts/jmeter-${JOB_COMPLETION_INDEX}.log"
          env:
            - name: HEAP
              value: "-Xms256m -Xmx512m -XX:MaxMetaspaceSize=128m"
            - name: JOB_COMPLETION_INDEX
              valueFrom:
                fieldRef:
                  fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index']
          resources:
            requests:
              cpu: "250m"
              memory: "384Mi"
            limits:
              cpu: "500m"
              memory: "768Mi"
          volumeMounts:
            - name: inputs
              mountPath: /inputs
              readOnly: true
            - name: artifacts
              mountPath: /artifacts
      volumes:
        - name: inputs
          configMap:
            name: p27-inputs
        - name: artifacts
          emptyDir: {}

Configured load:

2 completions × (5 threads × 20 loops × 1 Work sampler)
= 2 × 100
= 200 configured target samples

injector IDs:
  k8s-0 -> expected 100
  k8s-1 -> expected 100

backoffLimit: 0 avoids retrying a failed Pod in this teaching run. activeDeadlineSeconds: 90 bounds runtime. Resource limits are per Pod; aggregate requested/limited resources also double with parallelism.

9. Optional execution/inspection

kubectl apply -f .\k8s\p27-inputs.yaml
kubectl apply -f .\k8s\p27-fixture.yaml
kubectl rollout status deployment/p27-fixture --timeout=60s

kubectl apply -f .\k8s\p27-job.yaml
kubectl wait --for=condition=complete job/p27-jmeter --timeout=90s

kubectl get job p27-jmeter -o wide
kubectl get pods -l job-name=p27-jmeter -o wide
kubectl describe job p27-jmeter
kubectl top pod 2>$null

If a Pod fails or count exceeds 200, preserve state/logs and stop. Do not increase parallelism to “make it finish.”

10. Collect Pod artifacts before deleting the Job

The example uses emptyDir, so each Pod's artifacts persist only while that Pod exists. Collect them explicitly:

$pods = kubectl get pods -l job-name=p27-jmeter `
  -o jsonpath='{.items[*].metadata.name}'

New-Item -ItemType Directory -Force .\results\p27-k8s | Out-Null

foreach ($pod in $pods -split ' ') {
  New-Item -ItemType Directory -Force ".\results\p27-k8s\$pod" | Out-Null
  kubectl cp "$pod`:/artifacts/." ".\results\p27-k8s\$pod"
  kubectl logs $pod > ".\results\p27-k8s\$pod\container.log"
  kubectl get pod $pod -o yaml > ".\results\p27-k8s\$pod\pod.yaml"
}

kubectl get job p27-jmeter -o yaml `
  > .\results\p27-k8s\job.yaml

Do not set a short ttlSecondsAfterFinished until artifact automation can guarantee collection before deletion.

11. Kubernetes validity gate

If executed, require:

• two successful Indexed Pods, no retry/extra failed Pod;
• each JTL contains exactly 100 successful rows;
• injector IDs k8s-0/k8s-1 map to 100 samples each;
• fixture stats/events show exactly 200 total;
• no OOMKilled/deadline/resource-throttle evidence severe enough to invalidate achieved load;
• all JTL/logs collected before Pod/Job deletion.

12. Required evidence packet

13. Example validity statement

14. Cleanup / rollback

# Docker
docker rm p27-jmeter
docker rm -f p27-fixture 2>$null
docker network rm p27-net

# Optional Kubernetes after artifact collection
kubectl delete -f .\k8s\p27-job.yaml --ignore-not-found
kubectl delete -f .\k8s\p27-fixture.yaml --ignore-not-found
kubectl delete -f .\k8s\p27-inputs.yaml --ignore-not-found
kind delete cluster --name p27

Keep image/input manifests and run artifacts until review. Image deletion is optional; if retained, its ID becomes part of provenance. No production/public target, cloud resource, real secret, host firewall/OS tuning or remote RMI system was changed.

15. What Chapter 27 adds to the operating model

The production performance-testing operating model now has an ephemeral injector infrastructure contract: image/base provenance and integrity verification, plugin/runtime versions, immutable mounted inputs, container/Pod network target identity, CPU/memory/PID/JVM limits, non-root/filesystem permissions, secret injection boundary, container/Job count and retry load math, persistent JTL/log/telemetry path, exit/OOM/restart state, configured-versus-achieved target counts and cleanup are required before ephemeral infrastructure is considered reproducible.

Chapter 28 moves to CI/CD Performance Gates in GitHub Actions, GitLab CI, and Jenkins. It takes this reproducible injector contract into automated pipelines where runner identity, caches, secrets, service startup, artifacts, thresholds, exit codes and flaky-environment policy determine whether a performance gate is trustworthy.

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.