Диагностика и устранение проблем с подами и деплоями в Kubernetes: практическое руководство 2026

Введение: почему поды падают, а деплои зависают

CrashLoopBackOff, ImagePullBackOff, Pending, Failed. Эти статусы знакомы каждому DevOps-инженеру, который работает с Kubernetes. Проблема редко бывает уникальной: в 80% случаев сбой вызван типовой ошибкой конфигурации, нехваткой ресурсов или некорректной пробой. Эта статья даёт системный алгоритм диагностики и готовые команды для восстановления сервиса. Вы научитесь читать статусы подов, анализировать события кластера, работать с логами и откатывать неудачные деплои. Все примеры проверены на Kubernetes 1.29-1.32 и актуальны для production-сред 2026 года.

Материал построен как пошаговое руководство: от быстрой проверки статуса до продвинутых техник работы с событиями. Если вам нужна шпаргалка по командам, переходите к последнему разделу. Для углублённой диагностики через метрики мониторинга используйте руководство по диагностике Pods и узлов через Prometheus и Grafana.

Основы: как Kubernetes управляет подами и деплоями

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

Жизненный цикл пода: от создания до завершения

Под проходит пять основных фаз:

Pending - под создан, но ещё не запущен. Контейнеры не стартовали. Частая причина - нехватка ресурсов на узлах или проблемы с планировщиком.
Running - под назначен на узел, все контейнеры запущены. Это не означает готовность принимать трафик: readiness-проба может ещё не пройти.
Succeeded - все контейнеры завершились с кодом 0. Нормально для Job и CronJob.
Failed - хотя бы один контейнер завершился с ненулевым кодом.
CrashLoopBackOff - контейнер запускается, падает, перезапускается снова. Kubernetes увеличивает паузу между попытками: 10, 20, 40 секунд, до 5 минут.

Каждая фаза указывает на свой класс проблем. Pending - планирование. CrashLoopBackOff - приложение или конфигурация контейнера. ImagePullBackOff - доступ к реестру образов.

Роль Deployment и ReplicaSet в управлении подами

Deployment создаёт ReplicaSet, а ReplicaSet создаёт поды. Цепочка выглядит так: Deployment → ReplicaSet → Pod. При обновлении деплоя Kubernetes создаёт новый ReplicaSet и постепенно масштабирует его, уменьшая старый. Если новый под не проходит readiness-пробу, rolling update зависает: старый ReplicaSet не уменьшается, новый не становится готовым. Проблема с деплоем часто кроется не в самом деплое, а в конфигурации подов, которые он создаёт.

Для понимания того, как контроллеры обрабатывают изменения и почему деплой может застрять, рекомендую разбор архитектуры контроллеров Kubernetes: от watch до reconcile loop.

Диагностика проблем с подами: пошаговый алгоритм

Порядок действий важен. Начинайте с общего состояния, затем сужайте поиск до конкретного контейнера и его логов. Этот алгоритм покрывает 90% инцидентов.

Шаг 1: Проверка статуса пода с помощью kubectl get pods

Первая команда при любом инциденте:

kubectl get pods -n <namespace> -o wide

Ключевые столбцы:

STATUS - фаза пода. CrashLoopBackOff, ImagePullBackOff, Pending, Error - сигналы к действию.
READY - соотношение готовых контейнеров к общему числу. 0/1 означает, что под не принимает трафик.
RESTARTS - количество перезапусков. Растущее значение указывает на повторяющийся сбой.
NODE - узел, на котором работает под. Полезно для проверки ресурсов конкретного узла.

Быстрая фильтрация проблемных подов:

kubectl get pods -n <namespace> --field-selector=status.phase!=Running

Шаг 2: Анализ событий кластера с kubectl describe pod

Команда kubectl describe pod <pod-name> -n <namespace> даёт детальную картину. Смотрите раздел Events в конце вывода. Типичные сообщения:

Failed to pull image "repo/image:tag" - образ не найден или нет доступа.
Back-off restarting failed container - контейнер падает после запуска, Kubernetes увеличивает паузу между попытками.
FailedScheduling - планировщик не может найти узел. Причина: нехватка CPU/памяти, taints, tolerations, nodeSelector.
OOMKilled - контейнер превысил лимит памяти и был убит ядром.

