Sidecar Container Startup Order

K8s 1.28+ supports sidecar startup order. The pattern.

Idea

Sidecar startup order is the discipline of ensuring sidecar containers are ready before the main containers. The native sidecar feature (Kubernetes 1.28+) handles this; pre-1.28 setups require manual coordination.

What native sidecars provide:

• restartPolicy: Always on init container = sidecar.: The native sidecar feature uses init containers with restartPolicy: Always. The init container starts; runs alongside the main; the lifecycle is coordinated.
• Starts before main.: Native sidecars start before the main containers. The main containers can rely on the sidecar being ready; the discipline is built into the lifecycle.
• Runs alongside.: The sidecar runs concurrently with the main containers. It is not just a startup task; it is a long-running co-process.
• Restarts independently.: If the sidecar crashes, it restarts. The main containers are not affected by sidecar restarts; the discipline isolates the lifecycle.
• Stable in 1.29+.: The feature was stabilized in 1.29. Earlier versions had it in beta or alpha; the team's adoption follows the version.

Native sidecars solve a real problem. The discipline is using them when available.

When

Sidecars fit specific patterns. Service mesh proxies, logging agents, observability sidecars all are good candidates.

• Service mesh proxies.: Istio, Linkerd, and similar mesh sidecars must be ready before the main container. Native sidecars handle this; the discipline is automated.
• Logging agents.: Fluent Bit, Vector, and other logging sidecars start before the main; they are ready to capture logs from startup; the discipline is built in.
• Anything pre-main.: Anything that needs to be running before the main containers fits the sidecar pattern. The list is short but important.
• Standard pattern in 1.28+.: Modern Kubernetes makes the pattern easy. The team should use it; legacy workarounds become unnecessary.
• Document the design.: The team's pod specs document why each sidecar exists. Future maintainers understand; the discipline is preserved.

The when-to-use is narrow but important. Native sidecars solve the patterns they are designed for.

Legacy

Pre-1.28 Kubernetes did not have native sidecars. Teams used workarounds; the workarounds are awkward; migration to native sidecars is worthwhile.

• Pre-1.28: manual coordination via init containers.: Before native sidecars, teams used init containers with sleeps, lifecycle hooks, or other workarounds. The patterns were complex; the discipline was fragile.
• Migrate when on supported version.: Teams running 1.28+ should migrate. The native pattern is cleaner; the operational story is simpler; the future is the native pattern.
• Identify legacy patterns.: The team identifies pre-native sidecar patterns in their pod specs. Each is a candidate for migration; the migration is per-pod-spec.
• Test the migration.: The team tests the migrated pattern. The new sidecar behaves as expected; the main container is unaffected; the discipline holds.
• Roll out gradually.: Migration happens gradually. Each application's pod spec migrates at its own pace; new applications use native sidecars from launch.

Sidecar startup order is one of those Kubernetes pod-design patterns that pays off as the cluster modernizes. Nova AI Ops integrates with cluster pod telemetry, surfaces sidecar patterns, and supports the team's design discipline.