API Server Request Calculator
Estimate the Kubernetes API server's request rate (QPS) from client count and per-client request rate, and check it against flow-control throttle thresholds.
Inputs
Controllers, operators, kubelets, and CI/CD clients calling the API server.
The API Priority and Fairness / flow-control QPS ceiling for this client tier.
Estimated API Server QPS
50.00QPS
Utilization vs Throttle Threshold
12.5%
Will Be Throttled
false
Headroom Before Throttling
350.00QPS
Step by step
Total requests/min = clients × req/client
150 × 20
= 3000 req/min
QPS = req/min ÷ 60
3000 ÷ 60
= 50.00 QPS
Utilization vs throttle threshold
50.00 ÷ 400
= 12.5%
How it works
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.
Formula
QPS = (clients × requestsPerClientPerMinute) / 60
- C
- Number of API server clients
- R_c
- Requests per client per minute
- Q
- Aggregate API server QPS
Frequently Asked Questions
What causes API server throttling in practice?
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.
How does API Priority and Fairness (APF) help?
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.
What's the fix if legitimate clients are hitting throttling?
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.