Сколько контейнеров может быть в pod Kubernetes
Что проверяют
Понимаете ли, что под это не синоним контейнера, а группа с общими сетевым пространством и томами. Число тут повод: смотрят, знаете ли вы виды контейнеров и зачем вообще кладут несколько в один под.
Как отвечать
Жёсткого предела в API нет. Ограничивают ресурсы узла и лимит подов на узел у kubelet, по умолчанию сто десять. Снизу ограничение есть: список контейнеров не может быть пустым. На практике это один основной контейнер, к нему init-контейнеры и один или два вспомогательных.
Виды контейнеров стоит назвать отдельно:
- обычные: стартуют вместе, перезапускаются по политике пода;
- init: выполняются по очереди и до конца перед основными, годятся для миграций и ожидания зависимостей;
- sidecar: в свежих версиях описывается как init-контейнер с
restartPolicy: Always, стартует раньше основных и живёт вместе с ними; - эфемерные: подсаживаются в живой под для отладки через
kubectl debug, ресурсов не просят и перезапуск не переживают.
Общее у контейнеров пода: сетевое пространство имён, то есть один IP и общий localhost, тома, при желании IPC. Файловая система у каждого своя. Планируются они на один узел и масштабируются только целиком. Запросы ресурсов пода это сумма по обычным контейнерам и максимум по init-контейнерам.
Практика: sidecar для сбора логов и прокси сервисной сетки, ambassador для доступа к внешней базе, adapter для приведения метрик к нужному формату.
Где спотыкаются
Называют выдуманный предел вроде «от одного до пяти». В API такого числа нет, и спрашивают вообще не про него, а про то, понимаете ли вы механику пода.
Кладут в один под несвязанные сервисы, чтобы были рядом. Получают общий жизненный цикл, общий перезапуск и масштабирование пачкой. Связывать такие вещи надо через Service, а не через совместное проживание.
Забывают про общее сетевое пространство и вешают два контейнера на один порт. Родственная ошибка: делают вспомогательный контейнер обычным внутри Job, и задача не завершается никогда, потому что sidecar продолжает работать.