GCP Scenario

Distributed k6 Load Testing on GKE

k6-operator runs distributed load tests on GKE; results stream to BigQuery; Cloud Trace pinpoints latency hotspots.

Architecture

Cloud Build ─► k6 script + ConfigMap ─► kubectl apply
                                  │
       k6-operator ─► spawns 50 runner pods on GKE
                                  │
       runners hit target service ──► Cloud Trace + Monitoring
                                  │
       k6 → InfluxDB sidecar → Pub/Sub → BigQuery
                                  │
       Looker Studio dashboard (RPS, p95, error rate, traceId hotspots)

Services used

Google Kubernetes Engine Cloud Build Cloud Storage BigQuery Cloud Trace Cloud Monitoring Pub/Sub

Steps

1. Define test
Author k6 script; package script + thresholds in a ConfigMap consumed by k6-operator.
2. Schedule load
`kubectl apply -f testrun.yaml` provisions 50 runner pods across GKE node pool.
3. Correlate
k6 injects `traceparent` so backend OpenTelemetry spans link directly to load-test iterations in Cloud Trace.
4. Stream metrics
k6 → InfluxDB sidecar → Pub/Sub → BigQuery for long-term trend analysis.
5. Gate
Cloud Build job reads BigQuery; fails release if p95 regressed > 20% vs baseline.

Takeaways

k6-operator scales generators horizontally without bespoke orchestration.
Linking load test iterations to traces collapses MTTR for perf bugs.
Historical results in BigQuery turn perf testing into trend analysis.