Sidecar

Паттерн sidecar: инфраструктурный процесс рядом с приложением (прокси, телеметрия). Не отсек runtime и не сага.

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

На каком слое надёжности работает «Sidecar»

Инфраструктура рядом с процессом: отдельный контейнер или процесс в той же единице размещения.

Какой отказ моделирует паттерн «Sidecar»

прикладной код тащит TLS, ретраи, метрики, идентичность — или наоборот, без единого контура политики сеть «ломается у каждого сервиса по-своему». Отказ, который моделируем: несогласованная политика и судьба приложения вместе с помощником.

Что изолирует «Sidecar» и где кончается радиус взрыва

радиус инфраструктурного контура вокруг одного экземпляра. Приложение и sidecar обычно делят судьбу (fate-sharing): умер под — умерли оба. Это не изоляция арендаторов и не компенсация заказа.

Когда паттерн «Sidecar» применять нельзя

не ставить sidecar, чтобы «стать надёжнее», если не ясны политики, которые он несёт. Не путать с антикоррупционным слоем домена. Не замена Bulkhead: лимиты вызовов всё равно чьи-то.

Что записать в архитектурное решение (ADR) про «Sidecar»

какие обязанности вынесены, как отлаживать «чей таймаут», лимиты ресурсов sidecar, что будет при рассинхроне версии dataplane.

Оценка качеств «Sidecar»: масштабируемость, надёжность, сопровождение

Звёзды — ориентир автора сайта, не бенчмарк и не сравнение продуктов.

  • масштабируемость: ⭐⭐⭐⭐ (4/5)
  • надежность: ⭐⭐⭐⭐ (4/5)
  • сопровождение: ⭐⭐⭐ (3/5)

Варианты протокола «Sidecar» и как выбрать

  • Mesh dataplane: прокси ловит трафик, политики задаёт плоскость управления.
  • Утилитарный агент: логи, секреты, не обязательно перехват всего TCP.
  • Постепенное внедрение: сначала критичные сервисы, не весь кластер «потому что Istio».

Схема взаимодействия: как работает «Sidecar»

sequenceDiagram
    participant Клиент
    participant Прокси
    participant Приложение
    Клиент->>Прокси: запрос
    Прокси->>Приложение: дальше
    Приложение-->>Прокси: ответ
    Прокси-->>Клиент: ответ
    Note over Прокси,Приложение: одна единица размещения
единица_размещения:
    процесс приложение
    процесс sidecar  # политика сети/телеметрии
# судьба общая: рестарт единицы гасит оба

Типичные ошибки при внедрении «Sidecar»

  • Включить mesh «для надёжности» без политики ретрая и таймаутов — получите чужой retry-шторм.
  • Отладка только прикладных логов: таймаут жил в прокси.
  • Считать sidecar отсеком: без квот это просто ещё один процесс в том же взрыве.

С какими паттернами не путать «Sidecar»

  • Bulkhead — квоты runtime внутри приложения или воркеров, не соседний процесс.
  • Ретрай с задержкой (Retry with delay) — политика повтора может жить в sidecar, но сам паттерн вызова описывается отдельно.
  • Сага (SAGA) — оркестрация смысла, не dataplane.

Источники для сверки формулировок про «Sidecar»

В российском облаке sidecar на практике появляется как dataplane service mesh в Kubernetes. Yandex Cloud — Istio в Managed Kubernetes.

Частые вопросы про «Sidecar»

Зачем паттерн sidecar?

Вынести прокси, TLS, метрики и политики сети в процесс рядом с приложением, чтобы не тащить это в каждый репозиторий.

Делает ли sidecar систему надёжнее сам по себе?

Нет, если не заданы политики таймаутов и ретрая. Приложение и sidecar обычно делят судьбу в одной единице размещения.

Чем sidecar не является?

Не антикоррупционный слой домена, не сага и не bulkhead: квоты вызовов всё равно нужно задать отдельно.