Sidecar pattern

• Same pod = same IP + shared volumes
• Lifecycle: start/stop вместе с main container
• Common sidecars: istio-proxy, filebeat, vault-agent, oauth2-proxy
• Init containers: run once до main (setup)
• Downsides: resource overhead × pod_count, complexity

# Pod with sidecar
spec:
  containers:
  - name: app
    image: my-app:v1
  - name: log-shipper  # sidecar
    image: fluent/fluent-bit
    volumeMounts:
    - { name: logs, mountPath: /var/log }
  volumes:
  - name: logs
    emptyDir: {}

• Service Mesh
• Envoy
• K8s Operator

Sidecar pattern — это архитектурный подход, который используется в контейнерной среде для разделения функциональности приложения на два компонента: основной сервис и вспомогательный сервис (sidecar). Основной сервис отвечает за бизнес-логику, тогда как sidecar берет на себя задачи, такие как мониторинг, управление конфигурацией и взаимодействие с внешними системами. Это позволяет упростить разработку и развертывание, а также улучшить управление и масштабируемость приложений.

Sidecar pattern имеет ряд преимуществ:

• Модульность: Разделение логики приложения на независимые компоненты упрощает разработку и тестирование.
• Упрощенное управление конфигурацией: Вспомогательные сервисы могут управлять конфигурациями и обновлениями без изменения основного кода приложения.
• Улучшенная наблюдаемость: Sidecar может интегрироваться с инструментами мониторинга, такими как Prometheus или Jaeger, для отслеживания производительности приложения.

Тем не менее, существует и ряд недостатков:

• Сложность развертывания: При добавлении новых компонентов увеличивается сложность инфраструктуры.
• Дополнительные накладные расходы: Sidecar требует дополнительных ресурсов, что может увеличить затраты на инфраструктуру.

Рассмотрим практический пример реализации Sidecar pattern с использованием Docker и Kubernetes. В этом примере мы создадим основной сервис на Node.js и sidecar-сервис для логирования с использованием Fluentd.

version: '3'
services:
  app:
    image: node:14
    command: node app.js
    ports:
      - '3000:3000'
    networks:
      - my-network
    volumes:
      - .:/usr/src/app
  fluentd:
    image: fluent/fluentd:v1.12-1
    ports:
      - '24224:24224'
    volumes:
      - ./fluentd.conf:/fluentd/etc/fluentd.conf
    networks:
      - my-network
networks:
  my-network:
    driver: bridge

В данном примере основной сервис (app) и sidecar (fluentd) работают в одной сети. Fluentd собирает логи из основного приложения и отправляет их в систему хранения данных.

Для настройки Fluentd используется конфигурационный файл fluentd.conf, который определяет, как обрабатывать и куда отправлять логи. Например:

source
  @type tail
  path /usr/src/app/logs/*.log
  pos_file /fluentd/logs/position.log
  format none

match *.*
  @type stdout

Это позволяет вам легко интегрировать дополнительные функции, такие как мониторинг и логирование, без необходимости изменять код основного приложения. Sidecar pattern дает возможность гибко масштабировать и управлять различными аспектами приложения, что делает его популярным выбором для современных микросервисных архитектур.