A probe is a diagnostic performed periodically by the kubelet on a container. To perform a diagnostic, the kubelet either executes code within the container or makes a network request.
There are three types of probes in Kubernetes
-
Liveness Probe indicates whether the container is running.
-
Readiness Probe indicates whether the container is ready to respond to requests.
-
Startup Probe indicates whether the container is started.
Liveness Probe Link to heading
The kubelet uses a liveness probe to know when to restart the container. Many applications running for long periods of time eventually transition to broken states, and cannot recover except by being restarted.
For example, if you are running a web application and the web server is running but not able to serve any request. Restarting a container in such a scenario can help to make the application more available despite bugs.
The liveness probe can be specified using the livenessProbe field on the container spec.
-
If your pod has multiple containers then each container needs to have its own liveness probe.
-
If the liveness probe fails, the kubelet kills the container, and the container is subjected to its restart policy.
-
If a container does not provide a liveness probe, the default state is a
success.
...
containers:
...
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
failureThreshold: 3
The initialDelaySeconds field tells the kubelet that it should wait 3 seconds before performing the first probe.
The periodSeconds the field specifies that the kubelet should perform a liveness probe every 3 seconds.
There are some other fields as well which can be specified in the probes spec
failureThreshold : When a probe fails, Kubernetes will try failureThreshold times before giving up. Giving up in case of a liveness probe means restarting the container. In case of readiness probe, the Pod will be marked Unready. Defaults to 3. The 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 and startup Probes. The minimum value is 1.
timeoutSeconds : Number of seconds after which the probe times out. Defaults to 1 second. The minimum value is 1.
Readiness Probe Link to heading
The Kubelet uses a readiness probe to know when a container is ready to start accepting traffic. A pod is considered ready when all its containers are ready. It is used to control which pods can be used as backends for the Service.
For example, An application might need to load some data or configuration at or connect to some external services at startup. We don’t want to kill such applications or either start sending requests until that application’s Pod is not successfully loaded data or configurations at startup. Kubernetes provides readiness probes to detect and mitigate these situations.
If the readiness probe fails, the endpoints controller removes the Pod’s IP address from the endpoints of all Services that match the Pod. The default state of readiness before the initial delay is Failure. If a container does not provide a readiness probe, the default state is Success.
The readiness probe can be specified as similar to the liveness probe with the readinessProbe field. The spec is the same as the readiness probe spec.
...
containers:
...
readinessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
failureThreshold: 3
periodSeconds: 3
Startup Probe Link to heading
The kubelet uses this probe to know when a container application has started. If the startupProbe is enabled, it disables liveness and readiness probe until it succeeds. This is done to make sure that liveness and readiness probes do not interface with the application startup. This can be used to replace the liveness probe on a slow starting container which can be killed by kubelet before they are up and running.
The startup probe can be specified as similar to the liveness probe with the startupProbe field. The spec is the same as the readiness probe spec.
...
containers:
...
startupProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
failureThreshold: 3
periodSeconds: 3
There are different kinds of mechanisms that are used to check the container probes. All types of probes use one of these check mechanisms.
-
Exec Link to heading
This kind of check executes a specified command inside the container. The probe is considered successful if the command exits with a status code of 0.
For example,
apiVersion: v1
kind: Pod
...
spec:
containers:
- name: liveness
...
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
-
HTTP GET Request Link to heading
This check performs an HTTP GET request against the Pod’s IP address on a specified port and path. The check is considered successful if the response has a status code greater than or equal to 200 and less than 400. Any other code indicates failure.
For example,
...
containers:
...
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
failureThreshold: 3
periodSeconds: 3
-
TCP Socket Link to heading
This check performs a TCP connection request against the Pod’s IP address on a specified port. The check is considered successful if the port is open. If the remote system (the container) closes the connection immediately after it opens, this counts as healthy.
For example,
apiVersion: v1
kind: Pod
...
spec:
containers:
- name: goproxy
...
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
-
GRPC Link to heading
gRPC probes are an alpha feature and are only available if you enable the GRPCContainerProbe feature gate.
This check performs a remote procedure call using gRPC. The target should implement gRPC health checks. This check is considered successful if the status of the response is SERVING.
For example.
apiVersion: v1
kind: Pod
metadata:
...
spec:
containers:
- name: etcd
...
ports:
- containerPort: 2379
livenessProbe:
grpc:
port: 2379
initialDelaySeconds: 10