Создание Pod с несколькими контейнерами в Kubernetes

Pods обычно содержат один контейнер — это самый частый сценарий. Однако бывают случаи, когда в одном Pod собирают несколько связанных контейнеров, которые разделяют ресурсы (сеть, общие тома) и работают как единое логическое приложение. Multi-container Pod — это Pod с двумя или более контейнерами, у которых общий сетевой стек и (при необходимости) общие тома.

Почему используют multi-container Pod:

• Упрощённая локальная коммуникация: контейнеры внутри Pod-а общаются по localhost.
• Одинаковый жизненный цикл: все контейнеры запускаются, перезапускаются и удаляются вместе.
• Общие тома: контейнеры могут обмениваться данными через смонтированные тома.

Введение

В этой статье мы создадим Pod с двумя контейнерами: nginx (как веб-сервер) и alpine (как клиент, который выполняет запросы к localhost). На примере вы увидите манифест, команды kubectl для создания и проверки, а также советы по отладке.

Требования

1. Kubernetes-кластер с как минимум 1 рабочим узлом.
   Если у вас нет кластера, создайте тестовый кластер локально (minikube, kind) или в облаке — инструкция зависит от выбранного способа и выходит за рамки этой статьи.

Что мы сделаем

1. Создадим multi-container Pod с двумя контейнерами.
2. Проверим состояние Pod и каждого контейнера.
3. Получим логи конкретного контейнера и подключимся в него.
4. Разберём типичные ошибки и лучшие практики.

Создание Pod с несколькими контейнерами

Создайте файл манифеста для Pod, например multi-container-pod-example.yml:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: container-1
    image: nginx
    ports:
    - containerPort: 80    
  - name: container-2
    image: alpine
    command: ["watch", "wget", "-qO-", "localhost"]

Этот файл описывает Pod с двумя контейнерами, которые будут разделять сетевую область видимости и (при необходимости) смонтированные тома.

Создадим Pod и проверим список Pod-ов:

kubectl get pods # Получить список существующих Pod

kubectl create -f multi-container-pod-example.yml # Создать multi-container Pod

kubectl get pods # Проверить Pod после создания

В выводе вы можете увидеть столбец READY. Например, 2/2 означает, что внутри Pod-а определено два контейнера и оба находятся в состоянии Ready.

Получим детальное описание созданного Pod-а:

kubectl get pods

kubectl describe pod multi-container-pod # Показать детали Pod

Команда describe покажет разделы для каждого контейнера: имя, образ, состояние, события и порты.

Логи и вход в конкретный контейнер

Чтобы получить логи контейнера внутри Pod-а, нужно указать имя контейнера — в противном случае kubectl не знает, логи какого контейнера вы хотите посмотреть:

kubectl get pods

kubectl logs multi-container-pod # Без указания контейнера не сработает

kubectl logs multi-container-pod container-1 # Логи для container-1

Можно запросить логи только одного контейнера за раз. Попытка передать два имени контейнеров в одной команде приведёт к ошибке:

kubectl logs multi-container-pod container-1 container-2 # Нельзя указать два контейнера одновременно

Аналогично, простая команда exec без указания контейнера не сработает, если в Pod-е несколько контейнеров:

kubectl exec -it multi-container-pod /bin/bash

Чтобы подключиться в конкретный контейнер, используйте флаг -c (или –container):

kubectl exec -it multi-container-pod -c container-1 /bin/bash # Войти в container-1

Удаление Pod

Если Pod больше не нужен, его можно удалить:

kubectl get pod

kubectl delete pod multi-container-pod # Удалить Pod

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

Когда использовать multi-container Pod

• Когда контейнеры логически связаны и должны делить localhost (например, прокси и приложение).
• Когда нужно разделение ответственности: один контейнер служит прокси/sidecar, другой — основное приложение.
• Когда требуется совместный доступ к томам для обмена файлами.

Когда лучше не использовать multi-container Pod (контрпримеры)

• Если компоненты независимы и имеют разный жизненный цикл — лучше делать отдельные Pod-и и связывать их через сервисы.
• Если требуется масштабирование отдельных частей независимо — отдельные Deployments / ReplicaSets дают гибкость.
• Если контейнеры требуют разной политики обновлений или разные ресурсы и SLA.

Альтернативы

• Sidecar pattern: один вспомогательный контейнер в Pod (частный случай мультиконтейнерного Pod-а).
• Отдельные сервисы/Deployment: разделение на независимые микросервисы.
• initContainers: для подготовки окружения до старта основного контейнера (они не заменяют sidecar для совместной работы после старта).

Мысленная модель

Pod — это один логический хост: все контейнеры в Pod-е разделяют IP и порты (localhost), и могут совместно использовать тома. Подумайте о Pod-е как о «виртуальной машине» для тесно связанных процессов.

Проверка и отладка — пошаговый SOP

1. kubectl get pods — проверить состояние Pod.
2. kubectl describe pod — посмотреть события и причины неудач.
3. kubectl logs -c — получить логи нужного контейнера.
4. kubectl exec -it -c – /bin/sh или /bin/bash — войти в контейнер для живой отладки.
5. Если нужен сетевой дамп — используйте tcpdump в sidecar или nsenter на узле.

Риски и меры снижения

• Риск: взаимная блокировка контейнеров (resource contention). Митигируйте: лимиты и запросы ресурсов (resources.requests/resources.limits).
• Риск: один контейнер выводит кластер в нестабильное состояние. Митигируйте: readiness/liveness пробы и стратегия перезапуска.
• Риск: сложность логирования. Митигируйте: централизованное логирование по контейнеру и метки для сопоставления логов.

Роль-ориентированные чеклисты

Разработчик:

• Убедиться, что приложение корректно отвечает на localhost.
• Написать базовые пробы готовности и здоровья.

DevOps:

• Настроить ресурсы и пробы (readiness/liveness).
• Проверить логирование и мониторинг для каждого контейнера.

QA:

• Проверить сценарии перезапуска и восстановления.
• Проверить обмен данными через общий том, если он используется.

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

• Pod успешно создаётся и содержит два контейнера.
• Оба контейнера переходят в состояние Ready (kubectl get pods показывает 2/2).
• Логи каждого контейнера доступны через kubectl logs -c .
• Удаление Pod удаляет все контейнеры вместе.

Короткое резюме

В статье показано, как определить и создать Pod с несколькими контейнерами, как получать логи и подключаться к конкретному контейнеру, а также когда и зачем использовать такой подход. Multi-container Pod удобен для тесно связанных процессов, но не всегда подходит, если требуется независимое масштабирование или раздельный жизненный цикл.

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

• Pod: минимальная ед. развертывания в Kubernetes, содержащая один или несколько контейнеров.
• Sidecar: вспомогательный контейнер в том же Pod, который дополняет основное приложение.
• initContainer: контейнер, выполняемый до запуска основных контейнеров для подготовки окружения.

Важно: выбирайте multi-container Pod, когда контейнеры логически связаны и требуют совместного хоста. В противном случае рассмотрите отдельные Deployments и сервисы.