Pre-test connectivity validation for IP-restricted target servers

[moko-poi]

Feature Description

Currently, k6-operator starts the load test immediately after all runner pods are ready, without verifying that the target server is accessible from the runner pods. This causes issues when:

1. Target servers have IP restrictions/allowlists that need to be configured before testing
2. Network policies or firewall rules block initial connections
3. Target services are temporarily unavailable during test startup

When IP restrictions are in place, the test runs but all requests fail continuously, leading to:

• Wasted test execution time with failed requests
• Difficulty distinguishing between actual load testing results and connectivity issues
• Need for manual coordination between infrastructure teams and testing teams

Use Case Example:

• Production servers with strict IP allowlists
• Staging environments with network security policies
• Cloud services requiring IP whitelisting

Suggested Solution

Add a configurable pre-test connectivity check feature to TestRun CRD that polls until connectivity is successful (instead of failing immediately):

Option 1: Built-in connectivity validation

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: k6-sample
spec:
  parallelism: 4
  script:
    configMap:
      name: 'test'
      file: 'test.js'
  preTestValidation:
    enabled: true
    connectivityCheck:
      url: "https://target-server.example.com/health"
      method: "GET"
      expectedStatusCodes: [200, 204]
      timeout: "30s"
    polling:
      interval: "15s"
      backoff:
        type: exponential
        factor: 1.5
        maxInterval: "2m"
      maxDuration: "30m"
      successThreshold: 1
    # Only start the actual test after successful connectivity validation

Option 2: Custom validation script

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: k6-sample
spec:
  parallelism: 4
  script:
    configMap:
      name: 'test'
      file: 'test.js'
  preTestValidation:
    enabled: true
    validationScript:
      configMap:
        name: 'validation-script'
        file: 'validate.js'
    polling:
      interval: "20s"
      maxDuration: "45m"
    # Script exits 0 on success, non-0 on failure

Implementation Details:

1. Execute validation from one of the runner pods before starting the actual test

2. If validation fails, retry at the configured interval with optional backoff until either:

   • Connectivity succeeds (then proceed to the test), or
   • The maximum duration is exceeded (mark TestRun as ValidationFailed)

3. Provide clear error messages and retry events in TestRun status for troubleshooting

4. Add appropriate status conditions (ValidationPending, ValidationRetrying, ValidationSucceeded, ValidationDeadlineExceeded)

Benefits:

• Prevents wasted test runs due to connectivity issues
• Provides clear feedback about network/access problems
• Enables better coordination between teams
• Improves test reliability and results accuracy

Already existing or connected issues / PRs

Related issues that might benefit from this feature:

• The k6 Operator is not working #102 - Network connectivity issues causing test failures
• k6-operator manager freeze and don't recover after reaching timeout in initialize phase #128 - Timeout issues during initialization phase

[moko-poi]

Additional Context: Karpenter + IP Restrictions

Our Problem:

We use Karpenter for auto-scaling with IP-restricted target servers.

Current flow:

1. TestRun created → Pods pending → Karpenter boots new nodes → Pods ready
2. k6-operator immediately starts test
3. All requests fail (new node IPs not allowlisted yet)

What We Need:

1. Grace period after pods become ready (time to update IP allowlists)
2. Connectivity validation loop before starter execution
3. Only start test after successful validation

Why:

• Karpenter boots nodes in ~2-3 minutes
• IP allowlist updates take 5-10 minutes (manual process)
• Currently waste entire test duration with 100% failures

Desired flow:

Pods Ready → Grace Period → Connectivity Validation → Test Start

This would make k6-operator much better for dynamic environments with security restrictions.

[yorugac]

Hi @moko-poi, thanks for the issue. The problem is clear of course, but so far, the state of the SUT has never been a responsibility of neither k6 nor k6-operator.

Specifically, k6-operator follows the approaches in k6 and load testing software in general. AFAIK, readiness of SUT is the responsibility of a user, not of the load testing software. Basically, don't start the test before your SUT is ready to be tested 🙂 Alternatively, restart the test. So ATM, I don't think this kind of logic falls under k6-operator domain.

If we were to change this approach, IMO, it must be done on all levels, from k6 OSS to Grafana Cloud k6, i.e. not only in the TestRun CRD. I'm curious to know what the community thinks on this too.

---

As for workarounds, you could probably add some "validation logic" into init context of your main script. Then if SUT is not ready, the initializer pod will fail and the test will not proceed. You'll need some way to restart it after that.

But also, I see you mention that configuring IP allowlist is manual: in that case, why does this matter at all? If your SUT depends on manual set up, you can start your tests manually right after you've done the IP config and that's it.

The previous issues you linked were not about the same problem, AFAIS... The closest to what might help you from k6-operator side is probably this one: #457. But even that would require you to set up something additional that watches the state of your SUT.

[moko-poi]

Hi @yorugac, Thanks for the feedback.

Regarding the point about manual IP allowlist configuration not being relevant:
In our case this is actually a constraint due to using Karpenter. Since Karpenter only launches new nodes when pods are pending, we cannot know the node IPs beforehand. That means we can’t pre-register them in the allowlist in advance.

As for the workaround of adding validation logic in the init context:
I agree. I’ll try to verify whether we can fulfill this requirement within the init context for now.