Skip to content
CloudOps
All prompts
AI for Kubernetes & Helm Difficulty: Intermediate ClaudeChatGPT

Kubernetes Native Sidecar Containers Prompt

Migrate to native sidecar containers (1.28+) — `initContainers` with `restartPolicy: Always`, ordering, graceful shutdown, common patterns (service mesh, log shipper).

Target user
Kubernetes engineers adopting native sidecars
Difficulty
Intermediate
Tools
Claude, ChatGPT

The prompt

You are a senior Kubernetes engineer who has migrated workloads to native sidecar containers (1.28+ feature). You know the differences from traditional sidecars (regular containers) and how to handle ordering and graceful shutdown.

I will provide:
- The workload using sidecars (service mesh proxy, log shipper, secret injector, etc.)
- K8s version
- Symptom (if debugging: sidecar not starting first, main dies before sidecar, etc.)

Your job:

1. **Native sidecars** (1.28+):
   - Defined in `initContainers` with `restartPolicy: Always`
   - Start BEFORE other containers in startup order
   - Run alongside containers (not sequentially like normal init)
   - Terminate AFTER main containers (reverse shutdown)
   - Restart independently on failure
2. **For "main can't reach sidecar at startup"**:
   - With traditional sidecars (regular containers): race; both start simultaneously
   - With native sidecars: sidecar fully started before main begins
   - Migration solves this race
3. **For "sidecar dies before main during shutdown"**:
   - Traditional: both get SIGTERM simultaneously; sidecar may exit first leaving main without (e.g.) logging
   - Native: main gets SIGTERM first; sidecar receives it AFTER main exits
   - Critical for log shippers, mesh proxies
4. **For service mesh** (Istio, Linkerd):
   - Traditional injection: regular container; startup race
   - Native injection: sidecar; clean ordering
   - Mesh vendors adopting native sidecars
5. **For log shippers** (Fluent Bit, Vector):
   - Native: main writes logs until exit; sidecar ships then exits
   - Traditional: sidecar may exit first, losing tail logs
6. **Migration path**:
   - Update K8s to 1.28+ (1.29 GA)
   - Move sidecar from `containers` to `initContainers` with `restartPolicy: Always`
   - Test ordering
   - Update logging/mesh injectors to emit native form
7. **For backwards compat**:
   - Older K8s: ignores `restartPolicy: Always` in initContainers; treats as normal init (runs once)
   - Pin minimum K8s version

Mark DESTRUCTIVE: migrating without K8s version check (sidecar becomes init = runs once), changing sidecar resource limits without retest, removing health checks on sidecar (silent failures).

---

Workload + sidecar: [DESCRIBE]
K8s version: [DESCRIBE]
Symptom: [DESCRIBE]

Why this prompt works

Native sidecars solve real problems (startup race, shutdown order) but require migration. This prompt walks the migration.

How to use it

  1. Verify K8s version 1.28+.
  2. Identify sidecars needing migration.
  3. Test ordering before production.
  4. Coordinate with mesh / logging tools.

Useful commands

# K8s version check
kubectl version
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.kubeletVersion}'

# Check feature gates (1.28-1.29)
kubectl get --raw /metrics | grep feature_gate

# View pod with sidecars
kubectl get pod <pod> -o yaml | yq '.spec.initContainers, .spec.containers'

# Logs from native sidecar
kubectl logs <pod> -c <sidecar-name>

# Per-container restart count
kubectl get pod <pod> -o jsonpath='{range .status.containerStatuses[*]}{.name}: {.restartCount}{"\n"}{end}'
kubectl get pod <pod> -o jsonpath='{range .status.initContainerStatuses[*]}{.name}: {.restartCount}{"\n"}{end}'

Migration example

Traditional sidecar (pre-1.28)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  template:
    spec:
      containers:
      - name: app
        image: myapp
      - name: log-shipper            # traditional sidecar
        image: fluentbit
        volumeMounts:
        - name: logs
          mountPath: /logs
      volumes:
      - name: logs
        emptyDir: {}

Native sidecar (1.28+)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  template:
    spec:
      initContainers:
      - name: log-shipper           # native sidecar
        image: fluentbit
        restartPolicy: Always        # makes it a sidecar
        volumeMounts:
        - name: logs
          mountPath: /logs
        # Optional probes
        livenessProbe:
          httpGet:
            path: /api/v1/health
            port: 2020
      containers:
      - name: app
        image: myapp
        volumeMounts:
        - name: logs
          mountPath: /logs
      volumes:
      - name: logs
        emptyDir: {}

Common findings this catches

  • Sidecar runs as init (once) on K8s < 1.28 → upgrade or stick with traditional.
  • Main fails to reach sidecar at startup → native sidecar resolves this race.
  • Logs from app lost during shutdown → native sidecar (shipper exits AFTER main).
  • Mesh injection still using container → check mesh version supports native; some inject as both.
  • Sidecar crashloop blocking pod — independent restart with native; check restart count.
  • Resource budget surprise — native sidecar counts; review QoS.
  • Liveness probe on sidecar kills pod — design carefully.

When to escalate

  • Service mesh native sidecar adoption — coordinate with mesh team.
  • Logging architecture migration — staged rollout.
  • 1.28+ adoption gating — cluster upgrade.

Related prompts

Newsletter

Get weekly AI workflows for DevOps engineers

Practical prompts, automation ideas, and tool reviews for infrastructure engineers. One email per week. No spam.