Что такое Sidecar-контейнер в Kubernetes?

Sidecar-контейнер в Kubernetes: Вспомогательный контейнер в Pod

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

Основная концепция Sidecar

Обычно Pod содержит один контейнер, но Kubernetes позволяет запускать несколько контейнеров в одном Pod:

Pod
├── Основной контейнер (main application)
│   └── Слушает порт 8080
├── Sidecar контейнер 1
│   └── Логирование
└── Sidecar контейнер 2
    └── Мониторинг

Архитектура Sidecar Pod

Куберецес Ноде
├── Pod
│   ├── Network Namespace (SHARED)
│   │   └── localhost:8080 доступен всем контейнерам
│   ├── Storage Volumes (SHARED)
│   │   └── /shared-volume доступен всем контейнерам
│   ├── Основной контейнер (приложение)
│   │   └── Слушает localhost:8080
│   └── Sidecar контейнер
│       └── Читает/пишет в /shared-volume
└── [Другие Pods]

Определение Sidecar в Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: web-app-with-sidecar
spec:
  containers:
  # Основной контейнер
  - name: web-app
    image: myapp:1.0
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: app-logs
      mountPath: /var/log/app
  
  # Sidecar контейнер для логирования
  - name: log-shipper
    image: filebeat:7.0
    volumeMounts:
    - name: app-logs
      mountPath: /var/log/app
      readOnly: true
  
  volumes:
  - name: app-logs
    emptyDir: {}

Типичные сценарии использования Sidecar

1. Логирование и обработка логов

apiVersion: v1
kind: Pod
metadata:
  name: app-with-log-sidecar
spec:
  containers:
  # Основное приложение
  - name: myapp
    image: java:latest
    command: ["java", "-jar", "app.jar"]
    volumeMounts:
    - name: logs
      mountPath: /var/log
  
  # Sidecar для сбора логов
  - name: log-aggregator
    image: fluent-bit:latest
    volumeMounts:
    - name: logs
      mountPath: /var/log
      readOnly: true
    env:
    - name: LOG_PROCESSOR_HOST
      value: "elasticsearch.logging.svc.cluster.local"
  
  volumes:
  - name: logs
    emptyDir: {}

2. Мониторинг и метрики

apiVersion: v1
kind: Pod
metadata:
  name: app-with-monitoring
spec:
  containers:
  # Основное приложение
  - name: app
    image: myapp:1.0
    ports:
    - containerPort: 8080
  
  # Sidecar для сбора метрик
  - name: prometheus-exporter
    image: prometheus-jmx-exporter:latest
    ports:
    - containerPort: 5555
    env:
    - name: SERVICE_PORT
      value: "8080"

3. Proxy и трафик контроль

apiVersion: v1
kind: Pod
metadata:
  name: app-with-proxy-sidecar
spec:
  containers:
  # Основное приложение
  - name: myapp
    image: myapp:1.0
    ports:
    - containerPort: 8080
  
  # Sidecar proxy (например, Envoy)
  - name: envoy-proxy
    image: envoyproxy/envoy:v1.20
    ports:
    - containerPort: 10000
    volumeMounts:
    - name: envoy-config
      mountPath: /etc/envoy
  
  volumes:
  - name: envoy-config
    configMap:
      name: envoy-configuration

4. Инициализация данных

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
  # Init контейнер выполняется ДО основного
  - name: db-init
    image: postgres-client:latest
    env:
    - name: DB_HOST
      value: "db.default.svc.cluster.local"
    - name: DB_NAME
      value: "myapp"
  
  containers:
  # Основное приложение
  - name: app
    image: myapp:1.0
    dependsOn:
    - name: db-init

5. Authentication и авторизация

apiVersion: v1
kind: Pod
metadata:
  name: app-with-auth-sidecar
spec:
  containers:
  # Основное приложение
  - name: app
    image: myapp:1.0
    ports:
    - containerPort: 8080
    env:
    - name: AUTH_PROXY_HOST
      value: "localhost"
    - name: AUTH_PROXY_PORT
      value: "8888"
  
  # Sidecar для проверки аутентификации
  - name: oauth2-proxy
    image: oauth2-proxy/oauth2-proxy:latest
    ports:
    - containerPort: 8888
    env:
    - name: OAUTH2_PROXY_UPSTREAM
      value: "http://localhost:8080"

