Liveness and Readiness Probes
Contents
Readiness Probes
Is my pod instance ready to serve requests, or is it too busy?
- true: request are sent
- false: pod instance is removed from the loadbalancer
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
The container will not accept traffic until the probe returns a healthy state.
Existing probes
- exec
- httpGet
- tcpSocket
Liveness
Is my container inside the pod ok?
- true: request are sent
- false: keep the pod, but restart the failing container (other containers are left unchanged).
Liveness command
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
Liveness HTTP request
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
TCP Liveness Probe
With TCP Liveness Probe, the kubelet attempts to open the TCP Socket to the container which is running the application. If it succeeds, the application is considered healthy, otherwise the kubelet would mark it as unhealthy and restart the affected container.
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
Attachments