Multi Container Pods
Sometimes one container isn’t enough. Multi‑container Pods allow you to run closely coupled containers together. They share the same network and storage, making them ideal for sidecar, adapter, or ambassador patterns.
Why Multi‑Container Pods?
Common use cases:
- Sidecar: A helper container that logs, proxies, or monitors the main app.
- Adapter: Transforms data from the main container to a format expected by external systems.
- Ambassador: Proxies network connections to simplify access to external services.
Example: Main App + Logging Sidecar
Here’s a Pod with an Nginx main container and a sidecar that tails the access log:
apiVersion: v1
kind: Pod
metadata:
name: nginx-with-sidecar
spec:
volumes:
- name: shared-logs
emptyDir: {}
containers:
- name: nginx
image: nginx
volumeMounts:
- name: shared-logs
mountPath: /var/log/nginx
- name: sidecar
image: busybox
command: ["sh", "-c", "tail -f /var/log/nginx/access.log"]
volumeMounts:
- name: shared-logs
mountPath: /var/log/nginxshared-logs volume. The sidecar tails the log file written by Nginx.Communication Between Containers
Containers in the same Pod can communicate via:
- localhost: Since they share the network namespace, they can reach each other on
localhost:port. - Shared volumes: For file‑based communication.
When to Use Separate Pods Instead
If containers don’t need to share network or storage, or if they can be scaled independently, separate Pods are better. For example, a web server and a database should be in different Pods because they can be scaled separately.
Two Minute Drill
- Multi‑container Pods are used for tightly coupled containers that share resources.
- Common patterns: sidecar, adapter, ambassador.
- Containers in the same Pod can communicate via localhost and shared volumes.
- Define multiple containers under
spec.containersin the Pod YAML.
Need more clarification?
Drop us an email at career@quipoinfotech.com