Устранение неполадок с сервером API и т. д. в AKS

Сводка

Эта статья поможет устранить неполадки с сервером API и т. д. в крупных развертываниях Службы Azure Kubernetes (AKS).

Корпорация Майкрософт проверяет надежность и производительность сервера API в масштабе 5000 узлов и 200 000 модулей pod. Кластер, содержащий сервер API, может автоматически масштабироваться и обеспечивать цели уровня обслуживания Kubernetes (SLOs). Если возникают высокая задержка или время ожидания соединения, причина, скорее всего, утечка ресурсов в распределенном etc каталоге (etcd) или проблемный клиент, инициирующий чрезмерное количество вызовов API.

Prerequisites

• Интерфейс командной строки Azure.

• Средство Kubernetes kubectl . Чтобы установить kubectl с помощью Azure CLI, выполните команду az aks install-cli .

• AKS журналы диагностики (в частности, события kube-audit), которые включены и затем отправляются в рабочую область Log Analytics. Чтобы определить, собираются ли журналы с помощью режима диагностикидля конкретных ресурсов или Azure, проверьте колонку "Параметры диагностики" на портале Azure.

• Уровень "Стандартный" для кластеров AKS. Если вы используете уровень "Бесплатный", сервер API и т. д. содержат ограниченные ресурсы. Кластеры AKS на уровне "Бесплатный" не обеспечивают высокий уровень доступности. Это условие часто является основной причиной проблем с сервером API и т. д.

• Плагин kubectl-aks для выполнения команд непосредственно на узлах AKS, в обход контрольной плоскости Kubernetes.

Основные проверки работоспособности

• Проверка событий работоспособности ресурсов

  AKS предоставляет события работоспособности ресурсов для простоя критически важных компонентов. Прежде чем продолжить, убедитесь, что Состояние ресурса не сообщает о критических событиях.

  

• Диагностика и решение проблем

  AKS предоставляет выделенную категорию устранения неполадок для доступности и производительности кластера и управляющей плоскости.

  

Symptoms

В следующей таблице описаны распространенные симптомы сбоев сервера API.

Причина и разрешение

Причина 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 и указанным узлом, в частности для его базового экземпляра масштабируемого набора.

Решение 1. Исправление политики сети для удаления блокировки трафика

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

Причина 2. Настраиваемый webhook вызывает взаимоблокировку в pod сервера API.

Настраиваемый веб-перехватчик, такой как Kyverno, может вызвать взаимоблокировку в подах сервера 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

AKSControlPlane
| where TimeGenerated between(now(-1h)..now())
| where Category=="kube-apiserver"
| where Message contains "Failed calling webhook, failing closed"
| limit 100
| project TimeGenerated, Level, Message

AzureDiagnostics
| where TimeGenerated between(now(-1h)..now())  // When you experienced the problem
| where Category == "kube-apiserver" 
| where log_s  contains "Failed calling webhook, failing closed"
| extend event = parse_json(log_s) 
| limit 100
| project TimeGenerated, event, Category

В этом примере проверяющий webhook блокирует создание некоторых объектов сервера API. Так как этот сценарий может возникать во время начальной загрузки, невозможно создать сервер API и модули pod Konnectivity. Поэтому вебхук не может подключиться к этим подам в Kubernetes. Эта последовательность событий вызывает взаимоблокировку и сообщение об ошибке.

Решение 2. Удаление конфигураций веб-перехватчика

Чтобы устранить эту проблему, удалите проверку и изменение конфигураций веб-перехватчика. Чтобы удалить эти конфигурации вебхуков в Kyverno, ознакомьтесь со статьей по устранению неполадок Kyverno.

Причина 3: клиент создаёт утечку объектов etcd и вызывает замедление etcd.

