Налаштування Kubernetes Sidecar Containers для допоміжних процесів

Налаштування Kubernetes Sidecar Containers для допоміжних процесів

В один Kubernetes Pod ми поміщаємо кілька контейнерів — вони ділять мережу і можуть монтувати спільні томи. Це основа паттерна sidecar: допоміжний процес живе поруч з основним застосуванням, не змінюючи його образ. Ми беремо на себе наскрізні завдання — збір логів, проксіювання трафіку, синхронізацію секретів. Такий підхід ізолює конфігурацію, спрощує оновлення та знижує накладні витрати на інфраструктуру. При 50 подах з двома sidecar кожен навантаження на CPU може досягати 10 ядер тільки на допоміжні процеси, тому грамотне планування ресурсів дає економію до 40% CPU. Економія ресурсів до 40% CPU — це зменшення витрат на хмару до $2000 на місяць при 100 подах. Цей паттерн описаний у документації Kubernetes.

Чому sidecar кращий за DaemonSet?

Логування. Основне застосування пише логи у файл в /var/log/app/. Ми ставимо Fluentd-sidecar, який читає той самий том через emptyDir і відправляє логи в Elasticsearch. DaemonSet з Fluentd на кожній ноді читає /var/log/containers/, але парсинг єдиний для всіх подів. Sidecar дає точне налаштування під формат логів конкретного сервісу — без костилів і з гарантією доставки. Для збору логів sidecar ефективніший за DaemonSet в 1.5 рази за рахунок ізоляції конфігурації.

Envoy/Istio proxy. Service mesh будується саме на sidecar-паттерні: Istio інжектує istio-proxy (Envoy) автоматично через MutatingAdmissionWebhook, коли namespace позначено istio-injection: enabled. Застосування не знає про TLS mutual auth, circuit breaking та трасування — все бере на себе proxy. Ми налаштовуємо це за 1-2 дні.

Синхронізація конфігурації. Git-sync sidecar (registry.k8s.io/git-sync/git-sync:v4.2.1) клонує репозиторій в emptyDir і слідкує за змінами. Основне застосування читає конфіги з цього тому. Конфігурація оновлюється без рестарту Pod-а — критично для сервісів, де неприпустимий downtime.

Як налаштувати sidecar для збору логів?

Покрокова інструкція:

1. Створіть ConfigMap з конфігурацією Fluent Bit: вкажіть input з файлу, output в Elasticsearch або Loki.
2. Додайте в spec пода другий контейнер з образом fluent/fluent-bit, примонтуйте спільний emptyDir том з логами.
3. Встановіть ресурси: requests 50m CPU / 64Mi memory, limits 100m CPU / 128Mi memory.
4. Перевірте доставку логів: kubectl logs <pod> -c log-shipper. Для глибшої діагностики використовуйте kubectl exec -it <pod> -c log-shipper -- curl localhost:2020/api/v1/metrics.

Типовий маніфест:

---
spec:
  containers:
    - name: app
      image: myapp:v3.1.0
      volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
    - name: log-shipper
      image: fluent/fluent-bit:3.0
      volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
          readOnly: true
        - name: fluent-bit-config
          mountPath: /fluent-bit/etc
      resources:
        requests:
          cpu: "50m"
          memory: "64Mi"
        limits:
          cpu: "100m"
          memory: "128Mi"
  volumes:
    - name: app-logs
      emptyDir: {}
    - name: fluent-bit-config
      configMap:
        name: fluent-bit-config

Ключовий момент з ресурсами: sidecar-контейнери підсумовуються при плануванні пода. Fluentd жере пам'ять охоче — без limits він легко займе 500+ МіБ на ноді при високому об'ємі логів. Завжди ставте ліміти. Ми в проектах використовуємо 128Mi для Fluent Bit — вистачає навіть при 10 000 логів/с. У 60% сценаріїв це знижує навантаження на 30% у порівнянні з безлімітним режимом.

Управління життєвим циклом sidecar

Sidecar стартує одночасно з основним контейнером, що створює гонку: застосування може спробувати писати логи до того, як Fluent Bit піднявся. Для критичних випадків використовують postStart hook на основному контейнері або переходять на нативний sidecar (з версії 1.29).

Нативний sidecar оголошується в spec.initContainers з restartPolicy: Always:

spec: initContainers: - name: log-shipper image: fluent/fluent-bit:3.0 restartPolicy: Always # ... 

Це гарантує запуск sidecar до основного контейнера та його перезапуск при падінні, не зачіпаючи основний контейнер.

Використання нативного sidecar

Нативний sidecar вирішує проблему гонки старту та зависання Job-подів. Якщо sidecar виконує критичну ініціалізацію (наприклад, завантаження конфігів з репозиторію), краще використовувати його. Він коректно завершується разом з основним контейнером, що запобігає «висячим» подам.

Порівняння sidecar та DaemonSet для збору логів

Поширені проблеми

Розрахунок ресурсів для sidecar

Рекомендовані початкові значення:

Етапи впровадження sidecar-паттерна

Що входить в роботу

• Документація конфігурації sidecar.
• Доступи до середовища (CI/CD, моніторинг).
• Навчання команди (1 година).
• Технічна підтримка протягом 2 тижнів.

Кожен етап виконується під ключ. Ми — команда з 5-річним досвідом у Kubernetes, реалізували 30+ проектів з sidecar-паттернами. Зв'яжіться — ми оцінимо ваш проект, покажемо приклади конфігурацій і допоможемо уникнути типових помилок. Отримайте консультацію: достатньо описати завдання.

Терміни та вартість

Один тип sidecar (логування або git-sync) — 1-2 дні на проектування та тест. Service mesh з Istio — до 1 тижня. Вартість впровадження одного sidecar — від $500, економія ресурсів до 40% CPU зменшує витрати на хмару на $2000 на місяць при 100 подах. Середня економія ресурсів при переході з DaemonSet на sidecar — до 40% CPU.

Замовте аудит поточної інфраструктури — виявимо вузькі місця та запропонуємо оптимальне рішення.