Эта статья посвящена новой функции Kubernetes: API Priority and Fairness (APF). Я хочу поделиться своими находками и рассказать, как определять политики для приоритизации и ограничения входящих запросов на API-сервер Kubernetes. Также мы рассмотрим некоторые метрики и отладочные конечные точки, которые позволяют оценивать влияние APF на контроллеры.

Бета-версия функции APF включена по умолчанию, начиная с версии Kubernetes 1.20. В более ранних версиях Kubernetes она включается через функциональный шлюз APIPriorityAndFairness.

Что такое APF?

До появления функции APF на API-сервере для ограничения количества поступающих запросов применялись параметры командной строки --max-requests-inflight и --max-mutating-requests-inflight. Единственное отличие заключается в том, что при использовании этих параметров не разграничиваются изменяющие (mutating) запросы и остальные. Например, эти параметры не гарантируют, что низкоприоритетный трафик не «задушит» критически важные вызовы (такой сценарий описывается в этом примере проблемы).

APF предлагает механизм управления потоком, чтобы API-сервер мог ограничивать запросы по принципу равнодоступности (fairness). Владельцы платформы могут задавать политики уровня API с целью классификации входящих запросов по различным приоритетам и потокам.

Управление запросами посредством потоков и приоритетов
Управление запросами посредством потоков и приоритетов

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

Чтобы соблюдать принцип равнодоступности среди запросов с одним уровнем приоритета, соответствующая им схема потока связывает запросы с потоками — запросам из одного источника назначается одинаковый отличительный признак потока (flow distinguisher).

В потоках запросов, которые невозможно выполнить прямо сейчас, организуются очереди по принципу перемешивающего шардинга (shuffle sharding), который часто применяется для изоляции рабочих нагрузок и повышения отказоустойчивости. Когда появляются достаточные ресурсы, система выводит отсортированные по потокам запросы из очередей по алгоритму организации равноправных очередей (fair queueing).

Общие сведения о FlowSchema и PriorityLevelConfiguration

Используемые в этом разделе команды тестировались на кластере Kubernetes 1.19, созданном с помощью kind 0.9.0. Для повышения удобочитаемости и фильтрации выходных данных YAML применялся обработчик yq 4.3.1.

Prometheus Operator развернут посредством kube-prometheus 0.7. Способ организации доступа к консоли Prometheus через переадресацию портов описан в файле README компонента kube-prometheus.

Прежде чем создать собственные ресурсы FlowSchema и PriorityLevelConfiguration, сначала рассмотрим ключевые концепции на основе стандартных ресурсов.

Список схем потоков по умолчанию:

kubectl get flowschema                                                                            
NAME                           PRIORITYLEVEL     MATCHINGPRECEDENCE   DISTINGUISHERMETHOD   AGE   MISSINGPL
exempt                         exempt            1                    <none>                13m   False
system-leader-election         leader-election   100                  ByUser                13m   False
workload-leader-election       leader-election   200                  ByUser                13m   False
system-nodes                   system            500                  ByUser                13m   False
kube-controller-manager        workload-high     800                  ByNamespace           13m   False
kube-scheduler                 workload-high     800                  ByNamespace           13m   False
kube-system-service-accounts   workload-high     900                  ByNamespace           13m   False
service-accounts               workload-low      9000                 ByUser                13m   False
global-default                 global-default    9900                 ByUser                13m   False
catch-all                      catch-all         10000                ByUser                13m   False

Возьмем в качестве примера схему потока system-leader-election, ее файл .spec выглядит следующим образом.

Спецификация схемы потока system-leader-election:

kubectl get flowschema system-leader-election -oyaml | yq e '.spec' - 
distinguisherMethod:
  type: ByUser
matchingPrecedence: 100
priorityLevelConfiguration:
  name: leader-election
rules:
  - resourceRules:
      - apiGroups:
          - ""
        namespaces:
          - kube-system
        resources:
          - endpoints
          - configmaps
        verbs:
          - get
          - create
          - update
      - apiGroups:
          - coordination.k8s.io
        namespaces:
          - '*'
        resources:
          - leases
        verbs:
          - get
          - create
          - update
    subjects:
      - kind: User
        user:
          name: system:kube-controller-manager
      - kind: User
        user:
          name: system:kube-scheduler
      - kind: ServiceAccount
        serviceAccount:
          name: '*'
          namespace: kube-system

