Important
The SingleStore 9.1 release candidate (RC) gives you the opportunity to preview, evaluate, and provide feedback on new and upcoming features prior to their general availability. In the interim, SingleStore 9.0 is recommended for production workloads, which can later be upgraded to SingleStore 9.1.
Configure Container Probes
On this page
These instructions demonstrate how to configure liveness, readiness and startup probes for containers.
The time-related parameters of the Liveness, Readiness, and Startup probes can be configured through aggregatorSpec. and leafSpec..
Note: Liveness probes are disabled by default as of Operator 3.
aggregatorSpec:readinessProbeSpec:initialDelaySeconds: 10timeoutSeconds: 1periodSeconds: 10successThreshold: 1failureThreshold: 3livenessProbeSpec:initialDelaySeconds: 10timeoutSeconds: 1periodSeconds: 10successThreshold: 1failureThreshold: 3startupProbeSpec:initialDelaySeconds: 10timeoutSeconds: 1periodSeconds: 10successThreshold: 1failureThreshold: 30leafSpec:readinessProbeSpec:initialDelaySeconds: 10timeoutSeconds: 1periodSeconds: 10successThreshold: 1failureThreshold: 3livenessProbeSpec:initialDelaySeconds: 10timeoutSeconds: 1periodSeconds: 10successThreshold: 1failureThreshold: 3startupProbeSpec:initialDelaySeconds: 10timeoutSeconds: 1periodSeconds: 10successThreshold: 1failureThreshold: 30
Refer to the Kubernetes documentation for more information about these attributes.
Configure Liveness Probe
The Operator can be configured to create liveness probes on the pods in the cluster.
spec:enableLivenessProbeOnNodes: true
When to Override Startup Probe Defaults
Startup probes are particularly useful in the following scenarios:
-
SingleStore nodes require long initialization times (for example, large caches or recovery operations)
-
You want to prevent premature restarts during cluster startup or recovery
-
Child aggregators require additional time to become ready before receiving traffic
Last modified: