Feature

Implement a supported configuration mechanism for the --goaway-chance flag in the Kubernetes API Server. This will provide administrators of large clusters with a supported method to control HTTP/2 connection distribution across API server pods.

Why is this important

In large OpenShift clusters, HTTP/2 connections tend to reuse existing connections to the same API server pod, creating unbalanced load distribution. This concentration of traffic on individual pods can cause:

• Resource exhaustion on heavily loaded API server pods

• Reduced overall cluster stability

• Potential API request failures during peak usage

By implementing the --goaway-chance parameter in a supported way, the API server will gracefully terminate a percentage of connections, forcing clients to establish new connections that will be distributed across different API server pods. This more even distribution pattern can significantly improve stability in large-scale deployments.

Large-scale deployments are increasing in OpenShift and while this has been in the backlog for a few releases it's becoming critical to allow this Kubernetes API flag.