Как найти и устранить неполадки в Kubernetes
Сложность самой системы и отсутствие хоть сколько-нибудь подробной информации о возникающих ошибках усугубляют и без того нетривиальный процесс диагностики в работе платформы. Неполадки в Kubernetes решаются путем выявления, диагностики и решения проблем, возникающих в кластерах, узлах, модулях или контейнерах.
В более широком смысле устранение неполадок Kubernetes также включает эффективное управление сбоями и принятие мер для предотвращения проблем в компонентах Kubernetes.
В некоторых случаях неполадки могут быть вызваны целым комплексом проблем. В руководстве ниже мы сосредоточим внимание на наиболее важных аспектах для решения этих проблем:
- Исправление распространенных ошибок: CreateContainerConfigError, ImagePullBackOff, CrashLoopBackOff и Kubernetes Node Not Ready;
- Первичная диагностика проблем в подах и кластерах Kubernetes;
- Поиск и работа с логами и другой информацией, необходимой для более глубокого анализа.
Три «столпа» устранения неполадок в Kubernetes
Для эффективного устранения неполадок в кластере Kubernetes условно весь процесс траблшутинга можно представить основанным на трех ключевых подпунктах: понимание самой проблемы, управление и устранение неполадки, а также предотвращение повторения проблемы в будущем.
Понимание сути проблемы
В среде Kubernetes порой может быть довольно сложно выяснить, что произошло, и определить основную причину проблемы. Как правило, для этого требуется ряд некоторых действий:
- Просмотр последних изменений в рассматриваемом кластере, модуле или узле с целью выяснения причины, которая в итоге и вызвала сбой;
- Анализ конфигураций YAML, репозиториев GitHub и логов виртуальных машин, на которых запущены неисправные компоненты;
- Просмотр событий и показателей Kubernetes, таких как занятое дисковое пространство, нехватка памяти и использование других ресурсов. В готовой среде у вас должен быть доступ к панелям мониторинга, которые показывают важные метрики для кластеров, узлов, модулей и контейнеров с течением времени;
- Сравнение похожих компонентов, выполняющих схожие процессы, и анализ зависимостей между компонентами.
В идентификации проблемы может помочь комплексное использование целого ряда инструментов, среди них:
- Софт для мониторинга: Datadog, Dynatrace, Grafana, New Relic;
- Инструменты наблюдения: Lightstep, Honeycomb;
- Софт для отладки в режиме реального времени: OzCode, Rookout;
- Инструменты логирования: Splunk, LogDNA, Logz.io.
Управление
В архитектуре микросервисов обычно каждый компонент разрабатывается и управляется отдельной командой разработчиков. Поскольку производственные инциденты часто связаны с взаимодействием между несколькими компонентами, наличие контакта между разработчиками необходимо для быстрого устранения проблем.
Есть три подхода к устранению выявленной проблемы:
- «Ad hoc решения» - основанные на знаниях разработчиков, работающими над затронутыми компонентами. Очень часто инженер, создавший компонент, имеет целостное представление и знания о том, как его отлаживать и решать возникшие неполадки.
- Ручные модули Runbook - документированная процедура, описывающая, как разрешить каждую из неполадок. Наличие модуля Runbook означает, что каждый разработчик может быстро решить проблему.
- Автоматизированные модули Runbook - автоматизированный процесс, запускающийся автоматически при обнаружении проблемы, который может быть реализован в виде сценария, шаблона инфраструктуры как кода (IaC) или оператора Kubernetes. Автоматизировать реагирование на все распространенные ошибки может оказаться довольно сложной задачей с точки зрения реализации, однако это позволит существенно сократить время простоя и устранить человеческий фактор.
Для достижения высоких стандартов по управлению команды разработчиков обычно используют следующие технологии:
- Управление инцидентами: PagerDuty, Kintaba;
- Управление проектом: Jira, Monday, Trello;
- Инфраструктура как код (IaC): Amazon CloudFormation, Terraform.
Профилактика
На примере наиболее успешных проектов ясно, что предотвращение проблем вносит наибольший вклад в траблшутинг и позволяет заранее ликвидировать многие ошибки в Kubernetes. Превентивный подход значительно сократит время, затрачиваемое на выявление и устранение новых проблем. Профилактика, как правило, включает в себя перечень следующих действий:
- Создание политик, правил и сценариев на случай каждого инцидента;
- Изучение того, можно ли автоматизировать ответ на проблему и как;
- Выяснение того, как быстро можно определить проблему в следующий раз и сделать соответствующие данные доступными - например, путем инструментального анализа соответствующих компонентов;
- Делегирование решения проблемы соответствующим группам разработчиков;
Технологии, которые зачастую используются для предотвращения проблем:
- Хаос инженерия: Gremlin, Chaos Monkey, ChaosIQ;
- Автоисправление: Shoreline, OpsGenie.
Почему устранить ошибки в Kubernetes так непросто?
Kubernetes - сложная система, и устранение неполадок, возникающих где-то в кластере Kubernetes, требует немало усилий и времени.
Даже в небольшом локальном кластере Kubernetes проблема может быть сложно диагностируемой, поскольку она может быть локализована в отдельном контейнере, в одном или нескольких модулях, контроллере или где-либо еще.
Что еще хуже, Kubernetes часто используется для создания приложений микросервисов, в которых каждый микросервис разрабатывается отдельной командой. В других случаях команды разработки приложений и DevOps работают в одном кластере Kubernetes, что негативно сказывается на разделении ответственности.
Таким образом, в Kubernetes настройка системы может быстро превратиться в хаос, результатом чего станут лишние затраты ресурсов и снижение функциональности приложений. Всего этого можно избежать, если разработчики будут тесно координировать свои действия и использовать набор необходимых инструментов.
Устранение распространенных ошибок Kubernetes
Если вы столкнулись с распространенной ошибкой в Kubernetes, проблема наверняка широко изучена другими разработчиками. Вот лишь часть таких ошибок, решение которых мы приведем ниже:
- CreateContainerConfigError;
- ImagePullBackOff или ErrImagePull;
- CrashLoopBackOff;
- Kubernetes Node Not Ready.
CreateContainerConfigError
Эта ошибка обычно возникает из-за отсутствия Secret или ConfigMap. Secrets - это объекты Kubernetes, используемые для хранения конфиденциальной информации, как, например, учетные данные. ConfigMaps хранят данные в виде пар ключ-значение и обычно используются для хранения информации о конфигурации, используемой несколькими модулями.
Шаг I. Идентификация проблемы
Выполните команду
kubectl get pods
Изучите вывод команды, чтобы определить, имеет ли модуль статус CreateContainerConfigError.
Шаг II. Получение подробной информации и решение проблемы
Чтобы получить дополнительную информацию о проблеме, запустите команду
kubectl describe [name]
и найдите сообщение, указывающее, какая именно ConfigMap отсутствует.
Теперь запустите эту команду, чтобы увидеть, существует ли ConfigMap в кластере. Например:
$ kubectl get configmap configmap-3
Если результатом является null, то значит ConfigMap отсутствует, и вам необходимо его создать. Изучите документацию, чтобы узнать, как создать ConfigMap с именем, запрошенным вашим модулем.
Убедитесь, что ConfigMap доступен, снова запустив
get configmap [name]
Если вы хотите просмотреть содержимое ConfigMap в формате YAML, добавьте флаг -o yaml.
Убедившись, что ConfigMap существует, снова запустите
kubectl get pods
и убедитесь, что модуль находится в состоянии Running.
ImagePullBackOff или ErrImagePull
Этот статус означает, что модуль не удалось запустить, поскольку он попытался получить образ контейнера из реестра с ошибкой. Модуль отказывается запускаться, потому что он не может создать один или несколько контейнеров, определенных в его манифесте.
Шаг I. Идентификация проблемы
Выполните команду
kubectl get pods
Проверьте вывод команды, чтобы узнать, имеет ли модуль статус ImagePullBackOff или ErrImagePull.
Шаг II. Получение подробной информации и решение проблемы
Выполните команду
kubectl describe pod [name]
для проблемного модуля.
В выходных данных этой команды будет указана основная причина проблемы. Результатом может оказаться одна из следующих причин:
- Неверное имя или тег изображения. Обычно это происходит из-за того, что имя или тег изображения были неправильно введены в манифесте модуля. Проверьте правильность имени образа с помощью docker pull и исправьте его.
- Проблема аутентификации в реестре контейнеров. Модулю не удалось пройти аутентификацию в реестре для получения образа. Это могло произойти из-за проблемы с данными Secrets или из-за того, что модуль не имеет прав RBAC, которые позволили бы ему выполнить операцию. Убедитесь, что модуль и узел имеют соответствующие разрешения и выполните операцию вручную с помощью docker pull.
CrashLoopBackOff
Эта проблема указывает на то, что модуль не может быть запланирован на ноде. Это могло произойти из-за того, что у узла недостаточно ресурсов для запуска модуля, или из-за того, что модулю не удалось смонтировать запрошенные тома.
Шаг I. Идентификация проблемы
В Kubernetes настройка начинается стандартной командой
kubectl get pods
Проверьте результат вывода и определите, имеет ли модуль статус CrashLoopBackOff.
Шаг II. Получение подробной информации и решение проблемы
Выполните команду
kubectl describe pod [name]
для проблемного модуля.
Вывод поможет вам определить причину проблемы. Ниже приведены общие причины:
- Недостаточно ресурсов. Если на узле недостаточно ресурсов, вы можете вручную исключить модули из узла или масштабировать кластер, чтобы обеспечить доступность дополнительных узлов для ваших модулей.
- Подключение тома. Если вы видите, что проблема заключается в подключении тома хранилища, проверьте, какой том модуль пытается подключить. Убедитесь, что он правильно определен в манифесте модуля, и проверьте доступность тома хранилища.
- Использование hostPort - если вы привязываете модули к hostPort, вы можете запланировать только один модуль для каждого узла. В большинстве случаев вы можете избежать использования hostPort и использовать объект Service для обеспечения связи с вашим модулем.
Kubernetes Node Not Ready
Когда рабочий узел выключается или выходит из строя, все находящиеся на нем поды с отслеживанием состояния становятся недоступными, а статус узла отображается как NotReady.
Если узел находится в состоянии NotReady более пяти минут (по умолчанию), Kubernetes изменяет состояние запланированных на нем модулей на Unknown и пытается запланировать его на другом узле со статусом ContainerCreating.
Шаг I. Идентификация проблемы
Выполните команду
kubectl get nodes
Проверьте вывод команды и убедитесь, что статус узла - NotReady.
Чтобы проверить, перемещаются ли модули, запланированные на вашем узле, на другие узлы, выполните команду
get pods
Проверьте, появляется ли модуль дважды на двух разных узлах.
Шаг II. Решение проблемы
Если отказавший узел может восстановиться или перезагружается пользователем, проблема разрешится сама собой. После того, как отказавший узел восстанавливается и присоединяется к кластеру, происходит следующий процесс:
- Модуль со статусом Unknown удаляется, а тома отсоединяются от отказавшего узла.
- Модуль переносится на новый узел, его статус меняется с Unknown на ContainerCreating, и требуемые тома присоединяются.
- Kubernetes использует пятиминутный тайм-аут (по умолчанию), по истечении которого модуль будет запущен на узле, а его статус изменится с ContainerCreating на Running.
