Устранение неполадок с сервером API и т. д. в Служба Azure Kubernetes
Это руководство предназначено для выявления и устранения маловероятных проблем, которые могут возникнуть на сервере API в крупных развертываниях Microsoft Служба Azure Kubernetes (AKS).
Корпорация Майкрософт проверила надежность и производительность сервера API в масштабе 5000 узлов и 200 000 модулей pod. Кластер, содержащий сервер API, имеет возможность автоматического масштабирования и доставки целей уровня обслуживания Kubernetes (SLOS). Если вы испытываете высокую задержку или время ожидания, вероятно, это связано с утечкой ресурсов в распределенном etc каталоге (т. д.), или у обижающего клиента чрезмерные вызовы API.
Предварительные требования
Средство Kubernetes kubectl . Чтобы установить kubectl с помощью Azure CLI, выполните команду az aks install-cli .
AKS диагностика журналы (в частности, события аудита kube), которые включены и отправляются в рабочую область Log Analytics. Чтобы определить, собираются ли журналы с помощью режима диагностика ресурсов или Azure, проверьте колонку "Параметры диагностики" в портал Azure.
Уровень "Стандартный" для кластеров AKS. Если вы используете уровень "Бесплатный", сервер API и т. д. содержат ограниченные ресурсы. Кластеры AKS на уровне "Бесплатный" не обеспечивают высокий уровень доступности. Это часто является основной причиной проблем с сервером API и т. д.
Подключаемый модуль kubectl-aks для выполнения команд непосредственно на узлах AKS без использования плоскости управления Kubernetes.
Основные проверки работоспособности
События работоспособности ресурсов
AKS предоставляет события работоспособности ресурсов для простоя критически важных компонентов. Прежде чем продолжить, убедитесь, что в Работоспособность ресурсов нет критических событий.
Диагностика и решение проблем
AKS предоставляет выделенную категорию устранения неполадок для доступности кластера и уровня управления и производительности.
Симптомы
В следующей таблице описаны распространенные симптомы сбоев сервера API.
| Симптом | Description |
|---|---|
| Время ожидания с сервера API | Частые тайм-ауты, которые выходят за рамки гарантий в уровне обслуживания сервера API AKS. Например, kubectl время ожидания команд. |
| Высокая задержка | Высокая задержка, из-за которую произошел сбой объектов SLO Kubernetes. Например, kubectl команда занимает более 30 секунд для перечисления модулей pod. |
Модуль 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 для заданного агента пользователя
Выполните следующий запрос, чтобы табуляции задержки вызовов API на уровне 99-го процента (P99) в разных типах ресурсов для данного клиента:
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 или т. д. зависят от различных факторов, описанных в порогах масштабируемости 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>
Команда импорта конфигурации извлекает сведения о масштабируемом наборе виртуальных машин для всех узлов в кластере. Затем команда check-apiserver-connectivity использует эти сведения для проверки сетевого подключения между сервером API и указанным узлом, в частности для его базового экземпляра масштабируемого набора.
Примечание.
Если выходные данные check-apiserver-connectivity команды содержат Connectivity check: succeeded сообщение, сетевое подключение не используется.
Решение 1. Исправление политики сети для удаления блокировки трафика
Если выходные данные команды указывают на то, что произошел сбой подключения, перенастройка политики сети, чтобы она не заблокировала трафик между узлами агента и сервером API.
Причина 2: обижающая утечка клиентов и т. д., что приводит к замедлению использования и т. д.
Распространенная проблема заключается в непрерывном создании объектов без удаления неиспользуемых объектов в базе данных 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
Если вы определяете, что т. д. не перегружены слишком большим количеством объектов, злоумышленник может делать слишком много LIST или PUT вызовы к серверу API.
Решение 3a. Настройка шаблона вызова API
Рассмотрите возможность настройки шаблона вызова API клиента, чтобы уменьшить давление на плоскости управления.
Решение 3b. Регулирование клиента, подавляющего плоскость управления
Если вы не можете настроить клиент, вы можете использовать функцию Приоритета и справедливости в Kubernetes для регулирования клиента. Эта функция может помочь сохранить работоспособность плоскости управления и предотвратить сбой других приложений.
В следующей процедуре показано, как обустрять api list pods клиента, установленного на пять одновременных вызовов:
Создайте 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Создайте конфигурацию с низким приоритетом для регулирования плохих вызовов 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": запись unix @->/tunnel-uds/proxysocket: запись: сломанная труба
В этом примере проверяющий веб-перехватчик блокирует создание некоторых объектов сервера API. Так как этот сценарий может возникать во время начальной загрузки, невозможно создать сервер API и модули pod Konnectivity. Поэтому веб-перехватчик не может подключиться к этим модулям pod. Эта последовательность событий вызывает взаимоблокировку и сообщение об ошибке.
Решение 4. Удаление конфигураций веб-перехватчика
Чтобы устранить эту проблему, удалите проверку и изменение конфигураций веб-перехватчика. Чтобы удалить эти конфигурации веб-перехватчика в Kyverno, ознакомьтесь со статьей по устранению неполадок Kyverno.
Заявление об отказе от ответственности за контактные данные сторонней организации
Корпорация Майкрософт предоставляет контактные данные сторонних производителей в целях получения дополнительных сведений по данной теме. Эти данные могут быть изменены без предварительного уведомления. Корпорация Майкрософт не гарантирует точность контактных данных сторонних производителей.
Заявление об отказе от ответственности за сведения о продуктах сторонних производителей
В этой статье упомянуты программные продукты независимых производителей. Корпорация Microsoft не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.