Устранение неполадок рабочих нагрузок

Введение

Развёртывание не всегда проходит по плану. Когда что-то ломается, нужен последовательный и воспроизводимый метод поиска неисправностей.

В этой лабораторной работе вы раскроете дело «Таинственное исчезновение образа».

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

Вы выполните следующие действия:

Создадите место преступления: намеренно развернёте неисправный Pod.
Проведёте расследование: с помощью «бинокля» (get) обнаружите, что что-то не так.
Соберёте улики: с помощью «лупы» (describe) найдёте корневую причину.
Раскроете дело: исправите конфигурацию и проследите за восстановлением приложения.

Создание неисправного Pod

Сначала мы развернём Pod с намеренной опечаткой. Это имитирует распространённую ошибку: указание образа, которого не существует.

Это хороший пример того, что Kubernetes принимает многие манифесты, а проблемы в них обнаруживаются только позже. YAML-файл может быть синтаксически корректным, но при этом непригодным для работы. Поэтому при устранении неполадок нужно отдельно проверять: «Объект принят?» и «Действительно ли рабочая нагрузка запустилась правильно?».

Создайте файл с именем broken-pod.yaml:

nano broken-pod.yaml

Вставьте в него следующий текст. Обратите внимание на подозрительный тег образа wrongtag123.

apiVersion: v1
kind: Pod
metadata:
  name: broken-pod
spec:
  containers:
    - name: nginx
      image: nginx:wrongtag123

Сохраните файл и выйдите из редактора (Ctrl+X, Y, Enter).

Разверните Pod:

kubectl apply -f broken-pod.yaml

Kubernetes принимает файл, потому что формат YAML корректен. «Преступление» пока ещё не обнаружено.

Наблюдение за сбоем

Теперь посмотрим на состояние развёрнутого объекта. Это похоже на осмотр места происшествия в бинокль.

Такие состояния, как ErrImagePull и ImagePullBackOff, являются симптомами, а не окончательными объяснениями. Они показывают, в каком направлении нужно продолжить расследование. Грамотное устранение неполадок начинается с анализа состояния, но не ограничивается им.

Проверьте Pod в пространстве имён default:

kubectl get pods

Сначала вы можете увидеть состояние ContainerCreating, но через несколько секунд оно, скорее всего, изменится на ImagePullBackOff или ErrImagePull.

ImagePullBackOff на языке Kubernetes означает: «Я попытался загрузить этот образ, но не смог. Я подожду некоторое время и попробую снова позже».

Это подтверждает, что пострадавший объект — Pod — работает неправильно.

Просмотр событий

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

Команда kubectl describe — это ваша лупа. Она показывает внутренние события и журналы определённого ресурса.

Раздел Events особенно полезен: в нём сохраняется краткая последовательность действий компонентов Kubernetes, таких как планировщик и kubelet. Если начинающие сразу начинают наугад исправлять конфигурацию, не изучив события, они часто тратят время на решение не той проблемы.

Изучите неисправный Pod:

kubectl describe pod broken-pod

Команда выведет много данных. Прокрутите вывод до самого конца и найдите раздел Events.

Вы должны увидеть примерно следующее:

Type     Reason     Message
----     ------     -------
Normal   Pulling    Pulling image "nginx:wrongtag123"
Warning  Failed     Failed to pull image "nginx:wrongtag123": manifest unknown
Warning  Failed     Error: ErrImagePull

Сообщение manifest unknown — ключевая улика. Оно означает, что в реестре Docker, где хранятся образы, нет записи об образе nginx:wrongtag123.

Дело раскрыто: тег образа указан неверно.

Исправление Pod

Теперь, когда корневая причина известна, можно исправить проблему.

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

Снова откройте файл broken-pod.yaml:

nano broken-pod.yaml

Исправьте «опечатку». Замените nginx:wrongtag123 на просто nginx — в этом случае по умолчанию будет использован корректный образ nginx:latest.

apiVersion: v1
kind: Pod
metadata:
  name: broken-pod
spec:
  containers:
    - name: nginx
      image: nginx

Сохраните файл и выйдите из редактора.

Примените исправление. Kubernetes достаточно умён, чтобы обновить существующий Pod с учётом новых данных.

kubectl apply -f broken-pod.yaml

Теперь проследите за восстановлением:

kubectl get pods -w

Вы должны увидеть, как состояние изменится с ImagePullBackOff на Running.

Нажмите Ctrl+C, чтобы прекратить наблюдение.

Отличная работа, детектив! Вы нашли ошибку и успешно восстановили работу сервиса.

Итоги

В этой лабораторной работе вы изучили основной рабочий процесс устранения неполадок в Kubernetes:

Наблюдение: выполните kubectl get pods, чтобы найти неисправные рабочие нагрузки.
Исследование: используйте kubectl describe pod, чтобы просмотреть журнал событий и найти сообщения об ошибках.
Исправление: обновите YAML-манифест и примените исправления.

Этот процесс — Get, Describe, Fix — поможет решить 90% проблем развёртывания, с которыми вы столкнётесь в своей карьере, работая с Kubernetes.