We are trying to implement lifecycle preStop and postStart hooks that will be respected by resque workers inside Kubernetes pods. We want to define scripts that will run in the Deis applications by setting environment variables to run preStop and postStart hooks. Except imagine that the command part is just a long environment variable set in Deis environment variables:
The deis/kubernetes process is monitoring the worker process, in our case resque-pool with pid 1. Once we send the -QUIT command to this process, the Kubernetes worker pod enters "CrashBackoffLoop" and restarts the main resque-pool worker process. This is great behavior for resiliency, but not the behaviour we want because we want the pod to be terminated after the workers are terminate gracefully. However, the worker pod is restarted because something is monitoring the main process.
Is there a way we can unhook the deis/kubernetes main process monitor from binding to pid 1 from inside the pod or is there a simpler way to implement lifecycle hooks like the example above?
We were hoping for a successful test so that we can contribute to the deis-workflow by adding environment variables for lifecycle hooks and support for them.
From @Cryptophobia on June 12, 2017 20:46
We are trying to implement lifecycle preStop and postStart hooks that will be respected by resque workers inside Kubernetes pods. We want to define scripts that will run in the Deis applications by setting environment variables to run preStop and postStart hooks. Except imagine that the command part is just a long environment variable set in Deis environment variables:
The problem that we are encountering is this:
The deis/kubernetes process is monitoring the worker process, in our case resque-pool with
pid 1
. Once we send the-QUIT
command to this process, the Kubernetes worker pod enters "CrashBackoffLoop" and restarts the main resque-pool worker process. This is great behavior for resiliency, but not the behaviour we want because we want the pod to be terminated after the workers are terminate gracefully. However, the worker pod is restarted because something is monitoring the main process.Is there a way we can unhook the deis/kubernetes main process monitor from binding to
pid 1
from inside the pod or is there a simpler way to implement lifecycle hooks like the example above?We were hoping for a successful test so that we can contribute to the deis-workflow by adding environment variables for lifecycle hooks and support for them.
Any help would be greatly appreciated.
Copied from original issue: deis/workflow#825