Skip to content

Latest commit

 

History

History
65 lines (47 loc) · 2.75 KB

README.adoc

File metadata and controls

65 lines (47 loc) · 2.75 KB

Managed Lifecycle

For this simple example, you need access to a Kubernetes installation. Anyone as described in INSTALL is good enough.

Our sample random-genertore application provides a /shutdown endpoint which we use to log its call during shutdown of a Pod.

But lets create the Pod first:

kubectl create -f pod.yml

and verify its status with

kubectl get pods -w

As you can see, the Pod only starts only after 30s because we use a sleep 30 as preStart hool (you can’t even check the logs before).

In order to watch the logs during shutdown we start a kubectl logs in the background:

kubectl logs -f random-generator &

You can see the postStart message which has been picked up by random generator during startup and copied to the standard output of the application container. The environment variable WAIT_FOR_POST_START that we set for our main application container indicates the random generator application to wait until the postStart file has been created:

io.k8spatterns.examples.RandomGeneratorApplication - Waiting for postStart to be finished ....
io.k8spatterns.examples.RandomGeneratorApplication - Waiting for postStart to be finished ....
io.k8spatterns.examples.RandomGeneratorApplication - Waiting for postStart to be finished ....
io.k8spatterns.examples.RandomGeneratorApplication - postStart Message: Wake up!
....

Now let’s kill the Pod:

kubectl delete pod random-generator

You should see in the logs messages like the following which indicate that our /shutdown endpoint as been called indeed:

....
i.k.examples.RandomGeneratorApplication  : SHUTDOWN NOW
o.s.s.concurrent.ThreadPoolTaskExecutor  : Shutting down ExecutorService 'applicationTaskExecutor'
i.k.examples.RandomGeneratorApplication  : >>>> SHUTDOWN HOOK called. Possibly because of a SIGTERM from Kubernetes
Note
You could also use OpenShift for this example, e.g. by using Minishift. In this case you could also examine the log of the container after this has been finished, with oc debug. This is not possible with Kubernetes, so we start the log output command before we kill the Pod.