Distributed Testing: Kubernetes & k6-operator — Belajar k6

Kapan Anda Butuh Distributed Testing

Satu mesin modern (8 vCPU, 16 GB) umumnya sanggup 3.000–10.000 VU HTTP sederhana. Anda perlu menyebar beban bila:

CPU generator konsisten > 75% saat tes berjalan.
Muncul dropped_iterations yang tidak hilang meski preAllocatedVUs dinaikkan.
Bandwidth NIC mesin generator sudah jenuh.
Anda perlu menghasilkan beban dari beberapa region geografis sekaligus.

⚠️ Periksa dulu sebelum menambah mesin

Sebagian besar kasus "butuh distributed" sebenarnya adalah skrip yang boros. Coba dulu: aktifkan discardResponseBodies, hapus console.log per-iterasi, ganti array biasa dengan SharedArray, dan kurangi kompleksitas parsing JSON. Sering kali kapasitas naik 3–5× tanpa mesin tambahan.

k6-operator di Kubernetes

terminalbash

# Pasang operator
kubectl apply -f https://github.com/grafana/k6-operator/releases/latest/download/bundle.yaml

# Simpan skrip sebagai ConfigMap
kubectl create configmap skrip-uji --from-file=load.js

# Jalankan TestRun
kubectl apply -f testrun.yaml
kubectl get testrun
kubectl logs -l k6_cr=uji-checkout -f

testrun.yamlyaml

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: uji-checkout
spec:
  # Beban dipecah ke 8 pod. Bila skrip meminta 800 VU,
  # tiap pod menjalankan 100 VU.
  parallelism: 8

  script:
    configMap:
      name: skrip-uji
      file: load.js

  arguments: --out experimental-prometheus-rw --tag testid=checkout-421

  runner:
    image: grafana/k6:1.0.0
    resources:
      requests: { cpu: "1",  memory: "1Gi" }
      limits:   { cpu: "2",  memory: "2Gi" }
    env:
      - name: BASE_URL
        value: https://staging.contoh.id
      - name: TEST_PASSWORD
        valueFrom:
          secretKeyRef: { name: rahasia-uji, key: password }

Bagaimana Beban Dipecah

k6-operator membagi beban dengan execution segment. Dengan parallelism: 4 dan skrip vus: 400, tiap pod menjalankan segmen 0–25%, 25–50%, dan seterusnya — masing-masing 100 VU.

⛔ Threshold pada tes terdistribusi bisa menyesatkan

Setiap pod menghitung threshold-nya sendiri berdasarkan porsi bebannya saja. Threshold seperti http_reqs: ['count>10000'] akan gagal di setiap pod padahal totalnya terpenuhi.

Yang benar: pakai threshold berbasis rate dan persentil (yang tetap bermakna per-segmen), lalu lakukan evaluasi total di sisi Prometheus/Grafana setelah semua data terkumpul.

Hal yang Berubah Saat Tes Menjadi Terdistribusi

Aspek	Satu mesin	Terdistribusi
Data uji	Satu `SharedArray`	Tiap pod punya salinan — risiko akun bertabrakan
`setup()`	Jalan 1×	Dikoordinasi operator, tapi pastikan idempoten
Threshold	Global	Per-segmen — perlu agregasi eksternal
Ringkasan	Satu output	Terpecah per pod — gabungkan lewat Prometheus
IP sumber	Satu	Banyak — bagus untuk menghindari rate limit per-IP

Alternatif: Grafana Cloud k6

Bila Anda tidak ingin mengelola infrastruktur generator sendiri, k6 cloud run skrip.js menjalankan tes dari infrastruktur Grafana di berbagai region dunia, lengkap dengan dashboard analisis. Berbayar, tetapi menghilangkan seluruh beban operasional dan memberi perspektif latensi geografis yang sulit ditiru sendiri.