В этом материале
Если рабочий образ не содержит shell и сетевых утилит, используйте ephemeral debug container с необходимыми правами. Он добавляет диагностическую среду к Pod без обязательной пересборки основного образа. Такой доступ меняет состояние Pod и требует осознанного выбора образа и возможностей.
Если рабочий образ не содержит shell и сетевых утилит, используйте ephemeral debug container с необходимыми правами. Он добавляет диагностическую среду к Pod без обязательной пересборки основного образа. Такой доступ меняет состояние Pod и требует осознанного выбора образа и возможностей.
Определите диагностический вопрос
Сначала сохраните Pod events, состояние контейнеров и доступные логи. Для анализа маршрута нужен сетевой контекст, для дерева процессов — соответствующий process namespace. Не выдавайте debug container все привилегии, если требуется только проверить DNS или доступность порта. Укажите, какие данные разрешено читать, и выберите доверенный инструментальный образ по проверенной версии. Минимальный production image остаётся полезным свойством, даже если для разового расследования нужны дополнительные инструменты.
Проверьте поддержку runtime
kubectl debug может добавить ephemeral container к работающему Pod. Параметр —target нацеливает его на process namespace другого контейнера, но эта возможность зависит от runtime. Без поддержки отладчик может не увидеть нужные процессы. Ephemeral containers имеют ограничения по lifecycle и изменению ресурсов; не рассматривайте их как обычный новый постоянный sidecar. Сверьте версию Kubernetes, доступные debug profiles и права пользователя до запуска, чтобы отказ авторизации не смешался с исходным сбоем приложения.
Проведите ограниченный опыт
В учебном 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; vllm localhost container port.