Chapter 5. Pod and Container Lifecycles

 

With Kubernetes being a declarative system, the lifecycle and hooks that are offered for Pods and Containers are the points where your code can take actions. Pods have a lifecycle, as do containers, and Kubernetes offers a number of places where you can provide explicit feedback to the system to have it operate as you’d like. In this chapter, we will dig into the expected lifecycle, hooks available to use, and examples of how to use them.

The topics will include:

• Pod lifecycle
• Container lifecycle
• Probes
• Container hook: post-start and pre-stop
• Initialization containers
• How to handle a graceful shutdown

Pod lifecycle

The lifecycle of a Pod is an aggregate of several components, as a Pod has a number of moving parts that can be in a variety of states as it operates. The representation of the lifecycle is how Kubernetes manages running your code for you, in conjunction with the control and feedback loops that work from the various controllers.

The states of a Pod's lifecycle are:

• Pending: The Pod has been created through the API, and is in the process of being scheduled, loaded, and run on one of the Nodes
• Running: The Pod is fully operational and the software is running within the cluster
• Succeeded (or) Failed: The Pod has finished operation (normally or crashed)
• There is a fourth state: Unknown, which is a fairly rare occurrence and is typically only seen when there’s a problem internal to Kubernetes where it doesn’t know the current state of containers, or is unable to communicate with its underlying systems to determine that state

If you are working with long-running code in Containers, then...

Probes 

The two probes enabled in Kubernetes are the liveness probe and readiness Probe. They are complimentary, but different in intent and usage, and can be defined for each container within a Pod. In both cases, they provide a means for your code to influence how Kubernetes manages the containers.

Liveness probe

The most basic probe is the Liveness probe. If defined, it provides a command or URL that Kubernetes can use to determine whether a Pod is still operational. If the call succeeds, Kubernetes will assume the container is healthy; if it fails to respond, then the Pod can be handled as the restartPolicy is defined. The result is binary: either the probe succeeds, and Kubernetes believes your Pod is running, or it fails, so Kubernetes believes your Pod is no longer functional. In the latter case, it will check with the defined RestartPolicy to choose what to do.

The default value for restartPolicy is Always, meaning if a container within the Pod fails, Kubernetes will always attempt...

Container lifecycle hooks

Kubernetes also provides some hooks within the lifecycle of each container that can be used at setup and teardown time for containers. These are called container lifecycle hooks, and are defined for each container, rather than for the Pod overall. When you want to configure some additional functionality specific to the container when you have multiple containers per Pod, these can be extremely useful.

The two hooks you can define for each container are post-start and pre-stop. The post-start and pre-stop hooks are intended to be invoked at least once, but Kubernetes does not make any guarantees that these hooks will be invoked only once. This means while it is likely rare, the post-start or pre-stop hooks may be invoked more than once.

Neither of these hooks accept parameters, and are defined in the same fashion as a container’s run command. When used, they are expected to be self-contained, relatively short running commands that always return. When these hooks are...

Initialization containers

Initialization containers are containers that can be defined on your Pod, and will be invoked in the specific sequence that they are defined prior to your main container (or containers) being started. Initialization containers became a normal part of Pod specification in Kubernetes version 1.6.

These containers can use the same container image and simply have alternate commands, but they can also use entirely different images, leveraging the Kubernetes Pod guarantees of shared network and filesystem mounts to do initialization and setup work prior to the main container operating. These containers also use namespaces, so they can be given specific access that the main container doesn't have; consequently, they can be given access to Kubernetes Secrets that the main container cannot access.

Initialization containers are expected to have code that runs to completion and exits with a success response. As mentioned previously, these containers are also invoked in sequence...

Handling a graceful shutdown

With the lifecycle hooks, we mentioned the pre-stop hook that can be defined and enabled, but if you're writing your own code, then you may find it just as easy to respect the SIGTERM signal that Kubernetes uses to tell containers to shut down.

If you aren't familiar with SIGTERM, it is one of the functions that Linux supports from the kernel—a means of sending an interrupt to a running process. The process can listen for these signals, and you can choose how they respond when they are received. There are two signals that you can't ignore and the operating system will enforce, regardless of what you implement: SIGKILL and SIGSTOP. The signal that Kubernetes uses when it wants to shut down a container is SIGTERM.

The kind of events where you will receive this signal aren't just on error or user-invoked deletion, but also when you roll out a code update leveraging the rolling update mechanism that deployment uses. It can also happen if you take advantage of any of...

Summary

In this chapter, we started with looking at the Pod lifecycle and status details in depth, expanding to show multiple ways of revealing relevant details, and describing what Kubernetes does beneath the covers while running your software. We then looked at the feedback loops that your program can provide with liveness and readiness probes, and reviewed examples of enabling those in both Python and Node.js. Following on from the probes and how your code can interact with Kubernetes cleanly, we looked at the common cases for startup and initialization, and graceful shutdown.

In the next chapter, we look at how to use Kubernetes and open source to provide basic observability for your applications, specifically monitoring and logging.