# Kubernetes Lifecycle – Hooks Lifecycle hooks allow to execute code at specific points in a container's lifecycle. Kubernetes supports the following hooks: 1. **PreStart**: This hook executes immediately before a container is created. It provides a way to run setup scripts or custom commands before the application within the container starts. Note that the container’s main process does not start until the preStart hook completes successfully 2. **PostStart**: This hook executes immediately after a container is created, but there is no guarantee that it will run before the container’s entrypoint or main process starts. This is useful for configuration tasks that need to occur right after container startup 3. **PreStop**: This hook is called immediately before a container is terminated due to an API request or management event such as scaling down or pod re-deployment (*SIGTERM*). It is used to gracefully shut down the application, such as saving state or performing cleanup tasks. It’s important because it allows for a graceful shutdown before the container is killed and delays the sending of the *SIGTERM* to the application ## Termination ### Handling *SIGTERM* *SIGTERM* is the signal that is sent by kubelet to a container to request its termination. It’s a way for Kubernetes to politely ask a container to shut down, the source code for this sequence can be seen [here](https://github.com/kubernetes/kubernetes/blob/cae35dba5a3060711a2a3f958537003bc74a59c0/pkg/kubelet/kuberuntime/kuberuntime_container.go#L732-L796): - **Step 1**: A Delete pod event is sent to the kubelet and Endpoint Controller (which manages the Service endpoints - more specifically Endpoints and EndpointSlices) - This stops sending new traffic to the corresponding pod - **Step 2**: The Kubelet starts a timer for a grace period (the default is 30 seconds, configurable via `terminationGracePeriodSeconds`) - **Step 3a**: The kubelet executes the `PreStop` hook if it has been defined. This gives the application a chance to execute custom shutdown procedures if it cannot handle itself by catching the *SIGTERM* signal - If the application doesn't handle *SIGTERM* properly, it's a good idea to use, for example, `sleep 10`, so it will delay the sending of *SIGTERM* (by delaying the completion of the `PreStop` hook) - The `sleep` binary has to exist in the application container – [new Kubernetes versions](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3960-pod-lifecycle-sleep-action/README.md) could support custom configuration without the need for a `sleep` binary in the container - **Step 3b**: After finishing the `PreStop` hook (if defined), the kubelet sends a *SIGTERM* signal to the main process (PID 1) in the container - If using `sleep 10` in the `PreStop`, the process has about 20 seconds to terminate itself or it will receive a SIGKILL without a chance to clean up > [!warning] > Steps **2** and **3** are run asynchronously. There is a possibility that an application can receive a *SIGTERM* and there will still be traffic going to it for a while. ## References - [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) - [kubernetes/pkg/kubelet/kuberuntime](https://github.com/kubernetes/kubernetes/tree/cae35dba5a3060711a2a3f958537003bc74a59c0/pkg/kubelet/kuberuntime)