Практический пример: Java приложение с Sidecar

apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-app-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: java-app
  template:
    metadata:
      labels:
        app: java-app
    spec:
      containers:
      # Java приложение
      - name: java-app
        image: openjdk:11-jre
        command: ["java", "-jar", "app.jar"]
        ports:
        - containerPort: 8080
        env:
        - name: LOG_PATH
          value: "/var/log/app"
        volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
        resources:
          requests:
            memory: "256Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
      
      # Sidecar для логирования
      - name: filebeat
        image: docker.elastic.co/beats/filebeat:7.14.0
        command: ["/usr/share/filebeat/filebeat"]
        args: ["-c", "/etc/filebeat.yml", "-e"]
        volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
          readOnly: true
        - name: filebeat-config
          mountPath: /etc/filebeat.yml
          subPath: filebeat.yml
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "256Mi"
            cpu: "100m"
      
      volumes:
      - name: app-logs
        emptyDir: {}
      - name: filebeat-config
        configMap:
          name: filebeat-config

ConfigMap для Filebeat Sidecar

apiVersion: v1
kind: ConfigMap
metadata:
  name: filebeat-config
data:
  filebeat.yml: |
    filebeat.inputs:
    - type: log
      enabled: true
      paths:
        - /var/log/app/*.log
    
    output.elasticsearch:
      hosts: ["elasticsearch:9200"]
      index: "java-app-logs"
    
    logging.level: info

Сравнение: Pod с Sidecar vs несколько Pods

Преимущества Sidecar паттерна

1. Разделение ответственности — основное приложение не знает о логировании, мониторинге и т.д.
2. Переиспользование — один Sidecar можно использовать с разными приложениями
3. Упрощение сетевого взаимодействия — localhost вместо DNS запросов
4. Управление ресурсами — Kubernetes может управлять ресурсами каждого контейнера
5. Гибкость развертывания — можно добавлять/удалять Sidecars без изменения основного приложения

Недостатки и ограничения

1. Связанность — если Sidecar падает, может упасть весь Pod
2. Сложность отладки — несколько контейнеров в одном Pod
3. Ресурсы — каждый контейнер требует собственных ресурсов
4. Масштабирование — нельзя масштабировать независимо

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

Используйте Sidecar когда:

• Функция тесно связана с основным приложением
• Нужен быстрый локальный доступ (localhost)
• Функция должна масштабироваться вместе с приложением
• Примеры: логирование, мониторинг, прокси, инъекция конфигов

НЕ используйте Sidecar когда:

• Функция может масштабироваться независимо
• Нужен отдельный lifecycle
• Функция должна быть переиспользуемой в других сервисах
• Примеры: база данных, очередь, кэш

Service Mesh и Sidecars (Istio)

Istio использует Sidecars для управления трафиком:

apiVersion: v1
kind: Namespace
metadata:
  name: default
  labels:
    istio-injection: enabled  # Автоматическое внедрение Envoy sidecar

Istio автоматически добавит Envoy sidecar в каждый Pod:

kubectl get pods
# output:
# myapp-pod     2/2     Running   # основной контейнер + Envoy sidecar

Отладка Sidecar

# Просмотр логов основного контейнера
kubectl logs <pod-name> -c <main-container>

# Просмотр логов Sidecar
kubectl logs <pod-name> -c <sidecar-name>

# Выполнение команды в Sidecar
kubectl exec <pod-name> -c <sidecar-name> -- /bin/sh

# Описание Pod с информацией о контейнерах
kubectl describe pod <pod-name>

Лучшие практики

1. Используйте init-контейнеры для инициализации (запускаются один раз перед основным)
2. Устанавливайте liveness/readiness проbes для каждого контейнера
3. Разделяйте лимиты ресурсов между контейнерами
4. Документируйте назначение каждого Sidecar
5. Используйте registry для Sidecar образов (Docker Hub, ECR, GCR)
6. Не делайте Sidecar слишком тяжелым — это замедлит запуск Pod
7. Используйте Service Mesh (Istio, Linkerd) для управления Sidecars в масштабе

Sidecar паттерн — это мощный инструмент в арсенале Kubernetes, позволяющий разделять ответственность и обеспечивающий гибкость в развертывании микросервисных приложений.