В разделе rules приведен список критериев, по которым опознаются соответствующие запросы. Схема потока назначается запросу только при одновременном соблюдении следующих условий:

·        если хотя бы один из ее subjects (субъектов) совпадает с инициатором запроса;

·        если хотя бы одна из записей resourceRules или nonResourceRules совпадает с действием (verb) и запрашиваемым ресурсом или нересурсом.

Раздел distinguisherMethod определяет порядок вычисления отличительных признаков потоков:

·        ByUser — запросы от одного субъекта (subject) группируются в один и тот же поток, чтобы исключить доминирование каких-либо пользователей.

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

·        Пустая строка — все запросы группируются в единый поток.

В процессе сопоставления запросов схема потока с более низким значением matchingPrecedence имеет старшинство над более высоким значением matchingPrecendence.

Ресурс priorityLevelConfiguration содержит в себе конфигурацию уровней приоритетов с заданными атрибутами управления потоками.

Рассмотрим файл .spec конфигурации уровней приоритетов leader-election.

Спецификация конфигурации уровней приоритетов leader-election:

kubectl get prioritylevelconfigurations leader-election -oyaml | yq e '.spec' -                       
limited:
  assuredConcurrencyShares: 10
  limitResponse:
    queuing:
      handSize: 4
      queueLengthLimit: 50
      queues: 16
    type: Queue
type: Limited

Параметр limited.assuredConcurrencyShares определяет долю параллелизма, на основе которой рассчитывается гарантированное значение параллелизма. В документации к API Kubernetes есть подробное описание методики расчета гарантированного значения параллелизма.

Метрика apiserver_flowcontrol_request_concurrenty_limit дает представление о расчетных предельных значениях параллелизма для каждого уровня приоритета:

Ограничения параллелизма для всех уровней приоритета
Ограничения параллелизма для всех уровней приоритета

Значение limited.assuredConcurrencyShares связано с метрикой apiserver_flowcontrol_request_concurrency_limit таким образом, что увеличение доли параллелизма для уровня приоритета приводит к росту предельного значения параллелизма. Так как суммарное ограничение параллелизма API-сервера распределяется по всем уровням приоритета, повышение ограничения одного уровня приоритета сокращает ограничение для других.

Параметр limited.limitResponse определяет стратегию обработки запросов, которые невозможно исполнить прямо сейчас. Параметр limit.limitResponse.type допускает два значения:

·        Queue — запросы добавляются в очередь;

·        Reject — запросы отклоняются с ошибкой HTTP 429.

Тип реагирования Queue позволяет задать конфигурацию постановки в очередь с помощью параметров limited.limitResponse.queuing. В документации и предложении по реализации функции APF более подробно описывается эффект от изменения параметров queues, queueLengthLimit и handSize.

В следующем разделе мы научимся определять, какая схема сопоставляется нашим запросам.

Определение соответствующей схемы потока

Самый быстрый способ определить, какая схема потока соответствует нашему запросу, — проанализировать два заголовка, поступающих от API-сервера в ответах APF: X-Kubernetes-PF-FlowSchema-UID и X-Kubernetes-PF-PriorityLevel-UID. В них содержатся UID-идентификаторы соответствующих схем потоков и конфигурации уровня приоритетов.

Определение соответствующей схемы потока и уровня приоритета:

kubectl -n kube-system get po --v=8 2>&1 | grep -i x-kubernetes-pf                              
I0115 21:04:25.044262   65517 round_trippers.go:452]     X-Kubernetes-Pf-Flowschema-Uid: c36148b8-623a-45a8-9c63-7158262f7727
I0115 21:04:25.044267   65517 round_trippers.go:452]     X-Kubernetes-Pf-Prioritylevel-Uid: 0aab41a9-e078-4671-936b-937d6d5e8601

kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}" | grep c36148b8-623a-45a8-9c63-7158262f7727
c36148b8-623a-45a8-9c63-7158262f7727   exempt

kubectl get prioritylevelconfiguration -o custom-columns="uid:{metadata.uid},name:{metadata.name}" | grep 0aab41a9-e078-4671-936b-937d6d5e8601
0aab41a9-e078-4671-936b-937d6d5e8601   exempt

В примере выше, где я запрашиваю поды действием GET, запросу соответствует схема потока exempt и одноименная конфигурация уровня приоритета.

