Sidecar pattern
Sidecar pattern — containers, работающие рядом с main application container в одном Kubernetes pod. Share network + volumes, но отдельные processes. Используется для: log shipping (Fluent Bit sidecar), service mesh (Envoy proxy), config reload (watch ConfigMap), secrets sync (Vault agent), data synchronization. Главный plus: separation of concerns без application code changes.
Ниже: подробности, пример, смежные термины, FAQ.
Подробности
- 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: {}Смежные термины
Больше по теме
Часто задаваемые вопросы
Sidecar vs multi-process container?
Sidecar — separate container (different image + update cycle). Multi-process — все в одном image (anti-pattern в K8s, usage supervisord). Sidecar cleaner.
Overhead?
Каждый sidecar adds: ~30-100 MB memory, CPU slice. В 100-pod cluster — significant. Используйте только когда нужно.
Common pitfalls?
Sidecar crash → pod kill если restartPolicy: Always. Используйте lifecycle hooks + правильный readiness probe.