CKAD — Adapter Pattern

What Is the Adapter Pattern?

The adapter pattern transforms the output of the main container into a format that external systems expect. Think of it as a translator sitting next to your application.

The main container produces output in its native format, and the adapter container converts it into a standardized format — without modifying the application itself.

How It Works

┌──────────────────────────────────────────────┐
│                     Pod                      │
│                                              │
│ ┌───────────┐  shared   ┌─────────────────┐ │
│ │    App     │──volume──→│    Adapter      │─│──→ External System
│ │ Container  │           │   (Transformer) │ │    (expects format B)
│ │            │           │                 │ │
│ │ writes     │           │ reads format A  │ │
│ │ format A   │           │ outputs format B│ │
│ └───────────┘            └─────────────────┘ │
└──────────────────────────────────────────────┘

Common Use Cases

Use Case	What the Adapter Does
Log formatting	Converts plain text logs into structured JSON
Metrics transformation	Reformats app metrics for Prometheus scraping
Data normalization	Converts app output to a standard schema
Protocol translation	Converts between data formats (XML → JSON)
Monitoring integration	Transforms health data for external dashboards

Example: Log Adapter

The main container writes plain text logs. The adapter transforms them into JSON for consumption by logging systems.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-adapter
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ["/bin/sh", "-c"]
    args:
    - |
      while true; do
        echo "$(date +%s) INFO user_login count=1" >> /var/log/app.log
        sleep 5
      done
    volumeMounts:
    - name: logs
      mountPath: /var/log

  - name: adapter
    image: busybox:1.36
    command: ["/bin/sh", "-c"]
    args:
    - |
      tail -f /var/log/app.log | while read line; do
        ts=$(echo $line | awk '{print $1}')
        level=$(echo $line | awk '{print $2}')
        msg=$(echo $line | awk '{$1=$2=""; print $0}')
        echo "{\"timestamp\": $ts, \"level\": \"$level\", \"message\": \"$msg\"}"
      done
    volumeMounts:
    - name: logs
      mountPath: /var/log

  volumes:
  - name: logs
    emptyDir: {}

kubectl apply -f app-with-adapter.yaml

# View raw app logs
kubectl logs app-with-adapter -c app
# Expected: 1738999800 INFO user_login count=1

# View adapted JSON logs
kubectl logs app-with-adapter -c adapter
# Expected: {"timestamp": 1738999800, "level": "INFO", "message": " user_login count=1"}

Adapter vs Modifying the App

Approach	Pros	Cons
Modify the app to output the right format	No extra container needed	Must change application code
Use an adapter container	App stays unchanged, single responsibility	Extra container overhead

The adapter pattern follows the single responsibility principle — each container does one thing well. The app focuses on business logic, the adapter handles output transformation.

Adapter vs Sidecar

Both run alongside the main container, but the intent is different:

Pattern	Direction	Purpose
Sidecar	Extends the main container’s capabilities	Log shipping, proxying, config watching
Adapter	Transforms output to match external expectations	Format conversion, metrics reformatting

In practice, the line between them can be blurry. The CKAD exam focuses on understanding the intent behind each pattern.

Exam tip: When the exam describes a container that transforms or reformats data produced by the main container, that’s the adapter pattern. The key word is transform.

---

Next: Learn operational commands with Managing Multi-Container Pods →