This generates a MemsqlCluster object (from the custom resource definition) that spawns the cluster and all associated necessary objects/resources based on the configurations supplied within.

Create a MemsqlCluster definition file to specify the configuration settings for your cluster.

apiVersion: memsql.com/v1alpha1
kind: MemsqlCluster
metadata:
  name: sdb-cluster
spec:
  license: license_key
  adminHashedPassword: "hashed_password"
  nodeImage:
    repository: singlestore/node
    tag: node_tag

  redundancyLevel: 2

  serviceSpec:
    objectMetaOverrides:
      labels:
        custom: label
      annotations:
        custom: annotations

  aggregatorSpec:
    count: 2
    height: 0.5
    storageGB: 256
    storageClass: standard

    objectMetaOverrides:
      annotations:
        optional: annotation
      labels:
        optional: label

  leafSpec:
    count: 2
    height: 0.5
    storageGB: 1024
    storageClass: standard

    objectMetaOverrides:
      annotations:
        optional: annotation
      labels:
        optional: label

You must edit the following placeholders in this file to properly set up your cluster:

• Replace license_key with your license from the Cloud Portal.

  Note that, as of SingleStore 7.1.4, license checks are now cgroup-aware and respect container resource boundaries for containerized deployments. While this does not change how license checks are performed, nor does it change how capacity is allocated, it does change how the resources allocated to the container are checked.

• Replace hashed_password with a hashed version of a secure password for the admin database user on the cluster.

  The admin user is the default user you can use when logging into your cluster. The account is created by the Operator during cluster deployment and has an explicit set of grants (defined at the end of this step) to reduce the scope of this user.

  The following python script shows how to create a hashed password. Note that the asterisk (*) must be included in the final password.

  Python

  Copy

  from hashlib import sha1
  print("*" + sha1(sha1('secretpass'.encode('utf-8')).digest()).hexdigest().upper())

• Under nodeImage, tag specifies the version of singlestore/node that will be deployed in your cluster. This value aligns with the version number of the SingleStore database engine that is running in the container.

  For example, alma-8.0.16-501f90902b contains version 8.0 of SingleStore.

  You can use different versions of the engine by going to the Docker Hub page for singlestore/node and selecting a different tag, with the exception of the latest tag. Because of recent updates to the singlestore/node container, you should select a tag that is 6.8.9-24b9cbd386 or later. Also, running different versions of the SingleStore engine in one cluster is not supported, so you must ensure that each node in your Kubernetes cluster has the same tag value.

• By default, the redundancyLevel is set to 2 to enable high availability (HA), which is highly recommended for production deployments. To disable high availability, set this value to 1. Refer to Managing High Availability for more information.

• The objectMetaOverrides sections are optional. By including these sections, you can override the metadata annotations and labels at either the node or service layer (objectMetaOverrides).

• Change count to alter the number of aggregator or leaf nodes in your cluster.

• The height value specifies the vCPU and RAM size of an aggregator or leaf node where a height of 1 equals 8 vCPU cores and 32 GB of RAM. The smallest value you can set is 0.5 (4 vCPU cores, 16 GB of RAM).

• The storageGB value corresponds to the amount of storage each aggregator or leaf should request for their persistent data volume.

• The storageClass value specifies which storage class to use for the PersistedVolume in the Kubernetes cluster. You must change this value to align with the default (or custom) storage class available to your cluster and ensure that the storage class is provisioned before creating the SingleStore cluster via kubectl create.

• Users may declare an envVariables section. This is an optional section that allows environment variables to be specified. The currently supported environment variables include:

  • MALLOC_ARENA_MAX

  YAML

  Copy

  envVariables:
    MALLOC_ARENA_MAX: 4

Once you have finished creating your definition files, you can deploy your cluster.

usersSpec:
rootServiceUser: true

// RequireSSL is a flag that toggles `REQUIRE SSL`
// for the `admin` user
// For accounts that have REQUIRE SSL, the connection
// attempt fails if a secure connection cannot be established.

adminRequireSsl: true  # true to enable, false to disable