В каких случаях используются поды с несколькими контейнерами?

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

1. Sidecar-контейнер: Расширяет или усиливает функциональность основного приложения. Контейнеры работают параллельно.
   • Пример из практики: Основной контейнер — веб-приложение (Nginx), sidecar — fluentd, который читает логи из общего emptyDir тома и отправляет их в централизованную систему (Elasticsearch).

     spec:
     containers:
     - name: web-app
     image: nginx:alpine
     volumeMounts:
     - name: log-volume
       mountPath: /var/log/nginx
     - name: log-shipper
     image: fluent/fluentd:latest
     volumeMounts:
     - name: log-volume
       mountPath: /var/log/nginx
     volumes:
     - name: log-volume
     emptyDir: {}

2. Adapter-контейнер: Стандартизирует или трансформирует выходные данные основного контейнера.
   • Пример: Основной контейнер генерирует логи в собственном формате. Adapter-контейнер (logstash) преобразует их в структурированный JSON, прежде чем sidecar отправит их дальше.
3. Ambassador-контейнер: Служит прокси или посредником для сетевых подключений из основного контейнера.
   • Пример: Основное приложение подключается к localhost:5432, где слушает ambassador-контейнер с postgresql-client, который туннелирует или балансирует соединения к различным экземплярам базы данных в зависимости от окружения (dev/staging/prod). Это позволяет основному приложению не знать о реальной топологии БД.

Важное замечание: Я использую этот паттерн осознанно, так как контейнеры в Pod имеют общий жизненный цикл. Если sidecar крашится, весь Pod перезапускается. Для более слабой связанности часто лучше использовать отдельные Pods и взаимодействие через Service.