События - самый быстрый способ понять причину без чтения логов. Всегда начинайте с них.

Шаг 3: Просмотр логов контейнера с kubectl logs

Если события не дали ответа, читайте логи приложения:

kubectl logs <pod-name> -n <namespace> -c <container-name>

Полезные флаги:

--previous - логи предыдущего упавшего контейнера. Критично при CrashLoopBackOff, когда текущий контейнер ещё не успел ничего записать.
-f - потоковый вывод в реальном времени.
--tail=100 - последние 100 строк.

Ищите stack trace, сообщения об ошибках подключения к базе данных, некорректные переменные окружения. Подробный разбор всех флагов и сценариев - в полном руководстве по kubectl logs.

Шаг 4: Проверка readiness и liveness проб

Пробы - частая причина ложных перезапусков и зависших деплоев. LivenessProbe проверяет, жив ли контейнер. Если проба падает, kubelet перезапускает контейнер. ReadinessProbe проверяет готовность принимать трафик. Если проба не проходит, под исключается из Service, но не перезапускается.

Проверьте конфигурацию проб:

kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 20 'probe'

Типичные ошибки: слишком короткий initialDelaySeconds, проба зависит от внешнего сервиса, HTTP-проба проверяет не тот порт. Если readinessProbe никогда не проходит, деплой зависнет навсегда.

Решение частых проблем: CrashLoopBackOff и ImagePullBackOff

Два статуса, которые встречаются чаще всего. Разберём каждый детально.

CrashLoopBackOff: причины и способы устранения

Контейнер стартует и сразу падает. Kubernetes перезапускает его с нарастающей паузой. Причины:

Ошибка в приложении - исключение при старте, некорректный конфиг, отсутствие файла.
OOMKilled - контейнер превысил лимит памяти. Проверьте kubectl describe pod на наличие OOMKilled в разделе State.
Неправильная команда запуска - command или args указывают на несуществующий бинарник.
Отсутствие зависимостей - база данных не готова, миграции не выполнены.

Диагностика:

kubectl describe pod <pod-name> -n <namespace> | grep -A 10 'Last State'
kubectl logs <pod-name> -n <namespace> --previous

Решения: исправьте код или конфигурацию, увеличьте resources.limits.memory, скорректируйте command/args. Для OOMKilled важно различать утечку памяти и реальную нехватку ресурсов - метрики мониторинга помогут это сделать.

ImagePullBackOff: как исправить ошибку загрузки образа

Kubernetes не может скачать образ из реестра. Причины:

Неверный тег - образ с указанным тегом не существует.
Нет доступа к приватному реестру - отсутствуют imagePullSecrets.
Сетевые проблемы - узел не может достучаться до реестра.
Rate limit реестра - Docker Hub ограничивает количество запросов для анонимных пользователей.

Проверка:

kubectl describe pod <pod-name> -n <namespace> | grep -A 5 'Events'

Решения: исправьте имя образа и тег, создайте Secret для доступа к реестру и укажите его в imagePullSecrets, проверьте сетевую связность узла с реестром. Для приватных реестров используйте отдельный Secret с учётными данными.

Диагностика проблем с деплоями

Деплой может зависнуть даже если поды работают. Проблема в процессе обновления: старые поды не удаляются, новые не становятся готовыми.

Проверка статуса деплоя и истории версий

kubectl rollout status deployment/<deployment-name> -n <namespace>
kubectl rollout history deployment/<deployment-name> -n <namespace>

Команда rollout status показывает прогресс обновления. Если она зависла, проверьте поды нового ReplicaSet: скорее всего, они не проходят readiness-пробу или не могут стартовать.

Откат неудачного обновления

Быстрый способ вернуть сервис в рабочее состояние:

kubectl rollout undo deployment/<deployment-name> -n <namespace>

Для отката к конкретной версии:

kubectl rollout undo deployment/<deployment-name> -n <namespace> --to-revision=2

Откат создаёт новый ReplicaSet на основе выбранной ревизии. Это безопаснее, чем ручное редактирование манифеста.

Проблемы с обновлением: maxUnavailable и maxSurge

Параметры стратегии RollingUpdate определяют, сколько подов можно удалить и создать одновременно. maxUnavailable - максимальное количество недоступных подов в процессе обновления. maxSurge - максимальное количество дополнительных подов сверх желаемого числа.

