Kubernetes Probes: Startup, Liveness, Readiness

by Levent Ogut

Kubernetes has been disruptive due to the scalability, velocity, portability, and observability it adds to cloud deployments. While it brings a whole ecosystem of great features and options and eases complex deployment, it also has its own challenges. One of the great features Kubernetes has brought us is that of high availability. There are many high availability options in Kubernetes; in this article, we will discuss high availability options used for the application/microservice itself.

Pods — the smallest deployable units in Kubernetes — are scheduled once the declarative configuration is applied. Kube-scheduler is responsible for the calculation and schedule; once the schedule is accepted, it is in a controlled and calculated environment, and it is deemed service ready or not by the pod conditions. Using startup, readiness, and liveness probes, we can control when a pod should be deemed started, ready for service, or live. We will explore these conditions and triggers.

Pod and Container Status

Pods have phases and conditions; containers have states. These status properties can and will be changed based on probe results, so let’s explore them.

Pod status object includes a phase field. This phase-field tells Kubernetes and us that wherein the execution cycle a pod is.

• Pending: Accepted by the cluster, containers are not set up yet.
• Running: At least one container is in a running, starting, or restarting state.
• Succeeded: All of the containers exited with a status code of zero; the pod will not be restarted.
• Failed: All containers have terminated and at least one container exited with a status code of non-zero.
• Unknown: The state of the pod can not be determined.

Pod Conditions

As well as pod phases, there are pod conditions. These also give information about the state the pod is in.

• PodScheduled: A Node has been successfully…