Docker & Kubernetes: Readiness and Liveness Probes

bogotobogo.com site search:

Introduction

Refs:

Kubernetes gives us two types of health checks, and it is important to understand the differences between the two, and their uses.

In short, failing liveness probe will restart the container, while failing readiness probe will stop our application from serving traffic.

Readiness probe: Readiness probes are designed to let Kubernetes know when our app is ready to serve traffic. Kubernetes makes sure the readiness probe passes before allowing a service to send traffic to the pod. If a readiness probe starts to fail, Kubernetes stops sending traffic to the pod until it passes.
1. The kubelet uses readiness probes to know when a container is ready to start accepting traffic.
2. A Pod is considered ready when all of its containers are ready.
3. When a Pod is not ready, it is removed from Service load balancers.

Liveness probe: Liveness probes let Kubernetes know if our app is alive or dead. If our app is alive, then Kubernetes leaves it alone. If our app is dead, Kubernetes removes the Pod and starts a new one to replace it.
1. The kubelet uses liveness probes to know when to restart a container.
2. Many applications running for long periods of time eventually transition to broken states, and cannot recover except by being restarted. Kubernetes provides liveness probes to detect and remedy such situations.
3. The liveness probes could catch a deadlock.

Type of Probes

There are three types of probes: HTTP, Command, and TCP. We can use any of them for liveness and readiness checks.

HTTP: HTTP probes are probably the most common type of custom liveness probe. Even if our app isn't an HTTP server, we can create a lightweight HTTP server inside our app to respond to the liveness probe. Kubernetes pings a path, and if it gets an HTTP response in the 200 or 300 range, it marks the app as healthy. Otherwise it is marked as unhealthy.
Here is a sample: Define a liveness HTTP request

Command: For command probes, Kubernetes runs a command inside our container. If the command returns with exit code 0, then the container is marked as healthy. Otherwise, it is marked unhealthy. This type of probe is useful when we can't or don't want to run an HTTP server, but can run a command that can check whether or not our app is healthy.
Here is a sample: Define a liveness command

TCP: The last type of probe is the TCP probe, where Kubernetes tries to establish a TCP connection on the specified port. If it can establish a connection, the container is considered healthy; if it can't it is considered unhealthy. TCP probes come in handy if we have a scenario where HTTP probes or command probe don't work well. For example, a gRPC or FTP service is a prime candidate for this type of probe.

Note:
Termination grace period of 30 seconds: Kubernetes implements graceful termination by applying a default grace period of 30 seconds from the time that we issue a termination request.

This feature helps our app pod can process a request even after being severed off from a load balancer and keep the down time to 0 during a roll out (deploy/upgrade) period.