A liveness probe makes sure that your pod is in good health,
but for some applications it isn’t enough. Some applications
need to load large files before starting. You might think if you set
initialDelaySeconds value then
the problem is solved but this is not an efficient solution. The readiness
probe is a solution especially for Kubernetes services, as the pod
will not receive the traffic until it is ready. Whenever the readiness
probe fails, the endpoint for the pod is removed from the service
and it will be added back when the readiness probe succeeds. The readiness
probe is configured in the same way as the liveness probe:
apiVersion: v1 kind: Pod metadata: name: liveness-readiness labels: app: tcpsocket-test spec: containers: - name: liveness-readiness-pod image: virtualhops/ato-ubuntu:latest ports: - containerPort: 80 securityContext: privileged: true capabilities: add: - NET_ADMIN livenessProbe: httpGet: path: / port: 80 httpHeaders: - name: some-header value: Running initialDelaySeconds: 15 periodSeconds: 20 readinessProbe: tcpSocket: port: 80 initialDelaySeconds: 5 periodSeconds: 10
It’s recommended to use both the readiness probe and the liveness probe whereby the liveness probe restarts the pod if it failed and the readiness probe makes sure the pod is ready before it gets traffic.
Probes have a number of parameters 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.
periodSeconds: How often (in seconds) to perform the probe. Default is 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 a liveness probe means restarting the pod. In case of a readiness probe the pod will be marked Unready. Defaults to 3. Minimum value is 1.
And HTTP probes have additional parameters that can be set on
host: The host name to connect to, which defaults to the pod IP. You probably want to set “Host” in
scheme: The 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.