Как использовать kubectl exec для запуска команд в контейнере

Коротко

kubectl exec позволяет выполнить команду или получить интерактивную оболочку внутри запущенного контейнера в Pod. Это удобно для одноразовой отладки, просмотра файловой системы или выполнения обслуживающих задач, но не заменяет сборку и деплой обновлённого образа.

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

• Using Kubectl Exec

• Choosing a Different Container

• Waiting for Pods to Be Running

• When Should I Use It?

• Summary

Использование kubectl exec

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

$ kubectl exec demo-pod -- demo-command

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

Для интерактивной сессии нужны дополнительные флаги:

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

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

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

Всё, что идёт после --, становится частью команды, выполняемой внутри контейнера. kubectl exec игнорирует точку входа контейнера и запускает процесс, который вы указали. Не оборачивайте команду в кавычки, если вы обычно не делаете этого локально.

Важно:

• kubectl exec не меняет образ контейнера на диске узла — запущенный процесс живёт только в памяти и в файловой системе Pod до рестарта.
• Подавляющий объём команд выполняется в контексте контейнера, поэтому переменные окружения и монтированные тома действуют как обычно.

Выбор другого контейнера

Если 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

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

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

Обратите внимание на порядок флагов: kubectl позволяет гибко располагать флаги, но -- всегда отделяет аргументы kubectl от аргументов команды.

Ожидание, пока Pod перейдёт в состояние Running

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

Пример установки таймаута в 5 минут:

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

Это удобно, когда вы сразу после создания Pod хотите выполнить в нём команду, но он ещё не был назначен на Node или контейнеры проходят инициализацию.

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

kubectl exec полезен в следующих случаях:

• Быстрая диагностика: просмотр логов, состояния процессов, временных файлов.
• Ручная инспекция файловой системы, когда артефакты ошибки не экспортируются в лог.
• Запуск одноразовых скриптов обслуживания, уже включённых в образ.

Что не стоит делать:

• Не используйте kubectl exec для установки пакетов или внесения постоянных изменений в контейнер. Такие изменения исчезнут при перезапуске Pod или при развёртывании нового репликаСета.
• Не применяйте его как постоянный способ управления контейнерами в продакшене — это сигнал о проблемах в автоматизации.

Лучший рабочий процесс: внесите изменения в Dockerfile или систему сборки образов, создайте новый образ и разверните обновлённые Pods.

Альтернативы и лучшие практики

1. Logs и kubectl logs — для просмотра stdout/stderr процессов.
2. kubectl cp — копирование файлов между локальной машиной и контейнером без интерактивной сессии.
3. Sidecar для отладки — добавьте контейнер отладки в Pod в тестовой среде вместо постоянного exec.
4. Remote debugging через специализированные инструменты (например, Delve для Go) — когда нужна глубокая отладка приложений.

Когда использовать альтернативы:

• Если требуется воспроизводимая конфигурация — обновляйте образ.
• Если нужно длительное подключение для мониторинга — используйте сервисы или экспорт метрик.

Противоположные примеры и ограничения

• Контейнер с минимальным образом (например, scratch) может не содержать оболочки /bin/sh или /bin/bash. В этом случае exec интерактивной оболочки невозможна — используйте утилиты, которые есть в образе, или заранее добавьте инструменты в образ.
• Контейнеры с ограничениями безопасности (Seccomp, AppArmor, SELinux, запреты на привилегии) могут блокировать выполнение некоторых команд.
• Если Pod настроен как Job и сразу же завершается, window для exec может быть пропущен.

Чеклист для отладки через kubectl exec

Перед выполнением:

• Убедитесь, что у вас есть доступ к нужному namespace: kubectl config и контекст.
• Проверьте статус Pod: kubectl get pod demo-pod -o wide
• Посмотрите контейнеры в Pod: kubectl describe pod demo-pod
• Решите, нужен ли интерактив: если команда только выводит информацию, флаги -it не обязательны.

Шаги:

1. Найдите Pod: kubectl get pods -n
2. Подключитесь: kubectl exec -it -c – /bin/sh
3. Выполните команду диагностики.
4. Выход: exit — завершит сессию; процессы, запущенные интерактивно, могут остаться и после выхода, если они созданы как фоновые.

Рольные рекомендации:

• Разработчик: используйте exec в dev/test для быстрой проверки предположений о среде.
• SRE/оператор: используйте exec только при необходимости для расследования инцидентов, документируйте действия.
• Команда безопасности: проверяйте политики RBAC, чтобы ограничить возможность exec для некритичных учёток.

Критерии приёмки

• Команда должна выполняться в целевом контейнере и возвращать ожидаемый вывод.
• Не должно быть внесено постоянных изменений в файловую систему контейнера без новой сборки образа.
• Действия, проведённые через exec во время инцидента, задокументированы в тикете или системе учёта изменений.

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

• По умолчанию kubectl exec использует права пользователя, настроенного внутри контейнера (часто root). Ограничьте доступ через RBAC.
• Аудит: включите аудит Kubernetes API, чтобы фиксировать команды exec в случае расследования инцидентов.
• Не включайте SSH-демон в продакшен-образы для удалённого доступа — это увеличивает поверхность атаки.

Быстрая методология принятия решения

Mermaid-диаграмма для выбора способа доступа:

flowchart TD
  A[Нужно подключиться к контейнеру?] -->|да| B{Требуется интерактив?}
  A -->|нет| Z[Используйте kubectl logs или kubectl cp]
  B -->|да| C[kubectl exec -it  -c  -- /bin/sh]
  B -->|нет| D[kubectl exec  -- ]
  C --> E{Образ содержит оболочку?}
  E -->|да| F[Подключиться и диагностировать]
  E -->|нет| G[Использовать kubectl cp или пересобрать образ]

1-строчная глоссарий

• Pod — минимальная единица развертывания в Kubernetes, содержащая один или несколько контейнеров.
• Container — изолированный процесс в Pod, основанный на образе.
• kubectl exec — команда kubectl для выполнения команд внутри запущенных контейнеров.

Примеры типичных команд и сценариев

Получить список процессов в контейнере:

$ kubectl exec demo-pod -- ps aux

Просмотреть файл конфигурации:

$ kubectl exec demo-pod -c app-container -- cat /etc/config/app.conf

Копировать файл из контейнера локально (альтернатива exec для передачи данных):

$ kubectl cp demo-pod:/var/log/app.log ./app.log

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

• Для развертывания исправления или обновления конфигурации — используйте CI/CD и пересборку образов.
• Для постоянного доступа к контейнеру — настройте сервисы наблюдения и метрик.
• Для команд, требующих сохранения изменений в образе — изменения должны быть в источнике сборки.

Резюме

kubectl exec — это мощный инструмент для одноразовой отладки и инспекции контейнеров в Kubernetes. Он предоставляет интерактивный доступ к процессам и файловой системе, но не заменяет практики иммутабельных образов и CI/CD. Используйте его осознанно: документируйте действия, ограничивайте доступ через RBAC и предпочитайте пересборку образов для постоянных изменений.

Важное

• Не устанавливайте пакеты и не вносите постоянные изменения в контейнеры через kubectl exec. Такие изменения неустойчивы.
• Ограничьте возможность exec в production с помощью RBAC и аудита.