Чтобы понять влияние этой схемы потока на мой запрос, исследуем ее спецификацию .spec.

Спецификация схемы потока и уровня приоритета exempt:

kubectl get flowschema exempt -oyaml | yq e '.spec' - 
matchingPrecedence: 1
priorityLevelConfiguration:
  name: exempt
rules:
  - nonResourceRules:
      - nonResourceURLs:
          - '*'
        verbs:
          - '*'
    resourceRules:
      - apiGroups:
          - '*'
        clusterScope: true
        namespaces:
          - '*'
        resources:
          - '*'
        verbs:
          - '*'
    subjects:
      - group:
          name: system:masters
        kind: Group
        
# kubectl get prioritylevelconfiguration exempt -oyaml | yq e '.spec' -                        
type: Exempt

Обратите внимание, что схема потока exempt:

1.    имеет наибольшее старшинство, так как параметр matchingPrecedence имеет значение 1;

2.   сопоставляется запросам от группы system:masters.

Более того, в конфигурации уровня приоритета exempt параметр type соответствует Exempt, то есть какая-либо конфигурация очередности не требуется.

В этом есть смысл, поскольку мои команды kubectl авторизуются посредством моих учетных данных cluster-admin kubeconfig, связанных с группой system:masters. Запросы от группы system:masters считаются критически важным трафиком, поэтому они идут в обход механизма управления потоками и передаются немедленно с помощью схемы потока exempt согласно ее конфигурации уровня приоритета exempt.

С этим разобрались. Теперь можно поэкспериментировать с собственными схемой потока и конфигурацией уровня приоритета.

Создание кастомных схемы потока и уровня приоритета

Начнем с создания пространства имен demo с тремя служебными учетными записями, а именно podlister-0, podlister-1 и podlister-2, предоставив им разрешения выполнять действия LIST и GET для подов из пространства имен demo.

Создание пространства имен demo, его служебных учетных записей и задание требуемых параметров RBAC:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: demo
EOF

for i in {0..2}; do
cat <<EOF | kubectl auth reconcile -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: podlister
  namespace: demo  
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["list", "get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: podlister
  namespace: demo
subjects:
- apiGroup: ""
  kind: ServiceAccount
  name: podlister-$i
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: podlister
EOF
done

for i in {0..2}; do
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: podlister-$i
  namespace: demo
  labels:
    kubernetes.io/name: podlister-$i
EOF
done

Потом мы создаем произвольную схему потока, управляющую запросами от этих трех служебных учетных записей.

Развертывание схемы потока и конфигурации уровня приоритета restrict-pod-lister:

cat <<EOF | kubectl apply -f -
apiVersion: flowcontrol.apiserver.k8s.io/v1alpha1
kind: FlowSchema
metadata:
  name: restrict-pod-lister
spec:
  priorityLevelConfiguration:
    name: restrict-pod-lister
  distinguisherMethod:
    type: ByUser
  rules:
  - resourceRules:
    - apiGroups: [""]
      namespaces: ["demo"]
      resources: ["pods"]
      verbs: ["list", "get"]
    subjects:
    - kind: ServiceAccount
      serviceAccount:
        name: podlister-0
        namespace: demo
    - kind: ServiceAccount
      serviceAccount:
        name: podlister-1
        namespace: demo 
    - kind: ServiceAccount
      serviceAccount:
        name: podlister-2
        namespace: demo            
---
apiVersion: flowcontrol.apiserver.k8s.io/v1alpha1
kind: PriorityLevelConfiguration
metadata:
  name: restrict-pod-lister
spec:
  type: Limited
  limited:
    assuredConcurrencyShares: 10
    limitResponse:
      queuing:        
        queueLengthLimit: 5        
      type: Queue
EOF

Единственное нестандартное значение в уровне приоритета restrict-pod-lister — это размер очередей (spec.limited.limitResponse.queuing.queueLengthLimit), ограниченный пятью запросами. Благодаря этому мы сможем быстрее увидеть ограничение в действии.

Используя параметр kubectl --as, мы можем отправить запрос от имени служебной учетной записи podlister-0 на конечную точку для получения списка подов действием LIST.

Отправка запроса LIST для получения списка подов от имени другого пользователя:

kubectl -n demo get po --v=8 --as system:serviceaccount:demo:podlister-0  2>&1 | grep -i x-kubernetes-pf
I0118 20:06:06.654095     429 round_trippers.go:452]     X-Kubernetes-Pf-Flowschema-Uid: 88c3872e-5bcb-4264-b3f8-df757cedde4f                     
I0118 20:06:06.654098     429 round_trippers.go:452]     X-Kubernetes-Pf-Prioritylevel-Uid: 7f113b41-dbcb-43d0-8b6c-b8ace10e350f  

kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}" | grep 88c3872e-5bcb-4264-b3f8-df757cedde4f 
88c3872e-5bcb-4264-b3f8-df757cedde4f   restrict-pod-lister

kubectl get prioritylevelconfiguration -o custom-columns="uid:{metadata.uid},name:{metadata.name}" | grep 7f113b41-dbcb-43d0-8b6c-b8ace10e350f
7f113b41-dbcb-43d0-8b6c-b8ace10e350f   restrict-pod-lister

Отлично! Нашему запросу сопоставлена схема потока и уровень приоритета restrict-pod-lister, как мы и задумывали.

Исследование метрик APF

В этом разделе мы сымитируем входящий трафик API-сервера, развернув кастомный контроллер в пространстве имен demo в виде трех отдельных развертываний (Deployment). В каждом развертывании будет применяться одна из трех служебных учетных записей, созданных нами ранее.

Развертывание кастомных контроллеров:

for i in {0..2}; do
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: podlister-$i
  namespace: demo
  labels:
    kubernetes.io/name: podlister-$i
spec:
  selector:
    matchLabels:
      kubernetes.io/name: podlister-$i
  template:
    metadata:
      labels:
        kubernetes.io/name: podlister-$i
    spec:
      serviceAccountName: podlister-$i
      containers:
      - name: podlister
        image: gcr.io/ihcsim/podlister
        imagePullPolicy: Always
        command:
        - /podlister
        env:
        - name: TARGET_NAMESPACE
          value: demo
        - name: TICK_INTERVAL
          value: 200ms        
        - name: SHOW_ERRORS_ONLY
          value: "true"          
        resources:
          requests:
            cpu: 30m
            memory: 50Mi
          limits:
            cpu: 100m
            memory: 128Mi
EOF
done

Контроллер использует Go-функцию time.Tick(), чтобы непрерывно отправлять трафик на конечную точку API-сервера, выдающую список подов по запросу LIST. Будем таким образом извлекать все поды в пространстве имен demo. Исходный код доступен здесь.

Переходим в консоль Prometheus. Воспользуемся метрикой apiserver_flowcontrol_dispatched_requests_total, чтобы извлечь суммарное количество запросов, соответствующих нашей схеме потока:

apiserver_flowcontrol_dispatched_requests_total{job=”apiserver”,flowSchema=”restrict-pod-lister”}
Суммарное количество запросов, соответствующих нашей схеме потока
Суммарное количество запросов, соответствующих нашей схеме потока

Так как мы имеем дело с векторным счетчиком, при суммировании частоты запросов формируется возрастающий тренд:

sum(rate(apiserver_flowcontrol_dispatched_requests_total{job="apiserver",flowSchema="restrict-pod-lister"}[15m])) by (flowSchema)
Возрастающий тренд при суммировании частоты передачи запросов
Возрастающий тренд при суммировании частоты передачи запросов

Метрика apiserver_flowcontrol_current_inqueue_requests отражает количество запросов, ожидающих в очереди. Значение 0 свидетельствует о том, что в настоящий момент наши очереди пусты.

 Количество ожидающих в очереди запросов:

apiserver_flowcontrol_current_inqueue_requests{job="apiserver",flowSchema="restrict-pod-lister"}

Куда важнее, что количество отклоненных запросов тоже равно 0, что видно по метрике apiserver_flowcontrol_rejected_requests_total:

apiserver_flowcontrol_rejected_requests_total{job="apiserver",flowSchema="restrict-pod-lister"}
Количество запросов, отклоненных нашей схемой потока
Количество запросов, отклоненных нашей схемой потока

Метрика apiserver_flowcontrol_request_execution_seconds дает представление о том, как долго выполняются запросы из наших очередей:

