Эта статья посвящена новой функции Kubernetes: API Priority and Fairness (APF). Я хочу поделиться своими находками и рассказать, как определять политики для приоритизации и ограничения входящих запросов на API-сервер Kubernetes. Также мы рассмотрим некоторые метрики и отладочные конечные точки, которые позволяют оценивать влияние APF на контроллеры. Бета-версия функции APF включена по умолчанию, начиная с версии Kubernetes 1.20. В более ранних версиях Kubernetes она включается через функциональный шлюз APIPriorityAndFairness. До появления функции APF на API-сервере для ограничения количества поступающих запросов применялись параметры командной строки --max-requests-inflight и --max-mutating-requests-inflight. Единственное отличие заключается в том, что при использовании этих параметров не разграничиваются изменяющие (mutating) запросы и остальные. Например, эти параметры не гарантируют, что низкоприоритетный трафик не «задушит» критически важные вызовы (такой сценарий описывается в этом примере проблемы). APF предлагает механизм управления потоком, чтобы API-сервер мог ограничивать запросы по принципу равнодоступности (fairness). Владельцы платформы могут задавать политики уровня API с целью классификации входящих запросов по различным приоритетам и потокам. Все входящие запросы оцениваются на соответствие набору схем потоков. Для каждого запроса подбирается одна конкретная схема потока, которая назначает запросу уровень приоритета. Следовательно, когда ограничиваются запросы с определенным уровнем приоритета, это никак не влияет на запросы с другими уровнями приоритета. Чтобы соблюдать принцип равнодоступности среди запросов с одним уровнем приоритета, соответствующая им схема потока связывает запросы с потоками — запросам из одного источника назначается одинаковый отличительный признак потока (flow distinguisher). В потоках запросов, которые невозможно выполнить прямо сейчас, организуются очереди по принципу перемешивающего шардинга (shuffle sharding), который часто применяется для изоляции рабочих нагрузок и повышения отказоустойчивости. Когда появляются достаточные ресурсы, система выводит отсортированные по потокам запросы из очередей по алгоритму организации равноправных очередей (fair queueing). ​Используемые в этом разделе команды тестировались на кластере Kubernetes 1.19, созданном с помощью kind 0.9.0. Для повышения удобочитаемости и фильтрации выходных данных YAML применялся обработчик yq 4.3.1. ​Prometheus Operator развернут посредством kube-prometheus 0.7. Способ организации доступа к консоли Prometheus через переадресацию портов описан в файле README компонента kube-prometheus. Прежде чем создать собственные ресурсы FlowSchema и PriorityLevelConfiguration, сначала рассмотрим ключевые концепции на основе стандартных ресурсов. Список схем потоков по умолчанию: Возьмем в качестве примера схему потока system-leader-election, ее файл .spec выглядит следующим образом. Спецификация схемы потока system-leader-election: В разделе rules приведен список критериев, по которым опознаются соответствующие запросы. Схема потока назначается запросу только при одновременном соблюдении следующих условий: ·        если хотя бы один из ее subjects (субъектов) совпадает с инициатором запроса; ·        если хотя бы одна из записей resourceRules или nonResourceRules совпадает с действием (verb) и запрашиваемым ресурсом или нересурсом. Раздел distinguisherMethod определяет порядок вычисления отличительных признаков потоков: ·        ByUser — запросы от одного субъекта (subject) группируются в один и тот же поток, чтобы исключить доминирование каких-либо пользователей. ·        ByNamespace — запросы, исходящие от одного и того же пространства имен, группируются в один и тот же поток, чтобы исключить доминирование рабочих нагрузок в одном пространстве имен над рабочими нагрузками из других пространств имен. ·        Пустая строка — все запросы группируются в единый поток. В процессе сопоставления запросов схема потока с более низким значением matchingPrecedence имеет старшинство над более высоким значением matchingPrecendence. Ресурс priorityLevelConfiguration содержит в себе конфигурацию уровней приоритетов с заданными атрибутами управления потоками. Рассмотрим файл .spec конфигурации уровней приоритетов leader-election. Спецификация конфигурации уровней приоритетов leader-election: Параметр limited.assuredConcurrencyShares определяет долю параллелизма, на основе которой рассчитывается гарантированное значение параллелизма. В документации к API Kubernetes есть подробное описание методики расчета гарантированного значения параллелизма. Метрика apiserver_flowcontrol_request_concurrenсy_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-идентификаторы соответствующих схем потоков и конфигурации уровня приоритетов. Определение соответствующей схемы потока и уровня приоритета: В примере выше, где я запрашиваю поды действием GET, запросу соответствует схема потока exempt и одноименная конфигурация уровня приоритета. Чтобы понять влияние этой схемы потока на мой запрос, исследуем ее спецификацию .spec. Спецификация схемы потока и уровня приоритета 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: Потом мы создаем произвольную схему потока, управляющую запросами от этих трех служебных учетных записей. Развертывание схемы потока и конфигурации уровня приоритета restrict-pod-lister: Единственное нестандартное значение в уровне приоритета restrict-pod-lister — это размер очередей (spec.limited.limitResponse.queuing.queueLengthLimit), ограниченный пятью запросами. Благодаря этому мы сможем быстрее увидеть ограничение в действии. Используя параметр kubectl --as, мы можем отправить запрос от имени служебной учетной записи podlister-0 на конечную точку для получения списка подов действием LIST. Отправка запроса LIST для получения списка подов от имени другого пользователя: Отлично! Нашему запросу сопоставлена схема потока и уровень приоритета restrict-pod-lister, как мы и задумывали. В этом разделе мы сымитируем входящий трафик API-сервера, развернув кастомный контроллер в пространстве имен demo в виде трех отдельных развертываний (Deployment). В каждом развертывании будет применяться одна из трех служебных учетных записей, созданных нами ранее. Развертывание кастомных контроллеров: Контроллер использует Go-функцию time.Tick(), чтобы непрерывно отправлять трафик на конечную точку API-сервера, выдающую список подов по запросу LIST. Будем таким образом извлекать все поды в пространстве имен demo. Исходный код доступен здесь. Переходим в консоль Prometheus. Воспользуемся метрикой apiserver_flowcontrol_dispatched_requests_total, чтобы извлечь суммарное количество запросов, соответствующих нашей схеме потока: Так как мы имеем дело с векторным счетчиком, при суммировании частоты запросов формируется возрастающий тренд: Метрика apiserver_flowcontrol_current_inqueue_requests отражает количество запросов, ожидающих в очереди. Значение 0 свидетельствует о том, что в настоящий момент наши очереди пусты.  Количество ожидающих в очереди запросов: Куда важнее, что количество отклоненных запросов тоже равно 0, что видно по метрике apiserver_flowcontrol_rejected_requests_total: Метрика apiserver_flowcontrol_request_execution_seconds дает представление о том, как долго выполняются запросы из наших очередей: В рассматриваемом тестовом прогоне P99-задержка выполнения запросов из очередей составляет примерно 0,02 секунды. В свою очередь, метрика apiserver_flowcontrol_request_wait_duration_seconds показывает, как долго запросы находятся в очереди: Задержка P99 времени ожидания запросов (в секундах) в наших очередях В этом тестовом прогоне P99-задержка ожидания запроса составляет примерно 4,95 миллисекунды. Позднее мы вернемся к этим метрикам, чтобы оценить их воздействие на контекстное время ожидания на стороне клиента. Добавим побольше реплик, чтобы увеличить объем поступающего трафика и запустить формирование очередей. Увеличение числа реплик кастомных контроллеров: По мере насыщения очередей начинает расти количество отклоненных запросов. В метке reason указывается причина отклонения запросов. Например, очередь заполнена (queue-full) или истекло время ожидания (timeout): Также в журнале контроллера появляются записи о регулировании частоты запросов. Журналы кастомных контроллеров с записями о регулировании частоты запросов: Задержка 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: Если в журнале контроллера появится слишком много ошибок context deadline exceeded, вы сможете воспользоваться метриками APF и отладочными конечными точками, чтобы определить, не ограничивает ли ваши запросы функция APF. На мой взгляд, это самые полезные метрики, но существует множество других метрик APF, не рассматриваемых в этой статье. Полный список см. в документации APF. В дополнение к метрикам APF предлагает несколько отладочных конечных точек, позволяющих детальнее проанализировать обработку очередей и запросов. Конечная точка /debug/api_priority_and_fairness/dump_priority_levels сообщает нам общее число выполняющихся (executing) и ожидающих (waiting) запросов на нашем уровне приоритета. Отладочная конечная точка сообщает состояние запросов на нашем уровне приоритета: В момент запуска этой команды в нашей очереди присутствовали 70 ожидающих (waiting) и 29 выполняющихся (executing) запросов. Конечная точка /debug/api_priority_and_fairness/dump_queues предоставляет дополнительные сведения о состоянии каждой очереди в нашей схеме потока. Отладочная конечная точка сообщает состояние каждой очереди на нашем уровне приоритета: В целях удобочитаемости приведенные выше данные обрезаны. Обратите внимание, что отображаемое здесь количество запросов равно значению spec.limited.limitResponse.queuing.queues уровня приоритета. И наконец, конечная точка /debug/api_priority_and_fairness/dump_requests отображает отличительные признаки потока, назначенные каждому запросу, наряду с информацией о субъекте (subject) запроса. Отладочная конечная точка с информацией о наших запросах: Если сократить количество контроллеров до нуля реплик, число отклоненных запросов постепенно будет снижаться по мере восстановления API-сервера после ограничения частоты запросов. Сокращение числа реплик кастомных контроллеров: В этой статье мы рассмотрели создание кастомных ресурсов схемы потока (FlowSchema) и конфигурацию уровня приоритета (PriorityLevelConfiguration), позволяющих регулировать трафик, поступающий на API-сервер. Также мы рассмотрели спецификации этих ресурсов. Сымитировав посредством пользовательского контроллера интенсивный трафик в направлении API-сервера, мы смогли проанализировать порядок обработки запросов и формирования очередей с помощью различных метрик и отладочных конечных точек APF. Кроме того, мы рассмотрели сценарий, в котором крайний срок контекста на стороне клиента истекает по причине длительного пребывания запроса в очереди, до того как API-сервер закончит обработку наших запросов. Конфигурация схемы потока допускает отклонение входящего трафика вместо постановки запросов в очередь и регулировку входящего трафика по пространствам имен вместо пользователей — все эти возможности вы можете протестировать самостоятельно по схожему принципу. Перевод материала подготовлен в преддверии старта курса «Инфраструктурная платформа на основе Kubernetes».  Редактор