DevOps в K8s  — Цепочка обработчиков запросов API-сервера, управление потоком запросов

DevOps в серии буткемпов K8s

Обратите внимание, полная ментальная карта DevOps в K8s доступна по адресу: «DevOps в ментальной карте K8s»

Цепочка обработчиков запросов сервера API

Ниже представлена ​​схема цепочки обработчиков сервера API:

В этой статье мы сосредоточимся на «управлении потоком запросов».

Общее формирование трафика и управление потоком

Дырявое ведро

Алгоритм дырявого ведра — широко используемый алгоритм в компьютерных сетях для формирования трафика и управления потоком. Он используется для управления скоростью, с которой данные передаются из одной точки в другую.

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

Ведро имеет течь, из-за чего вода медленно вытекает из ведра с постоянной скоростью. Скорость, с которой вода поступает в ведро, контролируется алгоритмом, чтобы гарантировать, что она не превышает вместимость ведра, а также обеспечить максимально постоянную скорость потока.

Ведро жетонов

Алгоритм Token Bucket — еще один широко используемый алгоритм. Он используется для управления скоростью, с которой данные передаются из одной точки в другую.

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

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

K8s Api-сервер управления потоком

kube-apiserver — это точка входа для внешних операций с ресурсами кластера. В качестве полной реализации компонента на основе API, чтобы обеспечить бесперебойную работу компонента API, функция регулирования, естественно, необходима.

В K8s Api-сервере есть три параметра управления потоком:

максимальное количество запросов в полете

Когда флаг --enable-priority-and-fairness установлен в значение true, максимальное количество запросов только для чтения и запросов на изменение, которые могут быть обработаны одновременно, определяется путем суммирования значений флагов --max-requests-inflight и --max-mutating-requests-inflight соответственно. Сумма должна быть положительным значением.

Если для флага --enable-priority-and-fairness установлено значение false, то флаг --max-requests-inflight ограничивает максимальное количество неизменяемых запросов, которые могут обрабатываться одновременно. Нулевое значение для --max-requests-inflight полностью отключает ограничение.

Значение по умолчанию --max-requests-inflight равно 400.

max-mutating-requests-inflight

Подобно параметру --max-requests-inflight, он управляет максимальным количеством запросов на изменение, когда --enable-priority-and-fairness равно true. Значение по умолчанию — 200.

enable-priority-and-fairness (Приоритет и справедливость API/APF)

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

Когда для --enable-priority-and-fairness установлено значение true, сервер API реализует схему приоритизации, которая назначает уровень приоритета каждому запросу в зависимости от его типа и происхождения.

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

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

Преимущества АПФ

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

Реализация АПФ

Это зависит от двух ресурсов

• PriorityLevelConfigurations, определяющие политики ограничения и емкость очереди.
• FlowSchemas, которые классифицируют запросы и могут указывать пользователей или группы пользователей, соответствующие конфигурации PriorityLevelConfiguration.

Вы можете использовать команду kubectl для проверки фактической конфигурации:

Конфигурации уровня приоритета

$ kubectl get PriorityLevelConfiguration workload-high -oyaml
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: PriorityLevelConfiguration
metadata:
  annotations:
    apf.kubernetes.io/autoupdate-spec: "true"
  creationTimestamp: "2023-04-06T19:08:45Z"
  generation: 1
  name: workload-high
  resourceVersion: "31"
  uid: 2fd5ded2-c172-4645-b3dc-a754819ca3c2
spec:
  limited:
    assuredConcurrencyShares: 40
    limitResponse:
      queuing:
        handSize: 6
        queueLengthLimit: 50
        queues: 128
      type: Queue
  type: Limited
status: {}

Схемы потоков

$ kubectl get flowschemas.flowcontrol.apiserver.k8s.io kube-controller-manager -oyaml
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: FlowSchema
metadata:
  annotations:
    apf.kubernetes.io/autoupdate-spec: "true"
  creationTimestamp: "2023-04-06T19:08:45Z"
  generation: 1
  name: kube-controller-manager
  resourceVersion: "58"
  uid: 50cc6dbb-f2fe-4676-b76b-7b43d0b93301
spec:
  distinguisherMethod:
    type: ByNamespace
  matchingPrecedence: 800
  priorityLevelConfiguration:
    name: workload-high
  rules:
  - nonResourceRules:
    - nonResourceURLs:
      - '*'
      verbs:
      - '*'
    resourceRules:
    - apiGroups:
      - '*'
      clusterScope: true
      namespaces:
      - '*'
      resources:
      - '*'
      verbs:
      - '*'
    subjects:
    - kind: User
      user:
        name: system:kube-controller-manager
status:
  conditions:
  - lastTransitionTime: "2023-04-06T19:08:45Z"
    message: This FlowSchema references the PriorityLevelConfiguration object named
      "workload-high" and it exists
    reason: Found
    status: "False"
    type: Dangling

Заключение