Kubernetes Operators · Rate Limits

Kubernetes Operators Rate Limits

Operators interact with the Kubernetes API server as authenticated clients. There is no vendor-imposed rate limit on the pattern itself; instead, rate limiting is enforced by the Kubernetes API server (per-user/per-priority-level) via API Priority and Fairness (APF) and by client-side QPS/burst settings configured in client-go (rest.Config).

Kubernetes Operators Rate Limits is the machine-readable rate-limit profile for Kubernetes Operators on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 2 rate-limit definitions, measuring concurrent_requests and requests_per_second.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled and serviceUnavailable.

Tagged areas include Rate Limiting, Kubernetes, Operators, and Open Source.

2 Limits Throttle: 429
Rate LimitingKubernetesOperatorsOpen Source

Limits

API Priority and Fairness (server-side) priority-level
concurrent_requests
cluster-configured PriorityLevelConfiguration concurrency shares
Client-side QPS / Burst (client-go) client
requests_per_second
rest.Config.QPS (default 5) / Burst (default 10) — operators typically tune higher

Policies

APF flow control
The Kubernetes API server applies API Priority and Fairness; operators should set a sensible UserAgent and FlowSchema to avoid starvation under load.
Client-side throttling
client-go enforces local QPS/Burst before sending requests; operator authors raise these defaults to suit reconciliation workloads.
Backoff and resync
Use the controller-runtime / informer cache and rate-limited workqueues; do not poll the API server in tight loops — rely on watches.
Honor 429 and Retry-After
When the API server returns 429 (typically with a Retry-After), back off and respect the suggested delay rather than retrying immediately.

Sources