Pod Container Probes

Posted on 2020-02-01 In Kubernetes Views: Word count in article: 575 Reading time ≈ 2 mins.

DevOps, Cloud, Kubernetes — personal tech notes by ChengQing Su

Periodic diagnostics performed by kubelet on containers. To perform a diagnostic, kubelet calls a Handler implemented by the container.

Handler Types

ExecAction: Executes a specified command inside the container. The diagnostic is considered successful if the command exits with status code 0.
TCPSocketAction: Performs a TCP check against the container’s IP address on a specified port. The diagnostic is considered successful if the port is open.
HTTPGetAction: Performs an HTTP GET request against the container’s IP address on a specified port and path. The diagnostic is considered successful if the response status code is greater than or equal to 200 and less than 400.

Handler Execution Results

The execution result of a Handler is the result of the probe. There are three possible outcomes:

Success: The container passed the diagnostic.
Failure: The container failed the diagnostic.
Unknown: The diagnostic failed, so no action should be taken.

Probe Types

There are 3 types of probes in total:

livenessProbe: Indicates whether the container is running.
readinessProbe: Indicates whether the container is ready to serve requests.
startupProbe: Indicates whether the application inside the container has started.

livenessProbe

Indicates whether the container is running. If the probe result is Failure, kubectl will kill the container, and the container will be restarted based on the configured restart policy. If no probe is configured for the container, the default is Success.

If the container is able to crash on its own when it encounters a problem or becomes unhealthy, this probe is not needed.
If you want the container to be killed and restarted upon probe failure, configure this probe and set restartPolicy to Always or OnFailure.

readinessProbe

Indicates whether the container is ready to serve requests. If the probe result is Failure, the endpoint controller will remove the Pod’s IP address from the endpoints of all Services that match the Pod. Before the initial delay, the default state is Failure. If no probe is configured for the container, the default is Success.

This probe is recommended in the following situations:

The Pod should only start receiving traffic after this probe succeeds.
The container needs to load large datasets, configuration files, or perform migrations during startup.
You want the container to be able to take itself offline for maintenance.

If you only want to drain requests when deleting a Pod, this probe is not strictly necessary; during deletion, the Pod will automatically put itself into a not-ready state regardless of whether this probe is configured. The Pod will remain in the not-ready state while waiting for the container to stop.

startupProbe

This probe was added in Kubernetes 1.16 and is currently still in the alpha stage.

Indicates whether the application inside the container has started. If this probe is configured, all other probes are disabled until this probe succeeds. If the probe result is Failure, kubectl will kill the container, and the container will be restarted based on the configured restart policy. If no probe is configured for the container, the default is Success.

If the container’s startup time exceeds initialDelaySeconds + failureThreshold × periodSeconds, this probe should be configured. The endpoint checked by this probe is the same as that of the livenessProbe.