CRI-O · Rate Limits

Cri O Rate Limits

CRI-O's APIs are local-host interfaces (CRI gRPC over a Unix socket, Status HTTP API, Prometheus /metrics) consumed by the kubelet and operators. CRI-O does not enforce per-second request rate limits on its own APIs; effective throughput is bounded by the host's CPU and the kubelet's own pacing. CRI-O does, however, support image-pull rate limiting via the pause_image_auth_file and the registries.conf rate-limiting controls (delegated to containers/image), and operator-side controls (--pids-limit, container-cpu-quota) bound runtime resource consumption per container.

4 Limits
CNCFContainer RuntimeContainersCRIKubernetesOCIOpen SourceRate Limiting

Limits

CRI gRPC API host
requests_per_second
not enforced upstream
Served on /var/run/crio/crio.sock. Kubelet is the only documented consumer; CRI-O does not apply its own throttle.
Status HTTP API host
requests_per_second
not enforced upstream
Documented as not stable for production use; intended for operator inspection.
Metrics endpoint host
requests_per_second
not enforced upstream
Prometheus scrape target on the configured port (default 9090).
Image-pull rate host
pulls_per_second
registry-bound
Bounded by the upstream registry rate limits (e.g. Docker Hub) and any retry / backoff configured in containers/image. CRI-O respects 429 / Retry-After when surfaced by the registry.

Policies

Local-host APIs
CRI-O APIs run on the node, not as a hosted service. There is no provider-imposed per-second limit; throughput is bounded by node CPU and the kubelet's own request pacing.
Image-pull backoff
When image registries return 429 (Docker Hub anonymous-pull limits, etc.), CRI-O surfaces the error to the kubelet, which honors its image-pull backoff policy.
Resource constraints
Operator-configured runtime constraints (--pids-limit, --cpu-quota, --memory-limit) bound per-container resource consumption rather than per-request rate.

Sources