Если maxUnavailable: 0 и maxSurge: 0, обновление невозможно: Kubernetes не может ни удалить старый под, ни создать новый. Проверьте стратегию:

kubectl get deployment <deployment-name> -n <namespace> -o yaml | grep -A 10 'strategy'

Для stateful-приложений с одним экземпляром используйте Recreate - старый под удаляется перед созданием нового. Для stateless-сервисов подойдёт RollingUpdate с maxUnavailable: 1 и maxSurge: 1.

Работа с логами и событиями: продвинутые техники

Когда проблема затрагивает несколько подов или весь namespace, нужен обзорный инструмент.

Использование kubectl get events для обзора проблем

kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp

Фильтрация только предупреждений:

kubectl get events -n <namespace> --field-selector type=Warning

События хранятся ограниченное время, обычно час. Для долгосрочного анализа настройте централизованный сбор.

Централизованный сбор логов: краткий обзор

Для production-сред с десятками подов kubectl logs не масштабируется. Популярные решения: EFK/ELK (Elasticsearch, Fluentd/Logstash, Kibana), Grafana Loki, Datadog. Централизация даёт поиск по всем логам кластера, алерты на ошибки и корреляцию событий. Начните с Loki - он легче в установке и интегрируется с Grafana.

Предотвращение проблем: лучшие практики

Профилактика дешевле восстановления. Три настройки, которые предотвращают большинство инцидентов.

Настройка ресурсных лимитов и запросов

requests - гарантированный минимум ресурсов для пода. limits - максимальный потолок. Без requests планировщик не может корректно распределять нагрузку. Без limits один под может занять всю память узла и вызвать каскадный сбой.

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "512Mi"
    cpu: "500m"

Устанавливайте limits для всех production-подов. Это предотвращает OOMKilled и защищает соседние сервисы.

Правильная настройка readiness и liveness проб

Рекомендации:

Устанавливайте initialDelaySeconds с запасом: приложение должно успеть стартовать.
Не проверяйте в readinessProbe внешние сервисы - только готовность самого приложения.
Используйте HTTP-пробы с отдельным эндпоинтом /healthz, который не нагружает базу данных.
Для livenessProbe задавайте более мягкие таймауты, чем для readinessProbe.

Использование стратегий обновления для минимизации рисков

RollingUpdate подходит для stateless-сервисов с несколькими репликами. Recreate - для stateful-приложений, которые не поддерживают параллельную работу двух версий. Настраивайте maxUnavailable и maxSurge в зависимости от требований к доступности. Для критичных сервисов используйте maxUnavailable: 0 и maxSurge: 1 - обновление без потери доступности.

Шпаргалка: полезные команды для диагностики

Команда	Назначение
`kubectl get pods -n <ns> -o wide`	Общий статус подов, узел, IP, рестарты
`kubectl describe pod <pod> -n <ns>`	Детали пода, события, состояние контейнеров
`kubectl logs <pod> -n <ns> --previous`	Логи предыдущего упавшего контейнера
`kubectl get events -n <ns> --sort-by=.metadata.creationTimestamp`	События namespace в хронологическом порядке
`kubectl rollout status deployment/<dep> -n <ns>`	Прогресс обновления деплоя
`kubectl rollout undo deployment/<dep> -n <ns>`	Откат к предыдущей версии
`kubectl top pods -n <ns>`	Потребление ресурсов подами
`kubectl get pod <pod> -n <ns> -o yaml`	Полная конфигурация пода

Заключение

Систематический подход решает 90% проблем с подами и деплоями. Начинайте с kubectl get pods, затем kubectl describe pod для событий, затем kubectl logs для логов приложения. CrashLoopBackOff указывает на проблему в приложении или конфигурации, ImagePullBackOff - на доступ к реестру, зависший деплой - на пробы или стратегию обновления. Держите эту шпаргалку под рукой. Настройте ресурсные лимиты, пробы и централизованный сбор логов до того, как случится инцидент. Если нужна облачная инфраструктура для Kubernetes-кластера, обратите внимание на Timeweb Cloud - готовые серверы и управляемый Kubernetes для быстрого развёртывания.