Multi-Container Pod with Shared Volumes

Build a Kubernetes pod with multiple containers sharing data through emptyDir volumes. Demonstrates the ambassador and adapter patterns with a web server and metrics exporter.

Advanced

Detailed Explanation

Multi-Container Pod Patterns

Kubernetes pods can contain multiple containers that share network and storage. This enables powerful patterns where containers collaborate without being tightly coupled in the same process.

Key Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-with-metrics
  labels:
    app: "web"
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: web
          image: my-web-app:latest
          ports:
            - name: http
              containerPort: 8080
          volumeMounts:
            - name: shared-data
              mountPath: /app/data
        - name: metrics-exporter
          image: prom/statsd-exporter:latest
          ports:
            - name: metrics
              containerPort: 9102
          volumeMounts:
            - name: shared-data
              mountPath: /data
              readOnly: true
          resources:
            requests:
              cpu: "25m"
              memory: "32Mi"
            limits:
              cpu: "100m"
              memory: "64Mi"
      volumes:
        - name: shared-data
          emptyDir: {}

Multi-Container Patterns

Sidecar: Extends the main container (log forwarder, proxy, config reloader)

Ambassador: Proxies network traffic for the main container (local cache, connection pooling)

Adapter: Transforms the main container's output (metrics format converter, log parser)

Container Communication

Containers in the same pod can communicate through:

  1. Shared volumes: Write files to a shared emptyDir
  2. Localhost networking: All containers share the same network namespace (localhost:port)
  3. Shared process namespace: Enable with shareProcessNamespace: true for signal sending

Considerations

  • All containers in a pod are scheduled on the same node
  • Resource requests/limits are summed across all containers
  • If any container fails its liveness probe, the entire pod may be restarted
  • Container startup order within a pod is not guaranteed (use init containers for ordering)

Use Case

Building complex applications that require multiple cooperating processes, such as a web server with a metrics exporter, or an application with a local cache proxy for external API calls.

Try It — K8s Pod Spec Builder

Open full tool