histogram_quantile(0.99, sum(rate(apiserver_flowcontrol_request_execution_seconds_bucket{job="apiserver",flowSchema="restrict-pod-lister"}[15m])) by (le,flowSchema))
Задержка P99 времени выполнения запросов (в секундах) из наших очередей
Задержка P99 времени выполнения запросов (в секундах) из наших очередей

В рассматриваемом тестовом прогоне P99-задержка выполнения запросов из очередей составляет примерно 0,02 секунды.

В свою очередь, метрика apiserver_flowcontrol_request_wait_duration_seconds показывает, как долго запросы находятся в очереди:

histogram_quantile(0.99, sum(rate(apiserver_flowcontrol_request_wait_duration_seconds_bucket{job="apiserver",flowSchema="restrict-pod-lister"}[15m])) by (le,flowSchema))

Задержка P99 времени ожидания запросов (в секундах) в наших очередях

В этом тестовом прогоне P99-задержка ожидания запроса составляет примерно 4,95 миллисекунды. Позднее мы вернемся к этим метрикам, чтобы оценить их воздействие на контекстное время ожидания на стороне клиента.

Добавим побольше реплик, чтобы увеличить объем поступающего трафика и запустить формирование очередей.

Увеличение числа реплик кастомных контроллеров:

for i in {0..2}; do kubectl -n demo scale deploy/podlister-$i --replicas=10; done
deployment.apps/podlister-0 scaled
deployment.apps/podlister-1 scaled
deployment.apps/podlister-2 scaled

По мере насыщения очередей начинает расти количество отклоненных запросов. В метке reason указывается причина отклонения запросов. Например, очередь заполнена (queue-full) или истекло время ожидания (timeout):

sum(rate(apiserver_flowcontrol_rejected_requests_total{job="apiserver",flowSchema="restrict-pod-lister"}[15m])) by (flowSchema,reason)

Также в журнале контроллера появляются записи о регулировании частоты запросов.

Журналы кастомных контроллеров с записями о регулировании частоты запросов:

2021/01/23 18:45:05 error while listing pods: the server was unable to return a response in the time allotted, but may still be processing the request (get pods)
I0123 18:45:32.483900       1 request.go:655] Throttling request took 1.065818368s, request: GET:https://10.96.0.1:443/api/v1/namespaces/demo/pods
I0123 18:45:42.495515       1 request.go:655] Throttling request took 1.205752131s, request: GET:https://10.96.0.1:443/api/v1/namespaces/demo/pods
2021/01/23 18:46:34 error while listing pods: the server was unable to return a response in the time allotted, but may still be processing the request (get pods)
I0123 18:48:04.217262       1 request.go:655] Throttling request took 1.161568644s, request: GET:https://10.96.0.1:443/api/v1/namespaces/demo/pods
I0123 18:48:14.291914       1 request.go:655] Throttling request took 2.258553825s, request: GET:https://10.96.0.1:443/api/v1/namespaces/demo/pods
I0123 18:48:24.405990       1 request.go:655] Throttling request took 1.402613085s, request: GET:https://10.96.0.1:443/api/v1/namespaces/demo/pods
I0123 18:48:34.485410       1 request.go:655] Throttling request took 3.392645256s, request: GET:https://10.96.0.1:443/api/v1/namespaces/demo/pods
I0123 18:48:44.620237       1 request.go:655] Throttling request took 3.78360152s, request: GET:https://10.96.0.1:443/api/v1/namespaces/demo/pods
I0123 18:48:54.842999       1 request.go:655] Throttling request took 4.25852702s, request: GET:https://10.96.0.1:443/api/v1/namespaces/demo/pods
I0123 18:49:05.018247       1 request.go:655] Throttling request took 6.21121408s, request: GET:https://10.96.0.1:443/api/v1/namespaces/demo/pods
2021/01/23 18:49:10 error while listing pods: the server was unable to return a response in the time allotted, but may still be processing the request (get pods)

Задержка P99 времени ожидания запроса (apiserver_flowcontrol_request_wait_duration_seconds) лежит в пределах 4,0–7,5 секунды.

Задержка P99 времени выполнения запроса (apiserver_flowcontrol_request_execution_seconds) составляет примерно 0,96 секунды.

Если указать в контроллерах контекстное время ожидания (context timeout) меньшее, чем время ожидания в очереди, в журнале начнут появляться ошибки context deadline exceeded (превышен крайний срок контекста).