Распространенная ситуация заключается в том, что объекты постоянно создаются, даже если существующие неиспользуемые объекты в базе данных etcd не удаляются. Эта ситуация может привести к проблемам с производительностью, если etcd обрабатывает слишком много объектов (более 10 000) любого типа. Быстрое увеличение изменений таких объектов также может привести к превышению размера базы данных etcd по умолчанию (по умолчанию восемь (8) гигабайтов.

Чтобы проверить использование базы данных 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. База данных etcd с размером больше двух гигабайт считается большой базой данных etcd db.

Решение 3. Определение квот для создания объектов, удаления объектов или ограничения времени существования объектов в etcd

Чтобы предотвратить переполнение etcd и избежать простоя кластера, ограничьте максимальное количество создаваемых ресурсов. Вы также можете замедлить количество исправлений, создаваемых для экземпляров ресурсов. Чтобы ограничить количество создаваемых объектов, определите квоты объектов.

Если вы определяете объекты, которые больше не используются, но используют ресурсы, рассмотрите возможность их удаления. Например, удалите завершенные задания, чтобы освободить место:

kubectl delete jobs --field-selector status.successful=1

Для объектов, поддерживающих автоматическую очистку, задайте значения времени жизни (TTL), чтобы ограничить время существования этих объектов. Вы также можете пометить объекты таким образом, чтобы можно было массово удалить все объекты определенного типа с помощью селекторов меток. При установке ссылок владельца между объектами все зависимые объекты автоматически удаляются после удаления родительского объекта.

Также см. решение 6 для методов уменьшения размера объектов.

Причина 4. Применена управляемая защита сервера API AKS

Если вы видите высокую скорость ошибок HTTP 429, одна из возможных причин заключается в том, что AKS применяет управляемую защиту сервера API. AKS применяет эту защиту с помощью FlowSchema и PriorityLevelConfiguration с именем aks-managed-apiserver-guard. Эта защита активируется, когда сервер API сталкивается с частыми событиями вне памяти (OOM) после того, как усилия по масштабированию сервера API не смогли его стабилизировать. Эта защита выступает в качестве меры последней надежды для защиты сервера API, путем ограничения запросов не системных клиентов к серверу API и предотвращения его полной неотзывчивости.

• Проверьте кластер для присутствия "aks-managed-apiserver-guard" FlowSchema и PriorityLevelConfiguration или проверьте события Kubernetes.

kubectl get flowschemas
kubectl get prioritylevelconfigurations

• Проверьте события Kubernetes.

kubectl get events -n kube-system aks-managed-apiserver-throttling-enabled

Решение 4. Определение неоптимизированных клиентов и устранение рисков

Шаг 1. Определение неоптимизированных клиентов

• См. статью "Причина 5 " для выявления проблемных клиентов и уточнения шаблонов вызовов LIST, особенно тех клиентов, которые создают запросы с высокой частотой или высокой задержкой, так как они являются основными участниками снижения уровня сервера API. См. рекомендации по оптимизации клиентов для получения дополнительных указаний.

Шаг 2. Устранение рисков

• Уменьшите масштаб кластера, чтобы уменьшить нагрузку на сервер API.
• Если шаг 1 определяет недавно добавленный контроллер, CRD или DaemonSet в качестве основного драйвера перегрузки сервера API, удалите связанный объект из кластера.
• Используйте метрики уровня управления для мониторинга нагрузки на сервере API. Дополнительные сведения см. в блоге .
• После выполнения описанных выше действий удалите aks-managed-apiserver-guard.

kubectl delete flowschema aks-managed-apiserver-guard
kubectl delete prioritylevelconfiguration aks-managed-apiserver-guard

• Вы также можете изменить aks-managed-apiserver-guard FlowSchema и PriorityLevelConfiguration , применив метку aks-managed-skip-update-operation: true. Эта метка сохраняет измененные конфигурации и предотвращает их повторное согласование с значениями по умолчанию AKS. Это важно, если вы применяете настраиваемую схему потока (FlowSchema) и конфигурацию уровня приоритета (PriorityLevelConfiguration), адаптированную к требованиям вашего кластера, как указано в решении 5b, и не хотите, чтобы AKS автоматически управлял клиентским ограничением.

kubectl label prioritylevelconfiguration aks-managed-apiserver-guard aks-managed-skip-update-operation=true
kubectl label flowschema aks-managed-apiserver-guard aks-managed-skip-update-operation=true

Причина 5. Нарушающий клиент делает чрезмерные вызовы LIST или PUT

Если etcd не перегружен слишком большим количеством объектов, как определено в причине 3, то клиент-нарушитель может совершать слишком много LIST или PUT вызовов к серверу 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_

AzureDiagnostics
| where TimeGenerated between(now(-1h)..now())  // When you experienced the problem
| where Category == "kube-audit" 
| extend event = parse_json(log_s) 
| extend User = tostring(event.user.username) 
| summarize count() by User 
| top 10 by count_ 
| project User, count_ 

Хотя это полезно знать, какие клиенты создают самый высокий объем запросов, большой объем запросов может не быть причиной для беспокойства. Задержка ответа, которую клиенты испытывают, является лучшим индикатором фактической нагрузки, которую каждый из них создает на сервере API.

Шаг 2. Определение и анализ задержки для агента пользователя

Использование диагностики и решения на портале Azure

AKS теперь предоставляет встроенный анализатор, детектор ресурсоемких LIST вызовов API Server, чтобы помочь определить процессы, выполняющие такие вызовы. Эти вызовы являются основной причиной проблем с производительностью сервера API и т. д.

Чтобы получить доступ к детектору, выполните следующие действия.

1. Откройте кластер AKS на портале Azure.
2. Перейдите к разделу "Диагностика и решение проблем".
3. Выберите доступность и производительность кластера и плоскости управления.
4. Выберите детектор интенсивного использования ресурсов сервера API.

Детектор анализирует последние действия сервера API и выделяет агенты или рабочие нагрузки, которые создают большие или частые вызовы LIST. Он содержит сводку потенциальных эффектов, таких как время ожидания запроса, увеличение числа ошибок "408" и "503", нестабильности узлов, сбоев проб работоспособности и OOM-Kills на сервере API или т. д.

Интерпретация выходных данных детектора

• Summary:
  Указывает, обнаружены ли ресурсоемкие вызовы LIST и описываются возможные последствия для кластера.
• Окно анализа:
  Отображает проанализированное 30-минутное окно с пиковой памятью и загрузкой ЦП.
• Типы чтения:
  Объясняет, обслуживались ли вызовы метода LIST из кэша сервера API (предпочтительно) или требовали извлечения из etcd (наиболее значительное влияние).
• Диаграммы и таблицы:
  Определите, какие агенты, пространства имен или рабочие нагрузки создают наиболее ресурсоемкие вызовы LIST.

Использование журналов

Чтобы определить среднюю задержку запросов сервера 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

AzureDiagnostics
| where TimeGenerated between(now(-1h)..now())  // When you experienced the problem
| where Category == "kube-audit" 
| extend event = parse_json(log_s) 
| extend User = tostring(event.user.username)
| extend start_time = todatetime(event.requestReceivedTimestamp)
| extend end_time = todatetime(event.stageTimestamp)
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize avg(latency) by User, bin(start_time, 5m) 
| render timechart 

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

Шаг 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

AzureDiagnostics
| where TimeGenerated between(now(-1h)..now())  // When you experienced the problem
| where Category == "kube-audit" 
| extend event = parse_json(log_s) 
| extend HttpMethod = tostring(event.verb) 
| extend Resource = tostring(event.objectRef.resource) 
| extend User = tostring(event.user.username) 
| where User == "DUMMYUSERAGENT"  // Filter by name of the useragent you are interested in
| where Resource != ""
| extend start_time = todatetime(event.requestReceivedTimestamp)
| extend end_time = todatetime(event.stageTimestamp)
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize p99latency=percentile(latency, 99) by HttpMethod, Resource 
| render table  

Результаты этого запроса могут помочь вам определить типы вызовов API, которые не соответствуют вышестоящим SLO (Целям Уровня Обслуживания) Kubernetes. В большинстве случаев клиент-нарушитель выполняет слишком много LIST вызовов для большого набора объектов или слишком больших объектов. Ограничения масштабируемости сервера API или т. д. являются многомерными и описаны в пороговых значениях масштабируемости Kubernetes.

Решение 5a. Настройка шаблона вызова API

Чтобы уменьшить давление на плоскость управления, рассмотрите возможность настройки шаблона вызова сервера API клиента. Ознакомьтесь с рекомендациями.

Решение 5b: Ограничение клиента, перегружающего контрольную плоскость

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

В следующей процедуре показано, как ограничить API списка Pods клиента, задав пять одновременных вызовов:

1. Создайте 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 
   

2. Создайте конфигурацию с низким приоритетом для регулирования плохих вызовов API клиента:

   apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
   kind: PriorityLevelConfiguration
   metadata:
     name: very-low-priority
   spec:
     limited:
       assuredConcurrencyShares: 5
       limitResponse:
         type: Reject
     type: Limited
   

3. Обратите внимание на регулирование вызова в метриках сервера API:

   kubectl get --raw /metrics | grep "restrict-bad-client"
   

Причина 6. Высокое использование памяти etcd (по данным оповещения)

Может появиться оповещение о том, что использование памяти etcd превышает 20 ГиБ. Это оповещение указывает на то, что кластер испытывает интенсивную нагрузку на сервер API. Нагрузка может каскадно воздействовать и перегружать емкость памяти etcd. Если чрезмерная нагрузка не устранена быстро, это может привести к снижению производительности или сбоям.

Чтобы проверить текущее использование памяти etcd и понять конкретные факторы, которые влияют на его высокое потребление, перейдите в раздел «Диагностика и устранение проблем» на портале Azure. Запустите анализатор производительности etcd , выполнив поиск по запросу "etcd performance" в поле поиска. Анализатор показывает разбивку использования памяти и помогает определить, является ли причина проблемы высокой скоростью запросов, большим количеством объектов или большими размерами объектов.

Основная причина высокого использования памяти etcd обычно заключается в интенсивной загрузке сервера API. Эта проблема перекрывает другие причины, которые обсуждаются в этой статье. Чтобы определить конкретную проблему, влияющую на кластер, используйте следующее решение.

Решение 6. Использование существующих средств диагностики для выявления и устранения основной причины

Определение основного фактора вклада

Оповещение о памяти etcd может активироваться вследствие любой комбинации факторов. Определите, какой фактор является наиболее проблематичным в вашей ситуации.

• Если определены чрезмерные вызовы LIST или PUT: выполните решение Причины 5 для настройки шаблонов вызовов API или ограничения проблемных клиентов.

• Если слишком много объектов хранятся в etcd: выполните решение "Причина 3 ", чтобы очистить объекты и реализовать политики хранения.

• Если большие объекты используют чрезмерную память: сосредоточьтесь на следующих методах уменьшения размера объектов.

  • Чтобы уменьшить размеры спецификаций pod, переместите переменные среды из спецификаций pod в ConfigMaps.
  • Разделение больших секретов или ConfigMaps на более мелкие, более управляемые части.
  • Просмотрите и оптимизируйте спецификации ресурсов в приложениях.
  • Уменьшите количество версий.

  # Example: Clean up completed jobs that may have large specifications
  kubectl delete jobs --field-selector status.successful=1
  
  # Example: Clean up failed pods that may be consuming memory
  kubectl delete pods --field-selector status.phase=Failed
  

Заявление об отказе от ответственности за контактные данные сторонней организации

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

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

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