It is a recommended best practice to not run dockerized Node.JS applications as PID 1 (see https://github.com/nodejs/docker-node/blob/master/docs/BestPractices.md#handling-kernel-signals) in order to correctly capture signals.
The docker run
command provides the --init
flag to wrap the application entry point with a small init system that forwards signals correctly.
Is there a built-in equivalent of the --init
flag in Kubernetes?
I've explored the Pod and Container object specifications for Kubernetes 1.10 but have not seen anything related to specifying how the image gets started.
An alternative would be to explicitly include and use Tini in every container, but I would really like some way that does it transparently the way the --init
flag behaves.
Are there other alternatives?
If you enable process (PID) namespace sharing for your pods, the init process (
pause
) will come from Kubernetes. If you have a separate process namespace for your containers, they need to includetini
or another init process themselves.According to https://www.ianlewis.org/en/almighty-pause-container, Kubernetes 1.7 had a shared process namespace by default and a kubelet flag to disable it, 1.8 had it off by default and a kubelet flag to enable it. Kubernetes 1.11 has an alpha feature to enable a shared process namespace: https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/
If you suppose that Kubernetes creates a container using Docker commands, then you should be aware that it knows nothing about
--init
key. In other words, Kubernetes has no such wrapper for starting a container with another initial process.So, if you want to use this feature in Kubernetes, you need to prepare a Docker image with Tini in it.
Actually, Tini is included in Docker 1.13 or greater, and you just enable it by passing the
--init
flag todocker run
. So, to add Tini to your image, use the following code in theDockerfile
: