Run Gateway Benchmark

Overview

This skill drives the benchmark harness in scripts/ to measure Flex Gateway throughput, latency, and resource use under configurable API counts and policies. It provisions a dedicated EKS cluster, deploys Flex + an upstream echo service, runs a k6 TestRun, exports Grafana dashboards as PNGs, and emits a self-contained Markdown report per run.

Detailed architecture, dashboards, idempotency design, and design rationale are documented in references/ARCHITECTURE.md. Read it before extending the harness; this skill assumes it as background.

flowchart TD
    Start{What do you want to do?}

    Start -->|First-time setup| FT[Prerequisites + Registration + Push Upstream]
    Start -->|Provision infra| UP["make up — EKS cluster"]
    Start -->|Deploy + run a single benchmark| RUN["make benchmark or make run"]
    Start -->|Re-run with new scenario knobs| KNOB[Edit env + make run]
    Start -->|Retrieve results| REP[reports/RUN_ID/]
    Start -->|Reset between sessions| CLEAN["make clean-deployment"]
    Start -->|Stop AWS billing| DOWN["make down — destructive"]

Safety and Cost Guardrails

The harness provisions billable AWS infrastructure (EKS control plane, NAT gateway, EBS volumes, c6i.2xlarge nodes, ECR). Two operations are destructive and must be confirmed with the user before executing — never run them autonomously based on inferred intent:

If TEARDOWN=1 is set in .env, make benchmark runs make down automatically at the end of the pipeline. Verify this is the user's intent before invoking make benchmark with that flag set.

Step 1 — Verify prerequisites

All commands run from skills/omni-gateway/omni-gateway-benchmark/ (where the Makefile lives — the shell scripts the Makefile calls are under scripts/).

Run the bundled preflight; it covers every check below in one pass and prints a remediation command for each gap:

make preflight

What make preflight verifies:

• Required CLIs present: terraform, kubectl, helm, aws, docker (with buildx), flexctl, curl, jq, python3, envsubst, sha256sum, shellcheck.
• Docker engine — client + server versions reported, and docker info confirms the daemon is reachable on the current context.
• AWS identity (aws sts get-caller-identity), the resolved AWS_PROFILE, and AWS_REGION loaded from .env.
• .env exists and .run/registration/registration.yaml is present.
• When POLICIES includes client-id-enforcement, both CLIENT_ID and CLIENT_SECRET are non-empty.
• Egress to flex-packages.anypoint.mulesoft.com (the Helm chart source).

Exits non-zero if any check fails — wire it into your shell pipeline (make preflight && make up) so a missing prerequisite stops the run before AWS billing starts.

The AWS principal must have permissions to create EC2, EKS, VPC, ECR, IAM, and EBS resources in the target region.

Step 2 — Configure the environment

Copy the example .env and fill in scenario knobs:

cp .env.example .env

Edit .env based on the scenario the user wants. Reference table — the harness reads every variable below:

Validation checklist before continuing:

• If POLICIES contains client-id-enforcement, both CLIENT_ID and CLIENT_SECRET are set.
• If POLICIES= (empty), no auth headers are required.
• FLEX_VERSION matches a chart version published at flex-packages.anypoint.mulesoft.com/helm.

Step 3 — Generate the Flex registration artifact (one-time)

The benchmark runs Flex in local mode. Use the bundled target — it generates the artifact once and, when POLICIES includes client-id-enforcement, prompts for CLIENT_ID / CLIENT_SECRET and writes them into .env:

make prepare-registration

Behavior:

• Skips registration generation if .run/registration/registration.yaml already exists. To rotate the gateway identity (forces a Flex redeploy), re-run with FORCE=1 make prepare-registration — the existing file is backed up to *.bak first.
• Skips the credential prompt unless POLICIES contains client-id-enforcement.
• Skips overwriting existing non-empty CLIENT_ID / CLIENT_SECRET unless FORCE=1.
• Supports non-interactive use: CLIENT_ID=... CLIENT_SECRET=... make prepare-registration.

Manual equivalent (use only if flexctl is being driven outside the harness):

flexctl registration create \
  --connected=false \
  --output-directory=.run/registration

Do not commit .run/registration/registration.yaml — it is gateway identity material and .run/ is gitignored.

Step 4 — Build and push the upstream image (one-time)

The k6 driver hits an in-cluster echo server. The image must exist in ECR before deploy-upstream runs:

make push-upstream

This builds for linux/amd64 via docker buildx (cross-compiling on Apple Silicon) and pushes to the ECR repository created by Terraform. If make up has not yet run, this fails because the ECR repo does not exist — provision infra first (Step 5).

Skip condition: If make up has already been run and the upstream image is unchanged, this step is a no-op. The deploy-upstream hash check will skip redeployment if the rendered manifest matches the live state.

Step 5 — Provision infrastructure (destructive on AWS billing)

Confirm with the user before running. This creates a VPC, EKS cluster, ECR, and installs the observability + k6-operator Helm releases:

make up

Expected duration: 15–25 minutes for a fresh cluster. Re-running on an existing cluster is idempotent and finishes in seconds.

After completion, verify the cluster is reachable:

aws eks update-kubeconfig --region "$AWS_REGION" --name "$CLUSTER_NAME"
kubectl get nodes

You should see two system nodes (t3.large, tainted) and three workload nodes (c6i.2xlarge, node-role=workload).

Step 6 — Deploy Flex + upstream

These targets are idempotent and content-addressed via SHA-256 hashes stored as pod template annotations / Deployment labels. Re-running with unchanged config is a no-op:

make deploy-upstream    # bench-upstream Service + Deployment in 'default' namespace
make deploy-flex        # Flex Gateway Helm release + CRD resources in 'flex' namespace

deploy-flex renders flex-config.yaml from assets/config/flex-config-header.yaml + assets/config/snippets/api-instance.yaml + assets/config/policies/<policy>.yaml, hashes it together with the image reference, and skips helm upgrade if the hash matches the live deployment. Config changes apply via kubectl apply to CRDs without restarting Flex pods.

Step 7 — Run the benchmark

A single load test, including report generation:

make run

This sequences: render scenario.js → create the per-run ConfigMap → apply the k6 TestRun CRD → poll until finished (default timeout 1800s) → port-forward Grafana and export PNGs → emit the Markdown report.

RUN_ID defaults to a UTC timestamp (20260612T140530Z). Override it for a stable identifier:

RUN_ID=baseline-1.13.0-rl make run

For the full pipeline (up → deploys → run, optionally down if TEARDOWN=1):

make benchmark

Re-running with different scenario knobs does not require redeploying:

RPS=2000 VUS=400 DURATION=5m make run
N_APIS=50 POLICIES= make run            # 50 APIs, no policies
FLEX_VERSION=1.14.0 make deploy-flex && make run

If a TestRun is already in flight in the k6-operator-system namespace, the new run will fail with a name collision — wait for the previous run to finish or run make clean-deployment to clear stale TestRuns.

Step 8 — Retrieve results

Each run persists artifacts under reports/<RUN_ID>/:

Ephemeral render output lives under .run/<RUN_ID>/ (flex-config.yaml, scenario.js, flex-values.yaml, upstream-deployment.yaml) and is safe to delete.

To re-export Grafana for the most recent run without re-running k6:

make report

To open Grafana interactively while a run is in flight (anonymous Viewer is enabled; no login required):

make watch        # opens port-forward + prints live URLs + opens k6 dashboard
# or, manually:
kubectl -n monitoring port-forward svc/kps-grafana 3000:80
# → http://localhost:3000

make watch accepts RUN_ID=<id> to filter the k6 / Driver dashboard to a specific run, and OPEN_BROWSER=0 to skip the auto-open.

Step 9 — Clean up

Two cleanup paths, ordered by aggressiveness:

make clean-deployment    # Remove Flex + upstream + k6 TestRuns; keep cluster + observability
make down                # terraform destroy — destroys everything (confirm with user first)

clean-deployment is safe between sessions and preserves the cluster cost (~$0.10/hr for the EKS control plane plus node-group on-demand pricing). make down stops all AWS billing for this environment but is irreversible — any reports not copied out of reports/ will remain locally, but ECR images and cluster state are gone.

Scenario Cookbook

Common parameter combinations:

The k6 thresholds in the rendered scenario are hard failures: http_req_failed < 1%, p(95) < 500ms, p(99) < 1000ms. A run that exceeds them will surface in the report's checks_succeeded line — the harness still completes and reports.

Troubleshooting

For deeper triage of the gateway itself (not the harness), invoke omni-gateway-logs or omni-gateway-diagnose.

Available Scripts

The make targets above are the supported entry points. They delegate to the scripts in scripts/, listed here for reference when debugging the harness or composing steps manually. Every script reads its configuration from .env and accepts --help for usage:

Related Jobs

• omni-gateway-install — install Flex on Linux/Docker/Kubernetes (this skill provisions its own EKS install for benchmarking; use omni-gateway-install for production deployments)
• omni-gateway-config — validate the rendered flex-config.yaml before make deploy-flex
• omni-gateway-logs — parse Flex pod logs when a benchmark surfaces unexpected failures
• omni-gateway-diagnose — triage non-harness gateway issues observed during a run