# В образе нет shell: диагностика Pod через ephemeral container

Диагностика: В образе нет shell: диагностика Pod через ephemeral container. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-ephemeral-container-debug/
Language: ru

Если рабочий образ не содержит shell и сетевых утилит, используйте ephemeral debug container с необходимыми правами. Он добавляет диагностическую среду к Pod без обязательной пересборки основного образа. Такой доступ меняет состояние Pod и требует осознанного выбора образа и возможностей.

## Определите диагностический вопрос

Сначала сохраните Pod events, состояние контейнеров и доступные логи. Для анализа маршрута нужен сетевой контекст, для дерева процессов — соответствующий process namespace. Не выдавайте debug container все привилегии, если требуется только проверить DNS или доступность порта. Укажите, какие данные разрешено читать, и выберите доверенный инструментальный образ по проверенной версии. Минимальный production image остаётся полезным свойством, даже если для разового расследования нужны дополнительные инструменты.


[Официальный источник 1](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/).

## Проверьте поддержку runtime

kubectl debug может добавить ephemeral container к работающему Pod. Параметр --target нацеливает его на process namespace другого контейнера, но эта возможность зависит от runtime. Без поддержки отладчик может не увидеть нужные процессы. Ephemeral containers имеют ограничения по lifecycle и изменению ресурсов; не рассматривайте их как обычный новый постоянный sidecar. Сверьте версию Kubernetes, доступные debug profiles и права пользователя до запуска, чтобы отказ авторизации не смешался с исходным сбоем приложения.


[Официальный источник 2](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/).

## Проведите ограниченный опыт

В учебном Pod основной образ не содержит sh, и kubectl exec завершается ошибкой отсутствия файла. Отдельный debug container позволяет проверить адрес resolver и соединение с нужным сервисом. Для проверки процессов добавляется подходящий target. Сохраните, виден ли ожидаемый PID и из какой области выполнялась сетевая команда. Успешный запрос из debug container не доказывает, что основной процесс использует те же credentials, CA store или application proxy settings.

| Проверяемая область | Что записать |
| --- | --- |
| Сеть | Namespace, адрес и порт назначения |
| Процессы | Target и подтверждённый PID |
| Доступ к данным | Разрешённые mounts и UID |
| Инструменты | Image digest и debug profile |

## Выберите безопасный способ повторения

Если нужно изменить launch command или ресурсы для воспроизведения, копия Pod может оказаться подходящим вариантом. Она уже является отдельным workload и способна создавать дополнительную нагрузку или побочные эффекты. Не запускайте копию с производственными секретами и активной обработкой без проверки назначения. Для работающего Pod предпочитайте минимальный диагностический набор, а результаты сохраняйте вне интерактивной сессии. Закрытие терминала не стирает автоматически добавленные сведения из состояния Pod.

## Сохраните вывод и завершите доступ

Запишите исходный вопрос, команды без секретов, namespace scope и результат. Отделите подтверждённый факт от гипотезы, которую инструмент не смог проверить. Затем завершите диагностическую сессию и предусмотрите очистку временной копии, если она создавалась. Артефакт должен позволять повторить наблюдение с тем же image digest. Такой подход восстанавливает доказательства сбоя без постоянного расширения production образа и не превращает разовый debug в незадокументированный канал административного доступа.

Связанные разборы: [gpu containers vs vms](/ru/journal/gpu-containers-vs-vms/); [vllm localhost container port](/ru/journal/vllm-localhost-container-port/).