Introduction to Kubernetes Probes

Probes Introduction

• Liveness probes: Liveness probes are used to determine whether a container is healthy. If the health condition is not met, kubelet will decide whether to restart the Pod based on the restartPolicy configured on the Pod.

  A LivenessProbe performs checks according to its configuration (inspecting a process, a port, or whether a command executes successfully, etc.) to determine whether the container is functioning normally. If the probe fails (you can configure how many consecutive failures are required to mark the container as unhealthy), kubelet will kill the container and handle it according to the container’s restart policy. If no liveness probe is configured, the container is considered to have passed (Success) by default after startup — i.e., the probe always returns Success. Once Success is returned, the Pod status is RUNNING.

• Readiness probes: Readiness probes are used to determine whether the program inside the container is alive (or healthy). Only when the program (service) is functioning normally will the container start accepting external network traffic (startup complete and ready).

  After the container starts, probing is performed according to the ReadinessProbe configuration. When no issues are detected, the result is Success. The Pod’s READY status becomes true, changing from 0/1 to 1/1. If probing fails, it remains 0/1 with status false. If no readiness probe is configured, the container is considered Success by default after startup. The relationships among this Pod, the Service resource associated with this Pod, and the EndPoint will also be set based on the Pod’s Ready status. If the Pod’s Ready state changes to false during operation, the system will automatically remove the Pod from the EndPoint list associated with the Service. At that point, when the Service resource receives a GET request, kube-proxy will definitely not route traffic into this Pod — this mechanism prevents traffic from being forwarded to unavailable Pods. If the Pod returns to the Ready state, it will be added back to the Endpoint list, and kube-proxy will probabilistically route traffic to this Pod through its load-balancing mechanism.

• Startup Probes: For legacy applications that need a longer startup time, when you neither want to restart the application nor want requests to be routed in, you can configure a startup probe to grant sufficient startup time to ensure the application starts successfully.

Execution Order

You can customize whether these checks are executed when a Pod starts. If not configured, all checks default to passing.

If configured, the order is: startupProbe --> readinessProbe --> livenessProbe

But is this really the order? The official documentation says otherwise, stating:

Caution: Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.

So the actual order is: startupProbe --> readinessProbe(livenessProbe)

readinessProbe and livenessProbe run asynchronously and concurrently.

LivenessProbe & ReadinessProbe Usage

Probe Methods

Both LivenessProbe and ReadinessProbe support the following three probing methods:

• ExecAction: Execute a specified command inside the container. If the command succeeds with exit code 0, the probe succeeds.
• HTTPGetAction: Invoke the HTTP GET method via the container’s IP address, port number, and path. If the response status code is greater than or equal to 200 and less than 400, the container is considered healthy.
• TCPSocketAction: Perform a TCP check via the container’s IP address and port number. If a TCP connection can be established, the container is considered healthy.

Probe Parameters

Related attributes of the LivenessProbe and ReadinessProbe probes.
A Probe has many optional fields that can be used to more precisely control the behavior of Liveness and Readiness probes:

• initialDelaySeconds: Number of seconds to wait after the container starts before the probe begins working. Unit: “seconds”. Default is 0, minimum is 0.

• periodSeconds: The interval at which probing is performed (in seconds). Default is 10s, unit “seconds”, minimum is 1.

• timeoutSeconds: The timeout for waiting for a response after the probe issues a check request. Default is 1s, unit “seconds”, minimum is 1.

• successThreshold: The minimum number of consecutive successes required for the probe to be considered successful after having failed. Default is 1, in Liveness probes it must be 1, minimum is 1.

• failureThreshold: The number of retries before a probe is considered failed. After a certain number of retries, it is considered failed. In readiness probes, the Pod will be marked as not ready. Default is 3, minimum is 1.

  Tips: initialDelaySeconds does not actually need to be configured in ReadinessProbe. Without configuration, by default ReadinessProbe begins probing immediately after the Pod starts. Once the service has started and the check passes, the READY status naturally becomes normal.

Example

apiVersion: v1
kind: Pod
metadata:
    name: liveness-http
    labels:
        test: liveness
spec:
    containers:
        - name: liveness
          image: test.com/test-http-prober:v0.0.1
          LivenessProbe:
              failureThreshold: 5 #5 failed checks mark it as not ready
              initialDelaySeconds: 20 #delayed load time
              periodSeconds: 10 #retry interval
              timeoutSeconds: 5 #timeout setting
              successThreshold: 2 #2 successful checks mark it as ready
              httpGet:
                  port: 8082
                  path: /status/health

Refer

• https://juejin.cn/post/7163135179177852936
• https://juejin.cn/post/7163135453489528845