0

I have a kubernetes-based application that uses an operator to build and deploy containers in pods. Sometimes I'd like to run containers in privileged mode to enable performance tracing, but since I'm not deploying the pod/containers directly from a manifest, I cannot simply add privileged mode and the debugfs filesystem mount.

That leaves me to fork the operator code, change where it builds the container spec, and redeploy with the modified operator. Doable, but awkward.

So my question is, is it possible to impose additional attributes to be added to container specs based on some clusterwide setting, either before pods are deployed by the operator? Or to modify the container spec after deployment? I tried that with kubectl edit pod mypod, but that didn't work.

This is on a physical cluster installed with kubespray.

Tim B
  • 424
  • 3
  • 7

1 Answers1

0

There are three things to consider:

  1. Your operator can create a controller (e.g. Deployment) instead of Pod, which allows modifications in the Pod Spec area, thus triggering Deployment's rollout (see rolling update strategy).

  2. Use MutatingAdmissionWebhook so before creating the Pod, its manifest would be modified/overwritten on the fly. More info regarding MutatingAdmissionWebhook can be found here and here.

  3. A workaround solution in a form of modifying the supply spec -> swapping the pod-a. More about this was discussed here.

Please let me know if any of the above helped.

Wytrzymały Wiktor
  • 11,492
  • 5
  • 29
  • 37
  • MutatingAdmissionWebhook looks like the right solution. I’ll do some homework and try it and report back to accept the answer. Thanks for the pointer! – Tim B Aug 21 '19 at 22:46