Add Sidecar container to running pod(s)

user_1398357 0
Viewed 5482

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).

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).

So far I have understood that sidecar container can be defined inside the same deployment script (deployment configuration).

sidecar openshift fluent-bit kubernetes
2 Answers

Answering the question in the comments:

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.

You can't attach the additional container to a running Pod. You can update (patch) the resource definition. This will force the resource to be recreated with new specification.

There is a github issue about this feature which was closed with the following comment:

After discussing the goals of SIG Node, the clear consensus is that the containers list in the pod spec should remain immutable. #27140 will be better addressed by kubernetes/community#649, which allows running an ephemeral debugging container in an existing pod. This will not be implemented.

-- Github.com: Kubernetes: Issues: Allow containers to be added to a running pod

Answering the part of the post:

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).

Below I've included two methods to add a sidecar to a Deployment. Both of those methods will reload the Pods to match new specification:

  • Use $ kubectl patch
  • Edit the Helm Chart and use $ helm upgrade

In both cases, I encourage you to check how Kubernetes handles updates of its resources. You can read more by following below links:

Use $ kubectl patch

The way to completely avoid editing the Helm charts would be to use:

  • $ kubectl patch

This method will "patch" the existing Deployment/StatefulSet/Daemonset and add the sidecar. The downside of this method is that it's not automated like Helm and you would need to create a "patch" for every resource (each Deployment/Statefulset/Daemonset etc.). In case of any updates from other sources like Helm, this "patch" would be overridden.

Documentation about updating API objects in place:

Edit the Helm Chart and use $ helm upgrade

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 $ helm upgrade RELEASE_NAME CHART.

You can read more about it here:

user_122571340

A kubernetes ressource is immutable, as mention by dawid-kruk . Therefore modifing the pod description will cause the containers to restart.

You can modify the pod using the kubectl patch command, don't forget to reapply the. Patch as necessary.

Alternatively The two following options will inject the sidecar without having to modify/fork upstream chart or mangling deployed ressources.

#1 mutating admission controller

A mutating admission controller (webhook) can modify ressources see https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

You can use a generic framework like opa. Or a specific webhook like fluentd-sidecar-injector (not tested)

#2 support arbitrary sidecar in helm

You could submit a feature request to the chart mainter to supooort arbitrary sidecar injection, like in Prometheus, see https://stackoverflow.com/a/62910122/1260896

user_12608960
Related