Введение
Отладка Pod в Kubernetes может показаться сложной задачей, особенно на Linux-системах. В этом руководстве мы рассмотрим конкретные шаги, которые помогут вам быстро диагностировать проблемы, просмотреть логи и восстановить работоспособность кластера. После выполнения инструкций вы сможете самостоятельно устранять распространённые ошибки, такие как CrashLoopBackOff, ImagePullBackOff и другие.
Требования
- Операционная система: Linux (например, Ubuntu 22.04 LTS или Debian 12)
- Kubernetes: версия 1.28 (или более новая)
- kubectl: версия 1.28 (или соответствующая версии кластера)
- Права доступа: учётная запись с правами
cluster-adminили владения нужного Namespace - Инструменты:
kubectl,helm(если используется),kubectx(необязательно)
Пошаговая инструкция
Шаг 1: Установите необходимые инструменты
Убедитесь, что на системе присутствуют требуемые клиенты. В Ubuntu/Debian это можно сделать через пакетный менеджер:
sudo apt update
sudo apt install -y kubectl helm kubectx
После установки проверьте версии:
kubectl version --client
helm version
kubectx --version
Шаг 2: Проверьте состояние кластера
Подтвердите, что kubectl подключён к нужному кластеру:
kubectl cluster-info
Если вы ещё не инициализировали кластер, выполните:
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
и присоедините worker-узлы с помощью команды, полученной от master-узла.
Шаг 3: Получите подробную информацию о Pod
Чтобы увидеть полную информацию о Pod, выполните:
kubectl describe pod <имя-пода> -n <namespace>
Обратите внимание на поля Status, Reason и блок Events. Эти данные помогут выявить точную причину проблем, например, ошибки Pull образа или сбой контейнера.
Шаг 4: Проверьте логи Pod
Текущие логи контейнера выводятся так:
kubectl logs pod/<имя> -n <namespace>
Если проблема возникла во время предыдущего запуска, добавьте флаг --previous:
kubectl logs pod/<имя> -n <namespace> --previous
💡 Совет: Используйте
grepдля фильтрации логов, напримерkubectl logs pod/<имя> | grep "ERROR".
Шаг 5: Восстановите проблемный Pod
Если Pod неисправен и его невозможно восстановить, удалите его. Kubernetes автоматически создаст новый экземпляр на основе текущего манифеста (Deployment, StatefulSet и т.д.):
kubectl delete pod <имя> -n <namespace>
Дождитесь, пока новый Pod перейдёт в состояние Running.
Проверка результата
После выполнения шагов убедитесь, что Pod работает:
kubectl get pod <имя> -n <namespace> -o wide
Ожидаемый статус — Running. Если Pod всё ещё находится в ошибочном состоянии, повторите шаги 3–5 и проверьте логи на предмет новых подсказок.
Возможные проблемы
| Симптом | Вероятная причина | Решение |
|---|---|---|
Pending → ContainerCreating занимает много времени | Недостаточно ресурсов на узле или недоступный образ | Проверьте ресурсные ограничения узла (kubectl describe node <имя-узла>) и убедитесь, что образ доступен (docker pull <образ>). |
ImagePullBackOff | Ошибка при загрузке образа (неверный пароль, несуществующий репозиторий) | Проверьте параметры imagePullSecrets или создайте нужный Secret (kubectl create secret docker-registry ...). |
CrashLoopBackOff | Контейнер постоянно падает при старте | Просмотрите логи (kubectl logs pod/<имя> --previous), исправьте код приложения или конфигурацию. |
ErrImagePull | Невозможно получить образ из реестра | Убедитесь, что DNS работает (nslookup registry.k8s.io), проверьте сетевые политики. |
NetworkUnreachable | Под не может получить доступ к внешним сервисам | Проверьте сетевые политики, убедитесь, что Pod находится в правильном Subnet, и проверьте iptables на узле. |
Если проблема не решена, выполните kubectl get events --field-selector involvedObject.name=<имя-пода> для получения дополнительных событий, которые могут указать на скрытые причины.