livenessProbe
Description
If the DataPowerService version
meets the below criteria, the livenessProbe
property will be overwritten by the operator to enforce that the probe endpoint is the datapower-health-check
service.
Criteria for spec overwrite
- DataPowerService
version
is in10.6-lts
release stream - DataPowerService
version
is in10.5-cd
release stream - DataPowerService
version
is in10.5-lts
release stream and10.5.0.3
or higher - DataPowerService
version
is in10.0-lts
release stream and10.0.1.11
or higher
Operator managed spec
The following spec will be applied by the operator if the above criteria is met:
livenessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 7879
scheme: HTTP
initialDelaySeconds: 5
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 5
Customization
If you wish to customize the livenessProbe
and your deployment meets the above criteria, you must add an annotation to the DataPowerService resource for the operator to allow the change:
apiVersion: datapower.ibm.com/v1beta3
kind: DataPowerService
metadata:
name: example
annotations:
datapower.ibm.com/liveness-override: "true"
spec:
livenessProbe:
# custom spec
...
Legacy spec
NOTE: this only applies to deployments which do not meet the criteria listed above.
The livenessProbe
property allows you to set a custom Liveness Probe for the DataPower container(s) in the StatefulSet. The value of this property must be a well formed Kubernetes Probe
type. If not specified, the
following default will be used:
livenessProbe:
failureThreshold: 3
httpGet:
path: /
port: 7879
scheme: HTTP
initialDelaySeconds: 5
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 5
This default livenessProbe
leverages the built-in DataPower health-check sidecar process.
Example
In addition to the above example, it's worth reviewing Kubernetes documentation on Configure Liveness, Readiness and Startup Probes for additional details on what configuration capabilities are available for this field.