Estimate the request rate hitting the Kubernetes API server from controllers and clients.
The kube-apiserver enforces client-side rate limiting via client-go's QPS/Burst settings and, on the server side, API Priority and Fairness (APF) flow-control queues that cap request rate per priority level. Estimating aggregate QPS from client count and per-client request rate helps predict whether a growing number of controllers, CI/CD jobs, or operators will bump into those throttle thresholds and start seeing 429 Too Many Requests responses.
QPS = (clients × requestsPerClientPerMinute) / 60
A surge in controllers, operators, or CI/CD pipelines all polling or reconciling against the API server simultaneously — especially list/watch-heavy workloads or clients without exponential backoff on retries — pushing aggregate QPS above the configured flow-control limits for their priority level.
APF classifies requests into priority levels (e.g. workload-high, leader-election, global-default) with separate queues and concurrency limits, so a burst of low-priority traffic can't starve critical system components like the scheduler or controller-manager from getting API server time.
Add client-side caching/informers instead of repeated polling, ensure clients respect Retry-After and use exponential backoff, and if genuinely needed, request an increase to the relevant APF priority level's concurrency share.