Журнал контроллера с ошибками context deadline exceeded:

kubectl -n demo set env deploy CONTEXT_TIMEOUT=5s --all                                      
deployment.apps/podlister-0 env updated
deployment.apps/podlister-1 env updated
deployment.apps/podlister-2 env updated

kubectl -n demo logs deploy/podlister-0 | grep -i "context deadline exceeded"
...
2021/01/23 19:16:10 error while listing pods: Get "https://10.96.0.1:443/api/v1/namespaces/demo/pods": context deadline exceeded
2021/01/23 19:16:12 error while listing pods: Get "https://10.96.0.1:443/api/v1/namespaces/demo/pods": context deadline exceeded
2021/01/23 19:16:15 error while listing pods: Get "https://10.96.0.1:443/api/v1/namespaces/demo/pods": context deadline exceeded
2021/01/23 19:16:18 error while listing pods: Get "https://10.96.0.1:443/api/v1/namespaces/demo/pods": context deadline exceeded
2021/01/23 19:16:19 error while listing pods: Get "https://10.96.0.1:443/api/v1/namespaces/demo/pods": context deadline exceeded
2021/01/23 19:16:19 error while listing pods: Get "https://10.96.0.1:443/api/v1/namespaces/demo/pods": context deadline exceeded
2021/01/23 19:16:23 error while listing pods: Get "https://10.96.0.1:443/api/v1/namespaces/demo/pods": context deadline exceeded

Если в журнале контроллера появится слишком много ошибок context deadline exceeded, вы сможете воспользоваться метриками APF и отладочными конечными точками, чтобы определить, не ограничивает ли ваши запросы функция APF.

На мой взгляд, это самые полезные метрики, но существует множество других метрик APF, не рассматриваемых в этой статье. Полный список см. в документации APF.

Анализ отладочных конечных точек

В дополнение к метрикам APF предлагает несколько отладочных конечных точек, позволяющих детальнее проанализировать обработку очередей и запросов.

Конечная точка /debug/api_priority_and_fairness/dump_priority_levels сообщает нам общее число выполняющихся (executing) и ожидающих (waiting) запросов на нашем уровне приоритета.

Отладочная конечная точка сообщает состояние запросов на нашем уровне приоритета:

kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels            
PriorityLevelName,   ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests
catch-all,           0,            true,   false,       0,               0
restrict-pod-lister, 14,           false,  false,       70,              29
system,              0,            true,   false,       0,               0
leader-election,     0,            true,   false,       0,               0
workload-high,       0,            true,   false,       0,               0
workload-low,        0,            false,  false,       0,               24
global-default,      0,            true,   false,       0,               0
exempt,              <none>,       <none>, <none>,      <none>,          <none>

В момент запуска этой команды в нашей очереди присутствовали 70 ожидающих (waiting) и 29 выполняющихся (executing) запросов.

Конечная точка /debug/api_priority_and_fairness/dump_queues предоставляет дополнительные сведения о состоянии каждой очереди в нашей схеме потока.

Отладочная конечная точка сообщает состояние каждой очереди на нашем уровне приоритета:

kubectl get --raw /debug/api_priority_and_fairness/dump_queues      
PriorityLevelName, Index,  PendingRequests, ExecutingRequests, VirtualStart,
restrict-pod-lister, 0,      0,               0,                 0.0000
restrict-pod-lister, 1,      0,               0,                 0.0000
restrict-pod-lister, 2,      0,               0,                 0.0000
restrict-pod-lister, 3,      0,               0,                 0.0000
restrict-pod-lister, 4,      0,               0,                 0.0000
restrict-pod-lister, 5,      3,               22,                33577.0739
restrict-pod-lister, 6,      5,               2,                 175325.9325
...
restrict-pod-lister, 50,     0,               0,                 0.0000
restrict-pod-lister, 51,     0,               0,                 0.0000
restrict-pod-lister, 52,     0,               0,                 0.0000
restrict-pod-lister, 53,     5,               0,                 256070.9451
restrict-pod-lister, 54,     0,               0,                 0.0000
...
restrict-pod-lister, 58,     0,               0,                 0.0000
restrict-pod-lister, 59,     0,               0,                 0.0000
restrict-pod-lister, 60,     0,               0,                 0.0000
restrict-pod-lister, 61,     0,               0,                 0.0000
restrict-pod-lister, 62,     5,               1,                 175266.1469
restrict-pod-lister, 63,     0,               0,                 0.0000

