Helm client-go connection pool tuning via undocumented environment variables

Connection pool limits in concurrent Helm operations

Helm v3 relies on the Kubernetes client-go library with hard-coded defaults of 5 QPS and a burst of 10. These values are not exposed through any Helm command-line flag, yet they directly control the HTTP connection pool used when communicating with the API server.

Undocumented override mechanism

The client-go library honors the environment variables KUBE_API_QPS and KUBE_API_BURST, allowing operators to adjust the pool size. However, Helm’s documentation does not mention these variables, and the project has not merged a decision to expose them as first-class configuration options.

Open configuration question

Teams running parallel Helm commands in CI pipelines need a supported way to size the connection pool without risking API server throttling or file-descriptor exhaustion. The current gap leaves administrators choosing between undocumented environment variables and accepting the restrictive defaults.

• Is the absence of documented QPS/burst flags an intentional design choice or an oversight?
• What is the recommended path for tuning connection pool behavior in production Helm workflows?