architectpods

How do Kubernetes native sidecar containers change startup ordering, readiness, and Job completion compared with ordinary app containers?

⚡

Quick Answer

Native sidecars are init containers with `restartPolicy: Always`, so Kubernetes starts them during initialization but keeps them running for the lifetime of the Pod. Their readiness can affect Pod readiness, and for Jobs they do not prevent completion once the main container exits.

Detailed Answer

Think of a restaurant opening for dinner. The kitchen can start cooking only after the exhaust fan and point-of-sale terminal are running, but those support systems must keep working after the first meal is served. A native sidecar container is that support system: it starts before or alongside the main work, keeps running, and is not the reason the restaurant exists.

In Kubernetes, native sidecars solve the long-standing awkwardness of treating log shippers, mesh proxies, and credential refreshers as normal containers. A normal app container has no special startup relationship to the main workload. A traditional init container runs to completion before app containers start. A native sidecar sits between those ideas: it is listed under initContainers, but restartPolicy: Always tells Kubernetes to keep it alive as a supporting container.

Internally, kubelet processes init containers in order. When it reaches an init container with restartPolicy: Always, it starts that container and continues once the sidecar has started successfully. The app containers then start while the sidecar remains running. If the sidecar has a readiness probe, Kubernetes includes that probe when calculating whether the Pod is Ready. During shutdown, Kubernetes terminates app containers first, then sidecars, which is important for log flushing and proxy drain behavior.

At production scale, this changes rollout and observability practices. Teams should monitor sidecar restart count, readiness probe failures, log shipping lag, and whether the sidecar adds startup latency. For Jobs, the sidecar no longer keeps the Job alive forever after the main container has completed, which removes a common operational trap in batch workloads that need a helper process.

The non-obvious gotcha is that native sidecars are still part of the Pod resource budget and lifecycle. A slow or unhealthy sidecar can block readiness for an otherwise healthy app, and a sidecar with an aggressive readiness probe can cause endpoints to flap under dependency pressure. Architects should treat sidecars as production dependencies with SLOs, not invisible helper containers.

# Apply a Deployment that starts a log shipper as a native sidecar before the API container kubectl apply -f payments-api-native-sidecar.yaml # Verify the sidecar appears under init container status while continuing to run kubectl get pod -l app=payments-api -n payments -o jsonpath='{.items[0].status.initContainerStatuses[0].state}' # Check whether sidecar readiness is affecting the Pod Ready condition kubectl describe pod -l app=payments-api -n payments | grep -A6 'Conditions' # payments-api-native-sidecar.yaml apiVersion: apps/v1 # Uses the stable Deployment API for a replicated service kind: Deployment # Manages rollout and replacement of payments-api Pods metadata: name: payments-api # Realistic production service name namespace: payments # Keeps the service isolated from other teams spec: replicas: 3 # Runs three Pods so one sidecar issue does not stop all traffic selector: matchLabels: app: payments-api # Connects the Deployment to its Pods template: metadata: labels: app: payments-api # Allows Service and observability selectors to find Pods spec: initContainers: - name: logshipper # Supporting container that tails application logs image: alpine:3.20 # Small image for a simple tailing process restartPolicy: Always # Makes this init container a native sidecar command: ['sh','-c','tail -F /var/log/payments/access.log'] # Keeps log streaming active volumeMounts: - name: app-logs # Mounts the same log volume as the app container mountPath: /var/log/payments # Path where the app writes logs readinessProbe: exec: command: ['sh','-c','test -d /var/log/payments'] # Marks sidecar ready only after the shared path exists periodSeconds: 5 # Checks readiness frequently during rollout containers: - name: api # Primary business container image: registry.company.com/payments-api:2.8.4 # Versioned production image ports: - containerPort: 8080 # API listens on port 8080 inside the Pod volumeMounts: - name: app-logs # Shares log files with the sidecar mountPath: /var/log/payments # Write location for request logs volumes: - name: app-logs # Empty volume shared by the app and sidecar emptyDir: {} # Lives only for the Pod lifetime

How do Kubernetes native sidecar containers change startup ordering, readiness, and Job completion compared with ordinary app containers?

More Kubernetes questions