Sign inTry Free

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.

Pod Scheduling

Users may declare a schedulingDetails section. This is an optional section that allows scheduling configurations to be set over different groups of pods via the node selector, affinity / anti-affinity, taints, and tolerations attributes. To configure pod scheduling, add the following section to the sdb-cluster.yaml file.

Important

Configure scheduling settings for all roles under the top-level schedulingDetails section. Do not configure these settings directly under aggregatorSpec or leafSpec.

Fields specified under aggregatorSpec.nodeSelector or leafSpec.tolerations are not applied to the resulting pods.

schedulingDetails:
    ROLE:
      nodeName: custom_node_name
      nodeSelector:
        custom: label
      tolerations:
      - key: "custom_key"
        operator: "Exists"
        effect: "NoSchedule"
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            podAffinityTerm:
              labelSelector:
                matchLabels:
                  custom: label
              topologyKey: "kubernetes.io/hostname"
        podAffinity: ...
        nodeAffinity: ...
    STATEFULSET_TYPE:
      ...

STATEFULSET_TYPE is one of master, aggregator, leaf-ag1, or leaf-ag2. Scheduling details that are specified within the StatefulSet type will be passed directly to the pods that are owned by that StatefulSet.

For Operator versions 3.6.0 and later, the Parallel pod management policy is used to reduce the start-up time by child aggregators in parallel. For Operator versions earlier than 3.6.0, the OrderedReady pod management policy is used. Refer to Pod Management Policies for more information.

Refer to the Kubernetes.io documentation for more information about these attributes.

Last modified:

Was this article helpful?

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