DevOps Intermediate
Container Orchestration Patterns¶
KubernetesPatternsContainerizationArchitecture 6 min read
Design patterns for container orchestration. Sidecar, Ambassador, Adapter, Init Container and more.
Sidecar Pattern¶
A sidecar container extends the main container with additional functionality: logging, monitoring, proxy.
spec:
containers:
- name: app
image: myapp:latest
ports:
- containerPort: 8080
- name: log-shipper
image: fluent-bit:latest
volumeMounts:
- name: logs
mountPath: /var/log/app
volumes:
- name: logs
emptyDir: {}
Init Container Pattern¶
Init containers run before the main container. Use cases: migrations, wait-for-dependency, config setup.
spec:
initContainers:
- name: wait-for-db
image: busybox
command: ['sh', '-c',
'until nc -z postgres 5432; do sleep 2; done']
- name: db-migrate
image: myapp:latest
command: ['./migrate', 'up']
containers:
- name: app
image: myapp:latest
Ambassador Pattern¶
An ambassador container acts as a proxy for the main container — TLS termination, connection pooling, circuit breaking.
spec:
containers:
- name: app
image: myapp:latest
env:
- name: DB_HOST
value: localhost # connects via ambassador
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:latest
command:
- /cloud_sql_proxy
- -instances=project:region:db=tcp:5432
Adapter Pattern¶
An adapter container transforms the main container’s output into a standard format (e.g., custom metrics into Prometheus format).
Summary¶
Multi-container patterns (Sidecar, Init, Ambassador, Adapter) solve cross-cutting concerns without modifying application code.
Need Help with Implementation?¶
Our team has experience designing and implementing modern architectures. We’re happy to help.