Sign inTry Free

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.readinessProbeSpec/livenessProbeSpec/startupProbeSpec and leafSpec.readinessProbeSpec/livenessProbeSpec/startupProbeSpec.

Note: Liveness probes are disabled by default as of Operator 3.0.96 and later. You can enable them if needed using the following configuration.

aggregatorSpec:
  readinessProbeSpec:
    initialDelaySeconds: 10
    timeoutSeconds: 1
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 3
  livenessProbeSpec:
    initialDelaySeconds: 10
    timeoutSeconds: 1
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 3
  startupProbeSpec:
    initialDelaySeconds: 10
    timeoutSeconds: 1
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 30
leafSpec:
  readinessProbeSpec:
    initialDelaySeconds: 10
    timeoutSeconds: 1
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 3
  livenessProbeSpec:
    initialDelaySeconds: 10
    timeoutSeconds: 1
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 3
  startupProbeSpec:
    initialDelaySeconds: 10
    timeoutSeconds: 1
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 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. This feature attempts to restart a container if it fails a probe. This feature is off by default as thread, CPU, or PID exhaustion from database workloads can lead to restarts.

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:

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In