Helm client-go connection pool tuning via undocumented environment variables

Direct answers

Intentional design choice. Helm maintainers have explicitly declined adding QPS/burst flags (see helm/helm#10345, helm/helm#11234) because client-go already exposes these controls through its standard configuration layer. Duplicating them in Helm would create flag proliferation without adding new capability.

Recommended path for production CI: set the client-go environment variables KUBE_API_QPS and KUBE_API_BURST in your pipeline runtime (GitHub Actions env:, GitLab CI variables:, Jenkins credentials, etc.). These are officially supported by client-go since v0.17+ and work with any client-go consumer including Helm, kubectl, and custom controllers.

Why the env vars are the supported mechanism

Client-go reads KUBE_API_QPS (float, requests per second) and KUBE_API_BURST (integer, maximum burst) when building its REST config. Helm does not parse or forward these itself—the variables are honored directly by the shared library. This means:

• They affect all client-go operations in the Helm process: release operations, cache updates, discovery calls, and any plugin that uses the same kubeconfig.
• They override values from kubeconfig (cluster.qps/burst or user.qps/burst), so env vars are the simplest single source of truth.
• No Helm version upgrade is required; the behavior exists in every Helm 3 release because it lives in client-go.

Safe starting values for parallel CI pipelines

After load-testing against your target cluster, a common baseline is:

KUBE_API_QPS=50
KUBE_API_BURST=100

Guidelines:

• Keep burst >= qps (typically 2–3×) to avoid immediate throttling on startup spikes.
• Do not exceed the API server’s --max-requests-inflight and --max-mutating-requests-inflight (defaults 400/200). If multiple CI runners share a cluster, coordinate the aggregate QPS across runners.
• Monitor apiserver_request_total{code=~"429"} before and after changes; a rise in 429 responses means you’re pushing the server’s limit.

Alternative: kubeconfig stanza

If you prefer file-based config, add qps and burst under the cluster or user entry in ~/.kube/config:

clusters:
- name: my-cluster
  cluster:
    server: https://api.example.com
    qps: 50
    burst: 100

Environment variables still take precedence, which is useful for per-job overrides in CI.

Verification steps

1. Confirm current Helm/client-go version: helm version --short (client-go version is not printed directly; check go.mod in Helm source or vendor directory if needed).
2. Test env var uptake: KUBE_API_QPS=50 KUBE_API_BURST=100 HELM_DEBUG=1 helm list --all-namespaces 2>&1 | grep -i qps (debug output shows the constructed REST config).
3. Run a representative parallel workload (e.g., 10 concurrent helm upgrade --install) and watch API server 429 metrics.

One diagnostic detail that changes the recommendation

Are your CI runners executing Helm inside a container that drops or sanitizes environment variables (e.g., a distroless base, a security policy that strips unknown vars)? If yes, you must either allow-list KUBE_API_QPS/KUBE_API_BURST or switch to the kubeconfig method baked into the image.