Container Lifecycle Hooks [page]deterministic
This page describes how kubelet managed Containers can use the Container lifecycle hook framework to run code triggered by events during their management lifecycle.
## Overview
Analogous to many programming language frameworks that have component lifecycle hooks, such as Angular, Kubernetes provides Containers with lifecycle hooks. The hooks enable Containers to be aware of events in their management lifecycle and run code implemented in a handler when the corresponding lifecycle hook is executed.
## Container hooks
There are two hooks that are exposed to Containers:
`PostStart`
This hook is executed immediately after a container is created. It runs concurrently with the container's `ENTRYPOINT` (main process), meaning the hook may run before, during, or after the main process starts.
No parameters are passed to the handler.
> Note: While the hook runs concurrently with the container process, it can delay container status updates; the container may not transition to `Running` until the hook completes.
`PreStop`
This hook is called immediately before a container is terminated due to an API request or management event such as a liveness/startup probe failure, preemption, resource contention and others. A call to the `PreStop` hook fails if the container is already in a terminated or completed state and the hook must complete before the TERM signal to stop the container can be sent. The Pod's termination grace period countdown begins before the `PreStop` hook is executed, so regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period. No parameters are passed to the handler.
A more detailed description of the termination behavior can be found in [Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
`StopSignal`
The StopSignal lifecycle can be used to define a stop signal which would be sent to the container when it is stopped. If you set this, it overrides any `STOPSIGNAL` instruction defined within the container image.
A more detailed description of termination behaviour with custom stop signals can be found in [Stop Signals](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-stop-signals).
### Hook handler implementations
Containers can access a hook by implementing and registering a handler for that hook. There are three types of hook handlers that can be implemented for Containers:
* Exec - Executes a specific command, such as `pre-stop.sh`, inside the cgroups and namespaces of the Container. Resources consumed by the command are counted against the Container. * HTTP - Executes an HTTP request against a specific endpoint on the Container. * Sleep - Pauses the container for a specified duration.
### Hook handler execution
When a Container lifecycle management hook is called, the Kubernetes management system executes the handler according to the hook action, `httpGet`, `tcpSocket` ([deprecated](/docs/reference/generated/kubernetes-api/v1.35/#lifecyclehandler-v1-core)) and `sleep` are executed by the kubelet process, and `exec` is executed in the container.
The `PostStart` hook handler call is initiated when a container is created, meaning the container ENTRYPOINT and the `PostStart` hook are triggered simultaneously. (This means it generally doesn't make sense to use an HTTP hook for `PostStart`, since there is no guarantee that the container's process will have fully started up when the hook runs.) If the `PostStart` hook takes too long to execute or if it hangs, it can prevent the container from transitioning to a `running` state.
`PreStop` hooks are not executed asynchronously from the signal to stop the Container; the hook must complete its execution before the TERM signal can be sent. If a `PreStop` hook hangs during execution, the Pod's phase will be `Terminating` and remain there until the Pod is killed after its `terminationGracePeriodSeconds` expires. This grace period applies to …(trimmed)