Juju mirrors the syntax used in Kubernetes manifests. Refer to the Kubernetes reference documentation for all options.
Add a livenessProbe, startupProbe and/or readinessProbe key within the relevant container item of the containers list at the base of your pod spec.
containers:
- livenessProbe:
# exec: { ... }
# httpGet: { ... }
# tcpSocket: { ... }
readinessProbe:
# exec: { ... }
# httpGet: { ... }
# tcpSocket: { ... }
startupProbe:
# exec: { ... }
# httpGet: { ... }
# tcpSocket: { ... }
Many long-running applications encounter an occasional crash. Restarting them is the simplest way to recover from these sorts of errors. Liveness probes provide this functionality. When a liveness probe fails, the Pod is re-scheduled.
Command-based probes
When your application provides a command that can check its status, a command-based liveness probe can be helpful.
Assuming that your container writes an example.pid file when it starts up, you can check that the process ID is still alive with the following syntax:
livenessProbe: # or readinessProbe:, or startupProbe:
exec:
command:
- /bin/ps --pid $(/bin/cat /var/run/example.pid)
Note: this requires that the container possesses the ps and cat executables
HTTP-based probes
An httpGet liveness probe will periodically send HTTP GET requests to the specified path and port over the lifetime of the application. If Kubernetes receives an HTTP error, the Pod will be considered down and will then be re-provisioned.
This example instructs Kubernetes to periodically poll the web application root.
livenessProbe: # or readinessProbe: or startupProbe:
httpGet:
path: /
port: 80
# httpHeaders is optional, but can be useful
# for filtering traffic within the application.
httpHeaders:
- name: X-Probe
value: Liveness
HTTP-based probes accept named ports. Named ports are defined within the container’s ports: section.
TCP-based probes
A tcpSocket probe determines success by the ability to open a TCP connection at the specified port.
livenessProbe: # or readinessProbe:, or startupProbe:
tcpSocket:
port: 10000
TCP-based probes accept named ports. Named ports are defined within the container’s ports: section.
Providing extra parameters to probes
The behaviour of probes can be adjusted by adding key/value pairs:
| Key | Data type | Description |
|---|---|---|
periodSeconds |
A positive integer | Number of seconds to pass between each probe. |
initialDelaySeconds |
A positive integer | Number of seconds that Kubernetes should wait before beginning to send probes. To avoid race conditions, consider adding a startupProbe. |
failureThreshold |
A positive integer | Number of successive probes that must fail before the Pod is rescheduled. |
successThreshold |
A positive integer | Number of successive probes that must succeed before the Pod is considered to be responsive. |
Further Reading
Refer to the Kubernetes guide for more information about probes and their functionality
See the Kubernetes probe reference documentation for authoritative information about which parameters are available.