kubectl exec: запуск команд в контейнерах Kubernetes

Логотип Kubernetes на иллюстрации

TL;DR

kubectl exec позволяет запускать команды и получать интерактивную оболочку внутри запущенного контейнера без установки SSH. Используйте его для отладки и одноразовых операций, но не для долгосрочных исправлений — для этого нужно собирать новый образ.

Быстрые ссылки

Using Kubectl Exec
Choosing a Different Container
Waiting for Pods to Be Running
When Should I Use It?
Summary

Коротко: приложения в Kubernetes обычно долгоживущие и не требуют вмешательства. Иногда нужно вручную выполнить команду внутри контейнера — для обслуживания, сбора артефактов или отладки. В этой статье объяснено, как запускать команды и подключать интерактивную оболочку к контейнерам с помощью kubectl exec.

Что такое kubectl exec

Определение: kubectl exec — команда CLI, которая запускает указанный процесс внутри уже запущенного контейнера в Pod.

Using Kubectl Exec

kubectl exec выполняет команду внутри работающего контейнера. Базовый синтаксис выглядит так:

$ kubectl exec demo-pod -- demo-command

Эта команда запустит demo-command внутри первого контейнера Pod с именем demo-pod. По умолчанию команда выполняется с привилегиями root внутри контейнера.

Чтобы получить интерактивную сессию терминала, добавьте флаги:

--stdin (-i) — передаёт стандартный ввод вашего терминала в контейнер.
--tty (-t) — помечает поток ввода как TTY, делая сессию интерактивной.

Пример получения шелла в первом контейнере Pod:

$ kubectl exec -it demo-pod -- /bin/sh

Всё, что указано после --, становится частью команды, выполняемой внутри контейнера. kubectl exec игнорирует точку входа контейнера (entrypoint) и запускает новый процесс с вашей командой. Не оборачивайте команду в кавычки ("/bin/sh"), если вы не использовали бы их при локальном запуске.

Choosing a Different Container

Если в Pod несколько контейнеров, kubectl exec по умолчанию подключается к контейнеру, помеченному аннотацией kubectl.kubernetes.io/default-container. Если аннотация не задана, считается, что это первый контейнер в списке.

Ниже — пример Pod с двумя контейнерами:

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: app-container
      image: nginx:latest
    - name: sidecar-container
      image: busybox:latest

Чтобы запустить команду в sidecar-container, используйте флаг -c:

$ kubectl exec --it demo-pod -c sidecar-container -- /bin/sh

Waiting for Pods to Be Running

Если контейнеры Pod ещё не запущены, kubectl по умолчанию подождёт примерно минуту, прежде чем выдать ошибку. Таймаут можно изменить флагом --pod-running-timeout. Это удобно, если вы пытаетесь выполнить команду сразу после создания Pod, когда он ещё не запланирован на Node.

$ kubectl exec --pod-running-timeout=5m demo-pod -- demo-command

Когда следует использовать kubectl exec

kubectl exec полезен в специализированных случаях:

срочная отладка: изучить состояние файлов и процессов;
одноразовые административные задачи: очистка кэша, просмотр локальных логов, запуск встроенных скриптов;
восстановление данных в экспериментальных средах.

Важно: не используйте kubectl exec как способ вносить постоянные изменения в контейнеры. Установка пакетов или правка окружения вручную приводит к “дрейфу” контейнера — таких изменений не будет в образе и они потеряются при перезапуске Pod. Правильный путь — обновить образ и выполнить деплой заново.

Когда это не подходит

Production: частое использование exec в production сигнализирует о проблеме в CI/CD или в процессе сборки образов.
Патчи и обновления: обновляйте образы, а не контейнеры вручную.
Удалённый администрирование: для постоянного доступа используйте инструменты управления конфигурацией или регламентированные методы.

Альтернативные подходы

kubectl cp — копирование файлов из/в контейнер;
kubectl logs — просмотр логов для отладки без подключения к шеллу;
sidecar с debug-образом — запуск временного контейнера рядом с приложением;
создание ephemeral Pod с нужными утилитами и подключение к нему.

Безопасность и рекомендации

Ограничьте доступ к kubectl по ролям RBAC — exec даёт доступ к filesystem и процессам контейнера.
Не запускайте kubeconfig с правами admin на рабочих машинах без нужды.
Логируйте сессии и команды в процессе аудита (если это предусмотрено политикой).

Быстрая методика безопасного использования (мини-методология)

Оцените цель: отладка, сбор артефактов или временная правка.
Подготовьте временную среду: используйте debug-образ или ephemeral Pod, если нужно множество утилит.
Выполните команду с минимальными привилегиями.
Соберите артефакты (лог/дамп) в хранилище.
Не вносите долгосрочных изменений — соберите новый образ при необходимости.

Чек-лист по ролям

Developer:
- убедиться, что команда воспроизводима в CI;
- собрать артефакты и создать issue с детальными шагами.
SRE/Оператор:
- использовать RBAC и аудирование;
- при необходимости запускать временные контейнеры с инструментами отладки.
Security-инженер:
- проверять доступы к kubectl;
- запрещать exec в критических namespace без разрешения.

Шпаргалка команд

# Запустить команду в контейнере
kubectl exec demo-pod -- demo-command

# Интерактивный шелл
kubectl exec -it demo-pod -- /bin/sh

# Указать контейнер в Pod
kubectl exec --it demo-pod -c sidecar-container -- /bin/sh

# Подождать до 5 минут, пока Pod не будет Running
kubectl exec --pod-running-timeout=5m demo-pod -- demo-command

Когда kubectl exec не поможет — галерея кейсов

Контейнер падает сразу после старта: используйте kubectl logs и kubectl describe pod.
Нужны инструменты, которых нет в образе (strace, curl): запустите кратковременный debug Pod с нужными утилитами.
Требуется постоянный доступ к окружению: организуйте удалённое управление через CI/CD и обновление образов.

Диаграмма принятия решения

flowchart TD
  A{Нужно ли выполнить команду внутри контейнера?}
  A -->|Да: одноразовая отладка| B[kubectl exec]
  A -->|Да: нужна полная среда| C[Ephemeral debug Pod]
  A -->|Нет: просто логи| D[kubectl logs]
  B --> E{Pod Running?}
  E -->|Да| F[Выполнить kubectl exec]
  E -->|Нет| G[Подождать или изменить образ]

Короткое руководство по безопасности

Не устанавливайте пакеты внутри ранних контейнеров в production.
Минимизируйте права в kubeconfig и используйте временные креденшалы.
По возможности используйте immutable-образ и автоматические деплои.

Примеры ошибок и как их искать

Ошибка: “container not found”
- Проверьте название контейнера и флаг -c.
Ошибка: “pod not found”
- Проверьте namespace или используйте -n.
Проблемы с TTY
- Убедитесь, что вы используете -it при запуске интерактивного шелла.

Сводка

kubectl exec полезен для одноразовой отладки и выполнения вспомогательных задач внутри контейнера. Всегда думайте о воспроизводимости и безопасности: не используйте exec для постоянных изменений — обновляйте образы и автоматизируйте деплой. Применяйте чек-листы и ограничивайте доступ через RBAC.

Важно: если вы часто используете exec в production, пересмотрите процесс сборки образов и практики деплоя — это признак архитектурной или процедурной проблемы.