content_image/814009.jpg
## Poststart Hook 

Using only process signals for managing lifecycles is somewhat limited. That is why there are additional lifecycle hooks such as postStart  and preStop  provided by Kubernetes. A Pod manifest containing a postStart  hook looks like the one in Example 5-1. 

apiVersion : v1 kind : Pod metadata : name : post-start-hook spec : containers : - image : k8spatterns/random-generator:1.0 name : random-generator lifecycle : postStart : exec : command : - sh - -c - sleep 30 && echo "Wake up!" > /tmp/postStart_done 

The postStart  command waits here 30 seconds. sleep  is just a simulation for any lengthy startup code that might run here. Also, it uses a trigger file here to sync with the main application, which starts in parallel. 

<img src='content_image/814009.jpg'>

The postStart  command is executed after a container is created, asynchronously with the primary container’s process. Even if many of the application initialization and warm-up logic can be implemented as part of the container startup steps, post Start  still covers some use cases. The postStart  action is a blocking call, and the container status remains Waiting  until the postStart  handler completes, which in turn keeps the Pod status in the Pending  state. This nature of postStart  can be used to delay the startup state of the container while giving time to the main container process to initialize. 

Another use of postStart  is to prevent a container from starting when the Pod does not fulfill certain preconditions. For example, when the postStart  hook indicates an error by returning a nonzero exit code, the main container process gets killed by Kubernetes. 

