Устранение неполадок с сервером API и etcd в службах Azure Kubernetes
Это руководство поможет вам определить и устранить любые маловероятные проблемы, которые могут возникнуть на сервере API в крупных развертываниях Служб Microsoft Azure Kubernetes (AKS).
Корпорация Майкрософт проверила надежность и производительность сервера API в масштабе 5000 узлов и 200 000 модулей pod. Кластер, содержащий сервер API, имеет возможность автоматического масштабирования и доставки целей уровня обслуживания Kubernetes (SLO). Если у вас возникают большие задержки или тайм-ауты, это, вероятно, связано с утечкой ресурсов в распределенном etc
каталоге (т. д.) или из-за чрезмерного количества вызовов API у клиента-злоумышленника.
Предварительные условия
Средство Kubernetes kubectl . Чтобы установить kubectl с помощью Azure CLI, выполните команду az aks install-cli .
AKS диагностика журналы (в частности, события kube-audit), которые включены и отправляются в рабочую область Log Analytics. Чтобы определить, собираются ли журналы в режиме диагностика azure или для конкретного ресурса, проверка колонку Параметры диагностики в портал Azure.
Уровень "Стандартный" для кластеров AKS. Если вы используете уровень "Бесплатный", сервер API и т. д. содержат ограниченные ресурсы. Кластеры AKS на уровне "Бесплатный" не обеспечивают высокий уровень доступности. Это часто является первопричиной проблем с сервером API и т. д.
Подключаемый модуль kubectl-aks для выполнения команд непосредственно на узлах AKS без использования плоскости управления Kubernetes.
Симптомы
В следующей таблице описаны распространенные симптомы сбоев сервера API.
Признак | Описание |
---|---|
Время ожидания сервера API | Частые тайм-ауты, которые выходят за рамки гарантий в SLA сервера API AKS. Например, kubectl время ожидания команд. |
Высокая задержка | Высокая задержка, из-за чего объекты SLO Kubernetes завершаются сбоем. Например, команда kubectl выводит список модулей pod более 30 секунд. |
Модуль pod сервера API в CrashLoopbackOff состоянии или сбои вызова веб-перехватчика |
Убедитесь, что у вас нет пользовательского веб-перехватчика допуска (например, обработчика политик Kyverno ), блокирующего вызовы сервера API. |
Контрольный список для устранения неполадок
Если у вас возникает высокая задержка, выполните следующие действия, чтобы определить некорпожающий клиент и типы вызовов API, которые завершаются сбоем.
Шаг 1. Определение основных агентов пользователей по количеству запросов
Чтобы определить, какие клиенты генерируют больше всего запросов (и, возможно, большую загрузку сервера API), выполните запрос, похожий на приведенный ниже код. В следующем запросе перечислены первые 10 агентов пользователей по количеству отправленных запросов сервера API.
AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| summarize count() by UserAgent
| top 10 by count_
| project UserAgent, count_
Примечание.
Если запрос не возвращает результатов, возможно, вы выбрали неправильную таблицу для запроса диагностика журналов. В режиме для конкретного ресурса данные записываются в отдельные таблицы в зависимости от категории ресурса. Журналы диагностики записываются в таблицу AKSAudit
. В режиме диагностика Azure все данные записываются в таблицуAzureDiagnostics
. Дополнительные сведения см. в статье Журналы ресурсов Azure.
Хотя полезно знать, какие клиенты создают наибольший объем запросов, большой объем запросов сам по себе не может быть причиной для беспокойства. Лучшим показателем фактической нагрузки, которую каждый клиент создает на сервере API, является задержка ответа, которую он испытывает.
Шаг 2. Определение и диаграмма средней задержки запросов сервера API на агент пользователя
Чтобы определить среднюю задержку запросов сервера API на агент пользователя, показанную на диаграмме времени, выполните следующий запрос:
AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| extend start_time = RequestReceivedTime
| extend end_time = StageReceivedTime
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize avg(latency) by UserAgent, bin(start_time, 5m)
| render timechart
Этот запрос является продолжением запроса в разделе "Определение основных агентов пользователей по количеству запросов". Это может дать вам больше сведений о фактической нагрузке, создаваемой каждым агентом пользователя с течением времени.
Совет
Анализируя эти данные, можно определить закономерности и аномалии, которые могут указывать на проблемы в кластере ИЛИ приложениях AKS. Например, вы можете заметить, что у конкретного пользователя наблюдается высокая задержка. Этот сценарий может указывать тип вызовов API, которые вызывают чрезмерную нагрузку на сервер API или т. д.
Шаг 3. Определение недопустимых вызовов API для заданного агента пользователя
Выполните следующий запрос для табуляции задержки 99-го процентиля (P99) вызовов API в разных типах ресурсов для данного клиента:
AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| extend HttpMethod = Verb
| extend Resource = tostring(ObjectRef.resource)
| where UserAgent == "DUMMYUSERAGENT" // Filter by name of the useragent you are interested in
| where Resource != ""
| extend start_time = RequestReceivedTime
| extend end_time = StageReceivedTime
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize p99latency=percentile(latency, 99) by HttpMethod, Resource
| render table
Результаты этого запроса могут быть полезны для определения типов вызовов API, которые не вышестоящий объектов SLO Kubernetes. В большинстве случаев оскорбляющий клиент может выполнять слишком много LIST
вызовов к большому набору объектов или объектов, которые слишком велики. К сожалению, жесткие ограничения масштабируемости отсутствуют, чтобы помочь пользователям в масштабировании сервера API. Ограничения масштабируемости сервера API или etcd зависят от различных факторов, описанных в разделе Пороговые значения масштабируемости Kubernetes.
Причина 1. Сетевое правило блокирует трафик с узлов агента на сервер API.
Сетевое правило может блокировать трафик между узлами агента и сервером API.
Чтобы проверить, блокирует ли неправильно настроенная сетевая политика обмен данными между сервером API и узлами агента, выполните следующие команды kubectl-aks :
kubectl aks config import \
--subscription <mySubscriptionID> \
--resource-group <myResourceGroup> \
--cluster-name <myAKSCluster>
kubectl aks check-apiserver-connectivity --node <myNode>
Команда импорта конфигурации извлекает сведения о масштабируемом наборе виртуальных машин для всех узлов в кластере. Затем команда проверка-apiserver-connectivity использует эти сведения для проверки сетевого подключения между сервером API и указанным узлом, в частности для его базового экземпляра масштабируемого набора.
Примечание.
Если выходные check-apiserver-connectivity
данные команды содержат Connectivity check: succeeded
сообщение, сетевое подключение будет беспрепятственно.
Решение 1. Исправление политики сети для устранения блокировки трафика
Если в выходных данных команды указано, что произошел сбой подключения, перенастройте политику сети, чтобы она не блокировали трафик между узлами агента и сервером API.
Причина 2. Оскорбил клиент утечки объектов etcd и приводит к замедлению использования etcd
Распространенной проблемой является непрерывное создание объектов без удаления неиспользуемых объектов в базе данных etcd. Это может вызвать проблемы с производительностью, если etcd имеет дело с слишком большим количеством объектов (более 10 000) любого типа. Быстрое увеличение изменений в таких объектах также может привести к превышению размера базы данных etcd (4 гигабайта по умолчанию).
Чтобы проверка использования базы данных etcd, перейдите в раздел Диагностика и решение проблем в портал Azure. Запустите средство диагностики проблем с доступностью Etcd , выполнив поиск по запросу etcd в поле поиска. Средство диагностики показывает разбивку использования и общий размер базы данных.
Если вы просто хотите быстро просмотреть текущий размер базы данных etcd в байтах, выполните следующую команду:
kubectl get --raw /metrics | grep -E "etcd_db_total_size_in_bytes|apiserver_storage_size_bytes|apiserver_storage_db_total_size_in_bytes"
Примечание.
Имя метрики в предыдущей команде отличается для разных версий Kubernetes. Для Kubernetes 1.25 и более ранних версий используйте etcd_db_total_size_in_bytes
. Для Kubernetes 1.26–1.28 используйте apiserver_storage_db_total_size_in_bytes
.
Решение 2. Определение квот для создания, удаления объектов или ограничения времени существования объекта в etcd
Чтобы предотвратить достижение емкости и причинение простоя кластера, можно ограничить максимальное количество создаваемых ресурсов. Вы также можете замедлить количество исправлений, создаваемых для экземпляров ресурсов. Чтобы ограничить количество создаваемых объектов, можно определить квоты объектов.
Если вы определили объекты, которые больше не используются, но занимают ресурсы, рассмотрите возможность их удаления. Например, вы можете удалить выполненные задания, чтобы освободить место:
kubectl delete jobs --field-selector status.successful=1
Для объектов, поддерживающих автоматическую очистку, можно задать значения времени жизни (TTL), чтобы ограничить время существования этих объектов. Вы также можете пометить объекты метками, чтобы можно было массово удалить все объекты определенного типа с помощью селекторов меток. При установке ссылок владельца между объектами все зависимые объекты автоматически удаляются после удаления родительского объекта.
Причина 3. Клиент-злоумышленник выполняет чрезмерные вызовы LIST или PUT
Если вы определите, что etcd не перегружен слишком большим количеством объектов, клиент-злоумышленник может выполнять слишком много LIST
вызовов или PUT
вызовов к серверу API.
Решение 3a. Настройка шаблона вызова API
Рассмотрите возможность настройки шаблона вызовов API клиента, чтобы снизить нагрузку на уровень управления.
Решение 3b. Регулирование клиента, который подавляет уровень управления
Если вы не можете настроить клиент, вы можете использовать функцию приоритета и справедливости в Kubernetes для регулирования клиента. Эта функция помогает сохранить работоспособность уровня управления и предотвратить сбои других приложений.
В следующей процедуре показано, как регулировать api list pod клиента, который выполняет ошибку, для пяти одновременных вызовов:
Create FlowSchema, соответствующую шаблону вызова API для клиента-оскорбляющегося клиента:
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2 kind: FlowSchema metadata: name: restrict-bad-client spec: priorityLevelConfiguration: name: very-low-priority distinguisherMethod: type: ByUser rules: - resourceRules: - apiGroups: [""] namespaces: ["default"] resources: ["pods"] verbs: ["list"] subjects: - kind: ServiceAccount serviceAccount: name: bad-client-account namespace: default
Create конфигурацию с более низким приоритетом для регулирования недопустимых вызовов API клиента:
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2 kind: PriorityLevelConfiguration metadata: name: very-low-priority spec: limited: assuredConcurrencyShares: 5 limitResponse: type: Reject type: Limited
Наблюдайте за регулируемым вызовом в метриках сервера API.
kubectl get --raw /metrics | grep "restrict-bad-client"
Причина 4. Настраиваемый веб-перехватчик может вызвать взаимоблокировку в модулях pod сервера API
Настраиваемый веб-перехватчик, например Kyverno, может вызвать взаимоблокировку в модулях pod сервера API.
Проверьте события, связанные с сервером API. Могут отображаться сообщения о событиях, похожие на следующий текст:
Произошла внутренняя ошибка: не удалось вызвать веб-перехватчик "mutate.kyverno.svc-fail": не удалось вызвать веб-перехватчик: Post "https://kyverno-system-kyverno-system-svc.kyverno-system.svc:443/mutate/fail?timeout=10s": write unix @-/>tunnel-uds/proxysocket: write: broken pipe
В этом примере проверяющий веб-перехватчик блокирует создание некоторых объектов сервера API. Так как этот сценарий может произойти во время начальной загрузки, сервер API и модули pod Konnectivity невозможно создать. Поэтому веб-перехватчик не может подключиться к этим модулям pod. Эта последовательность событий вызывает взаимоблокировку и сообщение об ошибке.
Решение 4. Удаление конфигураций веб-перехватчиков
Чтобы устранить эту проблему, удалите конфигурации проверяющих и изменяющих веб-перехватчиков. Чтобы удалить эти конфигурации веб-перехватчиков в Kyverno, ознакомьтесь со статьей об устранении неполадок в Kyverno.
Заявление об отказе от ответственности за контактные данные сторонней организации
Корпорация Майкрософт предоставляет сторонние контактные данные, чтобы помочь вам найти дополнительные сведения по этой теме. Эти данные могут быть изменены без предварительного уведомления. Корпорация Майкрософт не гарантирует точность контактной информации сторонних поставщиков.
Заявление об отказе от ответственности за сведения о продуктах сторонних производителей
В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.