What problem does it solve? Kafka load tests often produce indefensible numbers because teams conflate broker bottlenecks with application bottlenecks, run tests from laptops with network skew, or leave sizing knobs unfixed. This Skill codifies a paired-tool methodology that produces reproducible results and names exactly which resource saturated first. ## Core Features & Use Cases - Paired-tool methodology: Run a one-time broker baseline with kafka-producer-perf-test.sh / kafka-consumer-perf-test.sh whenever broker shape changes, then run headline application-pipeline tests with k6 + xk6-kafka (v2 API: Producer, Consumer, AdminClient, SchemaRegistry). - Correct k6 lifecycle and CI integration: Create topics in setup() with a fresh AdminClient plus sleep(2) instead of the racy if (VU == 0) pattern, and bind k6 thresholds to kafka_writer* / kafka_reader* metrics so runs become pass/fail CI artifacts. - In-cluster execution and observability: Run k6 as a Kubernetes Job in a dedicated namespace like testing-system, watch the four-quadrant dashboard (producer, broker, consumer, app), stop on the first SLO breach, and clean up topics, offsets, and synthetic rows after every run. - Use Case: After changing a Strimzi KafkaNodePool, establish the new broker ceiling with perf-test.sh, then run a ramping-arrival-rate xk6-kafka Job against your service's inbound adapter to verify the pipeline meets its p99 latency SLO. ## Quick Start Ask the AI to write a k6 xk6-kafka load test script with ramping-arrival-rate, setup()-based topic creation, and kafka_writer thresholds, packaged as a Kubernetes Job in testing-system.