This document discusses different types of probes in Kubernetes including liveness, readiness, and startup probes. Liveness probes check if a container is running, readiness probes check if a container is ready to receive traffic, and startup probes delay liveness/readiness checks until startup is complete. It provides examples of defining each type of probe using commands, HTTP GET requests, and TCP checks. It also describes configuring probe parameters like initial delays, timeouts, success/failure thresholds.

1. Kubernetes Learning: Probes
Configure Liveness, Readiness, Startup
Probe

2. Liveness Probes
● Used by Kubelet
● To know when to restart the container
● Catching a Deadlock
● Despite App’s Bugs

3. Readiness Probe
● Used by Kubelet
● To know when a container is ready to start accepting traffic
● When all of its containers are ready
● Control which Pods are used as backends for Services

4. Startup Probes
● To know when a container application has started
● It disables liveness and readiness checks until it succeeds
● Can be used to adopt liveness checks on slow starting containers

5. Defining Liveness Probe (Using
Command)
● Create The Pod
kubectl apply -f https://k8s.io/examples/pods/probe/exec-
liveness.yaml
● Check the Pod, the Pod will be live for a 30 seconds
before it will be killed, and restarted
kubectl get pod liveness-exec
● The periodSeconds field specifies that the kubelet
should perform a liveness probe every 5 seconds
● The initialDelaySeconds field tells the kubelet that it
should wait 5 second before performing the first probe
● To perform a probe, the kubelet executes the
command cat /tmp/healthy in the target container. If
the command succeeds, it returns 0, and the kubelet
considers the container to be alive and healthy. If the
command returns a non-zero value, the kubelet kills
the container and restarts it.
● Describe the Pod, to Check it lifecycle
kubectl describe pod liveness-exec

6. Defining Liveness Probe (Using
httpGet)
● Example http Endpoint
http.HandleFunc("/healthz", func(w http.ResponseWriter, r
*http.Request) {
duration := time.Now().Sub(started)
if duration.Seconds() > 10 {
w.WriteHeader(500)
w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
} else {
w.WriteHeader(200)
w.Write([]byte("ok"))
}
})

7. Defining Liveness Probe (Using TCP)

8. Using Named Container’s Port

9. Protect slow starting containers with startup probes
● Used commonly with legacy app.
● That might require an additional startup time on
their first initialization.
● The trick is to set up a startup probe with the
same command, HTTP or TCP check
● Once the startup probe has succeeded once, the
liveness probe takes over to provide a fast
response to container deadlocks.

10. Define readiness probes
● an application might need to load large data or
configuration files during startup, or depend on
external services after startup
● Readiness probes are configured similarly to
liveness probes.
● Configuration for HTTP and TCP readiness
probes also remains identical to liveness probes.
● Readiness and liveness probes can be used in
parallel for the same container.
● Using both can ensure that traffic does not reach
a container that is not ready for it, and that
containers are restarted when they fail.

11. Configure Probes (1)
Probes have a number of fields that you can use to more precisely control the behavior of liveness and
readiness checks:
● initialDelaySeconds: Number of seconds after the container has started before liveness or readiness
probes are initiated. Defaults to 0 seconds. Minimum value is 0.
● periodSeconds: How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is
1.
● timeoutSeconds: Number of seconds after which the probe times out. Defaults to 1 second. Minimum
value is 1.
● successThreshold: Minimum consecutive successes for the probe to be considered successful after
having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1.
● failureThreshold: When a Pod starts and the probe fails, Kubernetes will try failureThreshold times
before giving up. Giving up in case of liveness probe means restarting the container. In case of
readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1.

12. Configure Probes (2)
HTTP probes have additional fields that can be set on httpGet:
● host: Host name to connect to, defaults to the pod IP. You probably want to set “Host” in httpHeaders
instead.
● scheme: Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
● path: Path to access on the HTTP server.
● httpHeaders: Custom headers to set in the request. HTTP allows repeated headers.
● port: Name or number of the port to access on the container. Number must be in the range 1 to 65535.

13. Thank You
© 2020 , By Akhmad Zaki Al-Safi
Summaried from: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/