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
- Verify K8s version 1.28+.
- Identify sidecars needing migration.
- Test ordering before production.
- 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
-
Kubernetes Init Containers Design Prompt
Design init container patterns — dependency checks, secret pulling, schema migration, image construction; debug init failures and ordering issues.
-
Kubernetes Pod Lifecycle & Graceful Shutdown Prompt
Design and debug pod lifecycle — preStop hooks, terminationGracePeriodSeconds, SIGTERM handling, connection draining, readiness probe behavior on shutdown.
-
Kubernetes Istio Service Mesh Debugging Prompt
Diagnose Istio service mesh issues — sidecar injection failures, mTLS misconfiguration, traffic routing, AuthorizationPolicy denials, Envoy config errors.