<p>I have helm deployment scripts for a vendor application which we are operating. For logging solution, I need to add a sidecar container for fluentbit to push the logs to aggregated log server (splunk in this case).</p>
<p>Now to define this sidecar container, I want to avoid changing vendor defined deployment scripts. Instead i want some alternative way to attach the sidecar container to the running pod(s).</p>
<p>So far I have understood that sidecar container can be defined inside the same deployment script (deployment configuration).</p>

<p>Answering the question in the comments:</p>
<blockquote>
<p>thanks @david. This has to be done before the deployment. I was wondering if I could attach a sidecar container to an already deployed (running) pod.</p>
</blockquote>
<p><strong>You can't attach the additional container to a running <code>Pod</code></strong>. You can update (patch) the resource definition. This will force the resource to be recreated with new specification.</p>
<p>There is a github issue about this feature which was closed with the following comment:</p>
<blockquote>
<p>After discussing the goals of SIG Node, <strong>the clear consensus is that the containers list in the pod spec should remain immutable</strong>. <a href="https://github.com/kubernetes/kubernetes/issues/27140" rel="nofollow noreferrer">#27140</a> will be better addressed by <a href="https://github.com/kubernetes/community/pull/649" rel="nofollow noreferrer">kubernetes/community#649</a>, which allows running an ephemeral debugging container in an existing pod. This will not be implemented.</p>
<p>-- <em><a href="https://github.com/kubernetes/kubernetes/issues/37838" rel="nofollow noreferrer">Github.com: Kubernetes: Issues: Allow containers to be added to a running pod</a></em></p>
</blockquote>
<hr />
<p>Answering the part of the post:</p>
<blockquote>
<p>Now to define this sidecar container, I want to avoid changing vendor defined deployment scripts. Instead i want some alternative way to attach the sidecar container to the running pod(s).</p>
</blockquote>
<p>Below I've included two methods to add a sidecar to a <code>Deployment</code>. <strong>Both of those methods will reload the <code>Pods</code></strong> to match new specification:</p>
<ul>
<li>Use <code>$ kubectl patch</code></li>
<li>Edit the <code>Helm</code> Chart and use <code>$ helm upgrade</code></li>
</ul>
<p>In both cases, I encourage you to check how Kubernetes handles updates of its resources. You can read more by following below links:</p>
<ul>
<li><em><a href="https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/" rel="nofollow noreferrer">Kubernetes.io: Docs: Tutorials: Kubernetes Basics: Update: Update </a></em></li>
<li><em><a href="https://medium.com/platformer-blog/enable-rolling-updates-in-kubernetes-with-zero-downtime-31d7ec388c81" rel="nofollow noreferrer">Medium.com: Platformer blog: Enable rolling updates in Kubernetes with zero downtime</a></em></li>
</ul>
<hr />
<hr />
<h3>Use <code>$ kubectl patch</code></h3>
<p>The way to completely avoid editing the Helm charts would be to use:</p>
<ul>
<li><code>$ kubectl patch</code></li>
</ul>
<p>This method will &quot;patch&quot; the existing <code>Deployment/StatefulSet/Daemonset</code> and add the sidecar. The downside of this method is that it's not automated like Helm and you would need to create a &quot;patch&quot; for every resource (each <code>Deployment</code>/<code>Statefulset</code>/<code>Daemonset</code> etc.). In case of any updates from other sources like Helm, this &quot;patch&quot; would be overridden.</p>
<p>Documentation about updating API objects in place:</p>
<ul>
<li><em><a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/" rel="nofollow noreferrer">Kubernetes.io: Docs: Tasks: Manage Kubernetes objects: Update api object kubectl patch</a></em></li>
</ul>
<hr />
<h3>Edit the <code>Helm</code> Chart and use <code>$ helm upgrade</code></h3>
<p>This method will require editing the Helm charts. The changes made like adding a sidecar will persist through the updates. After making the changes you will need to use the <code>$ helm upgrade RELEASE_NAME CHART</code>.</p>
<p>You can read more about it here:</p>
<ul>
<li><em><a href="https://helm.sh/docs/helm/helm_upgrade/" rel="nofollow noreferrer">Helm.sh: Docs: Helm: Helm upgrade</a></em></li>
</ul>
