Устранение неполадок с изменением работоспособного узла на состояние "Не готово"

  • Статья

В этой статье рассматривается сценарий, в котором состояние узла кластера Служба Azure Kubernetes (AKS) изменяется на Not Ready после того, как узел находится в работоспособном состоянии в течение некоторого времени. В этой статье описывается конкретная причина и предоставляется возможное решение.

Предварительные требования

Симптомы

Состояние узла кластера с состоянием работоспособности (все службы, работающие) неожиданно изменяется на "Не готово". Чтобы просмотреть состояние узла, выполните следующую команду kubectl:

kubectl describe nodes

Причина

Kubelet перестал публиковать состояние "Готово".

Просмотрите выходные данные kubectl describe nodes команды, чтобы найти поле "Условия " и блоки емкости и выделения . Отображается ли содержимое этих полей должным образом? (Например, в Поле условийmessage, содержит ли свойство "kubelet публикует состояние готовности"?) В этом случае, если у вас есть прямой доступ к узлу Secure Shell (SSH), проверьте последние события, чтобы понять ошибку. Просмотрите файл /var/log/messages . Или создайте файлы журнала управляющей программы kubelet и контейнера, выполнив следующие команды оболочки:

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

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

Решение

Шаг 1. Проверка изменений на уровне сети

Если все узлы кластера регрессируют в состояние "Не готово ", проверьте, произошли ли изменения на уровне сети. Ниже приведены примеры изменений на уровне сети:

  • Изменения в службе доменных имен (DNS)
  • Изменения правил брандмауэра, такие как порт, полные доменные имена (FQDN) и т. д.
  • Добавлены группы безопасности сети (NSG)
  • Применены или изменены конфигурации таблиц маршрутов для трафика AKS

Если на уровне сети были изменения, внесите необходимые исправления. Если у вас есть прямой доступ к узлу Secure Shell (SSH), можно использовать curl или telnet команду для проверки подключения к требованиям к исходящему трафику AKS. После устранения проблем остановите и перезапустите узлы. Если узлы остаются в работоспособном состоянии после этих исправлений, вы можете безопасно пропустить оставшиеся шаги.

Шаг 2. Остановка и перезапуск узлов

Если только несколько узлов регрессировали в состояние "Не готово ", просто остановите и перезапустите узлы. Одно только это действие может вернуть узлы в работоспособное состояние. Затем проверьте Служба Azure Kubernetes диагностика обзоре, чтобы определить, существуют ли какие-либо проблемы, такие как следующие проблемы:

  • Ошибки узлов
  • Сбои преобразования исходных сетевых адресов (SNAT)
  • Проблемы с производительностью операций ввода-вывода узла в секунду (IOPS)
  • Другие проблемы

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

Шаг 3. Устранение проблем SNAT для общедоступных кластеров API AKS

Были ли диагностика AKS обнаружены какие-либо проблемы СNAT? В этом случае выполните некоторые из следующих действий, как это необходимо:

  • Проверьте, остается ли подключение неактивным в течение длительного времени и зависит от времени ожидания простоя по умолчанию, чтобы освободить свой порт. Если подключения демонстрируют это поведение, может потребоваться сократить время ожидания по умолчанию в течение 30 минут.

  • Определите, как приложение создает исходящее подключение. Например, использует ли он проверку кода или запись пакетов?

  • Определите, представляет ли это действие ожидаемое поведение или, вместо этого, показано, что приложение работает неправильно. Для подтверждения результатов используйте метрики и журналы Azure Monitor, Например, можно использовать категорию "Сбой " в качестве метрики подключений SNAT.

  • Оцените, следует ли следовать соответствующим шаблонам.

  • Оцените, следует ли устранять нехватку портов SNAT с помощью дополнительных исходящих IP-адресов и большего количества выделенных исходящих портов. Дополнительные сведения см. в статье Масштабирование количества общедоступных IP-адресов управляемого исходящего трафика и настройка выделенных исходящих портов.

Дополнительные сведения об устранении неполадок с эксхаутированием портов SNAT см. в разделе "Устранение неполадок с исчерпанием портов SNAT" на узлах AKS.

Шаг 4. Устранение проблем с производительностью операций ввода-вывода в секунду

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

  • Чтобы увеличить количество операций ввода-вывода в секунду на масштабируемых наборах виртуальных машин, выберите больший размер диска, который обеспечивает более высокую производительность операций ввода-вывода в секунду, развернув новый пул узлов. Прямое изменение размера vmSSS напрямую не поддерживается. Дополнительные сведения об изменении размера пулов узлов см. в разделе "Изменение размера пулов узлов" в Служба Azure Kubernetes (AKS).

  • Увеличьте размер SKU узла, чтобы получить больше памяти и вычислительных возможностей ЦП.

  • Рассмотрите возможность использования эфемерной ОС.

  • Ограничение использования ЦП и памяти для модулей pod. Эти ограничения помогают предотвратить потребление ресурсов ЦП узлом и ситуации нехватки памяти.

  • Используйте методы топологии планирования, чтобы добавить больше узлов и распределить нагрузку между узлами. Дополнительные сведения см. в разделе "Ограничения распространения топологии Pod".

Шаг 5. Устранение проблем с потоком

Такие компоненты Kubernetes, как kubelets и контейнерные среды выполнения , сильно зависят от потоков, и они регулярно порождают новые потоки. Если выделение новых потоков не удалось, этот сбой может повлиять на готовность службы следующим образом:

  • Состояние узла изменяется на Not Ready, но оно перезапущено исправлением и может восстановиться.

  • В файлах журнала /var/log/messages и /var/log/syslog существуют повторяющиеся вхождения следующих записей об ошибках:

    ошибка pthread_create: ресурс временно недоступен для различных процессов

    К процессам, которые приводятся, относится containerd и, возможно, kubelet.

  • Состояние узла изменится на Not Ready вскоре после pthread_create записи сбоя в файлы журнала.

Идентификаторы процессов (PID) представляют потоки. Количество PID по умолчанию, которое может использовать модуль, может зависеть от операционной системы. Однако количество по умолчанию составляет не менее 32 768. Этого количества PID более чем достаточно для большинства ситуаций. Существуют ли какие-либо известные требования к приложению для более высоких ресурсов PID? Если их нет, то даже восьмикратного увеличения до 262 144 PID может быть недостаточно для размещения приложения с высокими ресурсами.

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

Чтобы отслеживать количество потоков для каждой группы управления (cgroup) и распечатать восемь верхних групп, выполните следующую команду оболочки:

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

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

Kubernetes предлагает два метода управления нехваткой PID на уровне узла:

  1. Настройте максимальное количество идентификаторов идентификаторов, разрешенных в модуле pod в kubelet, с помощью --pod-max-pids параметра. Эта конфигурация задает pids.max параметр в группе cgroup каждого модуля pod. Можно также использовать --system-reserved параметры и параметры для настройки системных и --kube-reserved kubelet ограничений соответственно.

  2. Настройте вытеснение на основе PID.

Примечание.

По умолчанию ни один из этих методов не настроен. Кроме того, в настоящее время нельзя настроить любой метод с помощью конфигурации узла для пулов узлов AKS.

Шаг 6. Использование более высокого уровня служб

Вы можете убедиться, что сервер API AKS имеет высокий уровень доступности с помощью более высокого уровня служб. Дополнительные сведения см. в разделе об уровне обслуживания об уровне обслуживания Служба Azure Kubernetes (AKS).

Дополнительная информация