В целях удобочитаемости приведенные выше данные обрезаны. Обратите внимание, что отображаемое здесь количество запросов равно значению spec.limited.limitResponse.queuing.queues уровня приоритета.

И наконец, конечная точка /debug/api_priority_and_fairness/dump_requests отображает отличительные признаки потока, назначенные каждому запросу, наряду с информацией о субъекте (subject) запроса.

Отладочная конечная точка с информацией о наших запросах:

kubectl get --raw /debug/api_priority_and_fairness/dump_requests                           
PriorityLevelName,   FlowSchemaName,      QueueIndex, RequestIndexInQueue, FlowDistingsher,                        ArriveTime
...
restrict-pod-lister, restrict-pod-lister, 0,          0,                   system:serviceaccount:demo:podlister-2, 2021-01-23T19:01:15.931993992Z
restrict-pod-lister, restrict-pod-lister, 0,          1,                   system:serviceaccount:demo:podlister-2, 2021-01-23T19:01:16.696436146Z
restrict-pod-lister, restrict-pod-lister, 0,          2,                   system:serviceaccount:demo:podlister-2, 2021-01-23T19:01:17.193373873Z
restrict-pod-lister, restrict-pod-lister, 0,          3,                   system:serviceaccount:demo:podlister-2, 2021-01-23T19:01:18.056388941Z
restrict-pod-lister, restrict-pod-lister, 0,          4,                   system:serviceaccount:demo:podlister-2, 2021-01-23T19:01:18.710985385Z
restrict-pod-lister, restrict-pod-lister, 5,          0,                   system:serviceaccount:demo:podlister-0, 2021-01-23T19:01:18.710698732Z
restrict-pod-lister, restrict-pod-lister, 5,          1,                   system:serviceaccount:demo:podlister-0, 2021-01-23T19:01:18.710848957Z
restrict-pod-lister, restrict-pod-lister, 5,          2,                   system:serviceaccount:demo:podlister-0, 2021-01-23T19:01:18.71103922Z
restrict-pod-lister, restrict-pod-lister, 5,          3,                   system:serviceaccount:demo:podlister-0, 2021-01-23T19:01:18.711174595Z
restrict-pod-lister, restrict-pod-lister, 6,          0,                   system:serviceaccount:demo:podlister-1, 2021-01-23T19:01:18.710762896Z
....

Устранение эффектов регулирования частоты запросов

Если сократить количество контроллеров до нуля реплик, число отклоненных запросов постепенно будет снижаться по мере восстановления API-сервера после ограничения частоты запросов.

Сокращение числа реплик кастомных контроллеров:

for i in {0..2}; do kubectl -n demo scale deploy/podlister-$i --replicas=0; done
deployment.apps/podlister-0 scaled
deployment.apps/podlister-1 scaled
deployment.apps/podlister-2 scaled
sum(rate(apiserver_flowcontrol_rejected_requests_total{job="apiserver",flowSchema="restrict-pod-lister"}[15m])) by (flowSchema,reason)
Количество отклоненных запросов сокращается по мере восстановления
Количество отклоненных запросов сокращается по мере восстановления

Заключение

В этой статье мы рассмотрели создание кастомных ресурсов схемы потока (FlowSchema) и конфигурацию уровня приоритета (PriorityLevelConfiguration), позволяющих регулировать трафик, поступающий на API-сервер. Также мы рассмотрели спецификации этих ресурсов.

Сымитировав посредством пользовательского контроллера интенсивный трафик в направлении API-сервера, мы смогли проанализировать порядок обработки запросов и формирования очередей с помощью различных метрик и отладочных конечных точек APF.

Кроме того, мы рассмотрели сценарий, в котором крайний срок контекста на стороне клиента истекает по причине длительного пребывания запроса в очереди, до того как API-сервер закончит обработку наших запросов.

Конфигурация схемы потока допускает отклонение входящего трафика вместо постановки запросов в очередь и регулировку входящего трафика по пространствам имен вместо пользователей — все эти возможности вы можете протестировать самостоятельно по схожему принципу.


Перевод материала подготовлен в преддверии старта курса «Инфраструктурная платформа на основе Kubernetes».

Комментарии (0)