30

I'd like a multi-container pod with a couple of components:

  • A "main" container which contains a build job
  • A "sidecar" container which contains an HTTP proxy, used by the "main" container

This seems to fit well with the pod design philosophy as described in the Kubernetes documentation, but I believe so long as the "sidecar" runs, the pod is kept alive. In my case, the "main" container is not long-lived; once it exits, the "sidecar" should be terminated.

How can I achieve this?

obeattie
  • 3,264
  • 2
  • 31
  • 36

5 Answers5

23

A pod is running as long as one of the containers is running. If you need them to exit together, you have to arrange that the sidecar dies. We do not have a notion of "primary" vs "secondary" containers wrt lifecycle, though that's sort of interesting.

One option would be to use an emptyDir volume and write a file telling the sidecar "time to go". The sidecar would exit when it sees that file.

Tim Hockin
  • 3,567
  • 13
  • 18
  • In my case the problem is the side car is not completely under my control -- it's a service from a third party (closed source), so I don't know how to arrange for this service to stop except if it were possible to send a signal to its process. – Anton Daneyko Dec 15 '21 at 11:34
  • A common pattern is to use this container as a base image for your own image (dockerfile FROM). Add a script and change the entrypoint to this script, and do something like: run "real" app in background, while file /pod/exit-now does not exist, sleep 3 seconds; loop; kill real app – Tim Hockin Dec 16 '21 at 19:47
  • Also, there is a new KEP to teach k8s about "main" containers. I have not reviewed it et, but there is a clear need. – Tim Hockin Dec 16 '21 at 19:49
  • Great idea, thank you for sharing. I ended up with something similar -- turned on shared process namespace and then the "worker" container sends SIGTERM to the other container that is out of my control (this, however, did not completely solve my problem, cause the app that received SIGTERM exited with non-zero code and the job that owned the pod was in some weird state [I do not recall now exactly which ATM]). – Anton Daneyko Dec 16 '21 at 20:56
6

For anyone still looking for an answer to this, the sidecar feature is being developed and should be out in v1.17 of Kubernetes, which will have this exact requested behaviour.

From the proposal:

One-line enhancement description: Containers can now be a marked as sidecars so that they startup before normal containers and shutdown after all other containers have terminated.

https://github.com/kubernetes/enhancements/issues/753

UPDATE: looks like it's planned for v1.18 now

Jonas D
  • 258
  • 5
  • 14
1

Have you considered using the http://kubernetes.io/docs/user-guide/jobs/ resource?

bfallik
  • 2,825
  • 1
  • 11
  • 9
  • 6
    Yes, these pods are running under a job. But I think so long as the "sidecar" container stays up, the job will remain running. – obeattie Jul 28 '16 at 09:35
1

The feature might not have been available when the question was asked but, one can define postStart and preStop handlers for pod now. You could probably define preStop in your main container to kill sidecar container.

Hem
  • 619
  • 13
  • 26
0

You could use the liveness probe to help with this. The probe checks for the "main" container (as well as any of its own checks). Once the main container goes down, the liveness probe fails, and then the pod should be recycled.

Arun Ramakrishnan
  • 128
  • 8