Kubernetes SidecarContainers feature is merged

While this is a very welcome improvement in terms of functionality, I can&#x27;t help by feel that the re-use of &quot;restartPolicy&quot; to mean something similar, but different, when used in a different context, is a very poor decision.<p>Kubernetes already has an issue with having a (perceived) high barrier to entry, and I&#x27;m not sure that &quot;restartPolicy on a container means this, unless isn&#x27;t used in <i>this</i> list of containers, in which case it means this&quot;.<p>I would have preferred to see a separate attribute (such as `sidecar: true`), rather than overloading (and in my opinion, abusing) the existing `restartPolicy`.

A very welcome change. It&#x27;s gonna be helpful for the case where the database proxy (CloudSQL) and the main container got terminated out of order.<p><a href="https:&#x2F;&#x2F;cloud.google.com&#x2F;sql&#x2F;docs&#x2F;postgres&#x2F;connect-kubernetes-engine" rel="nofollow noreferrer">https:&#x2F;&#x2F;cloud.google.com&#x2F;sql&#x2F;docs&#x2F;postgres&#x2F;connect-kubernete...</a>

On the one hand, great.<p>The other hand, one of the main criticisms of Kubernetes is that it has no composition or orchestration capabilities. It&#x27;s great about defining pieces of state, but managing blocks of state &amp; multiple things at once is left almost entirely to external tools.<p>The ability to compose &amp;sequence multiple containers feels like a very specific example of a much broader general capability. There&#x27;s bedevilling infinite complexity to trying to figure out a fully expressive state of state management system - I get why refining a couple specialized existing capabilities is the way - but it does make me a little sad to see a lack of appetite for the broader crosscutting system problem at the root here.

Worth noting that this is hitting Alpha in Kubernetes 1.28, so won&#x27;t be available by default at this stage.<p>If you&#x27;ve got self-managed clusters, it&#x27;d be possible to enable with a feature gate on the API server, but it&#x27;s unlikely to be available on managed Kubernetes until it gets to GA.

In case anyone else was looking for a clear, concise summary of the new feature:<p>&quot;The new feature gate &quot;SidecarContainers&quot; is now available. This feature introduces sidecar containers, a new type of init container that starts before other containers but remains running for the full duration of the pod&#x27;s lifecycle and will not block pod termination.&quot;

It&#x27;s a shame it took so long. If the main container shutdown (i.e connection drain, processing inflight queue items) takes a while, and your service mesh dies (nice go binary) and main container cannot communicate with internet anymore.<p>But I&#x27;m not sure about initContainers being used. init keyword implies it&#x27;d run and die in order for others to continue. Using restartPolicy with init instead of a dedicated sideCars field feels weird.

Any documentation on this? What does this mean?

KEP: <a href="https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;enhancements&#x2F;tree&#x2F;master&#x2F;keps&#x2F;sig-node&#x2F;753-sidecar-containers">https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;enhancements&#x2F;tree&#x2F;master&#x2F;keps&#x2F;...</a><p>TLDR: Introduce a restartPolicy field to init containers and use it to indicate that an init container is a sidecar container. Kubelet will start init containers with restartPolicy=Always in the order with other init containers, but instead of waiting for its completion, it will wait for the container startup completion.

When I first learned about the sidecar pattern I thought it was great. I am not sure about it anymore. Most of it could be propagated to custom images or layers at the boundary. To me this feels a bit sketchy. Too have containers that kinda is part of the mesh but then does not share the same lifecycle as the mesh.

&gt; Pod is terminated even if sidecar is still running<p>this is great for things like Jobs and Istio<p>eliminates the scheme where the main container had to signal to the sidecar it was exiting otherwise the pod would hang

Is there a clean way to share an emptyDir between sidecar(s) and main container(s)?<p>Looking at the logging usecase and want to be able to add a log shipper sidecar to a pod with ephemeral storage.

This is great. My team at Netflix (I&#x27;m not longer there) sponsored some of the work behind this, via Kinvolk (now acquired by MSFT). Great to see that it finally shipped. At the time, this was a blocker to us using Kubelet, and we thought it might take a few...months to sort out. Turns out it was closer to a few years, but its a tricky API, and important to get right.

The lack of native sidecar support was my biggest surprise when moving from ECS to EKS, and it was not fun hacking with shared process IDs to accomplish sidecars. I&#x27;m glad this is finally in but also curious how it takes roughly 3ish years(?) from KEP proposal to merge?

How does the syntax look for defining a sidecar in a deployment? Is it similar to initContainers?