Эта статья посвящена новой функции 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-задержка выполнения запросов из очередей составляет примерно 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 scaledsum(rate(apiserver_flowcontrol_rejected_requests_total{job="apiserver",flowSchema="restrict-pod-lister"}[15m])) by (flowSchema,reason)
Заключение
В этой статье мы рассмотрели создание кастомных ресурсов схемы потока (FlowSchema) и конфигурацию уровня приоритета (PriorityLevelConfiguration), позволяющих регулировать трафик, поступающий на API-сервер. Также мы рассмотрели спецификации этих ресурсов.
Сымитировав посредством пользовательского контроллера интенсивный трафик в направлении API-сервера, мы смогли проанализировать порядок обработки запросов и формирования очередей с помощью различных метрик и отладочных конечных точек APF.
Кроме того, мы рассмотрели сценарий, в котором крайний срок контекста на стороне клиента истекает по причине длительного пребывания запроса в очереди, до того как API-сервер закончит обработку наших запросов.
Конфигурация схемы потока допускает отклонение входящего трафика вместо постановки запросов в очередь и регулировку входящего трафика по пространствам имен вместо пользователей — все эти возможности вы можете протестировать самостоятельно по схожему принципу.
Перевод материала подготовлен в преддверии старта курса «Инфраструктурная платформа на основе Kubernetes».
ссылка на оригинал статьи https://habr.com/ru/company/otus/blog/564098/
Добавить комментарий