Новый механизм API Priority and Fairness в Kubernetes

[Kate]

Эта статья посвящена новой функции 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:demoodlister-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-задержка выполнения запросов из очередей составляет примерно 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:demoodlister-2, 2021-01-23T19:01:15.931993992Z
restrict-pod-lister, restrict-pod-lister, 0, 1, system:serviceaccount:demoodlister-2, 2021-01-23T19:01:16.696436146Z
restrict-pod-lister, restrict-pod-lister, 0, 2, system:serviceaccount:demoodlister-2, 2021-01-23T19:01:17.193373873Z
restrict-pod-lister, restrict-pod-lister, 0, 3, system:serviceaccount:demoodlister-2, 2021-01-23T19:01:18.056388941Z
restrict-pod-lister, restrict-pod-lister, 0, 4, system:serviceaccount:demoodlister-2, 2021-01-23T19:01:18.710985385Z
restrict-pod-lister, restrict-pod-lister, 5, 0, system:serviceaccount:demoodlister-0, 2021-01-23T19:01:18.710698732Z
restrict-pod-lister, restrict-pod-lister, 5, 1, system:serviceaccount:demoodlister-0, 2021-01-23T19:01:18.710848957Z
restrict-pod-lister, restrict-pod-lister, 5, 2, system:serviceaccount:demoodlister-0, 2021-01-23T19:01:18.71103922Z
restrict-pod-lister, restrict-pod-lister, 5, 3, system:serviceaccount:demoodlister-0, 2021-01-23T19:01:18.711174595Z
restrict-pod-lister, restrict-pod-lister, 6, 0, system:serviceaccount:demoodlister-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-сервер закончит обработку наших запросов.

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

Источник статьи: https://habr.com/ru/company/otus/blog/564098/