Как в Kubernetes реализовано ограничение частоты запросов (rate limiting) к API-серверу?

В Kubernetes ограничение частоты запросов к API-серверу реализовано через механизм API Priority and Fairness (APF). Его основная задача — обеспечить стабильность и справедливость обработки запросов, предотвращая перегрузку API-сервера и гарантируя, что критически важные запросы не будут "заглушены" менее важными.

APF классифицирует входящие запросы и управляет ими с помощью двух основных компонентов:

1. 
   

   FlowSchema: Определяет, как классифицировать запрос. FlowSchema сопоставляет запрос с уровнем приоритета на основе его атрибутов (например, пользователь, группа, тип операции, целевой ресурс).

   
   
2. 
   

   PriorityLevelConfiguration: Определяет, как обрабатывать запросы, отнесенные к определенному уровню приоритета. Для каждого уровня настраиваются лимиты на количество одновременно выполняемых запросов и размер очереди для ожидающих запросов.

   
   

Пример FlowSchema:
Этот пример относит все запросы на проверку состояния (/healthz) к уровню exempt, который не имеет ограничений.

apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: FlowSchema
metadata:
  name: health-checks
spec:
  priorityLevelConfiguration:
    name: exempt # Уровень приоритета без ограничений
  rules:
  - resourceRules:
    - apiGroups: [""]
      resources: ["healthz"]
      verbs: ["get"]
    subjects:
    - kind: User
      user:
        name: "*"

Когда лимиты для определенного уровня приоритета превышены, API-сервер отвечает с кодом состояния HTTP 429 (Too Many Requests), предлагая клиенту повторить запрос позже. Этот механизм заменил устаревший флаг --max-requests-inflight и обеспечивает более гибкое и надежное управление нагрузкой.