Use Mission Control to provision and deploy a DSE cluster

Mission Control is the next generation operations platform available with DataStax Enterprise (DSE) version 6.8.26 or later. It simplifies management of DSE operations across an array of hosting options from the cloud to hybrid to on-premises. Install and run Mission Control in DSE environments on bare-metal, virtual machines (VMs), or on your existing Kubernetes cluster. Powered by the advanced automation that runs Astra DB, Mission Control provides 24/7 automated operations of DSE nodes, datacenters, and clusters.

You can deploy DSE 6.8 in a production-ready environment across multiple servers and immediately start testing. To run a single-node development and testing instance consider following the container-based instructions.

With Mission Control, you can provision a database cluster directly in the Mission Control UI or through the kubectl command line tool.

Mission Control reconciles MissionControlCluster resources defined either through the UI or CLI against any currently deployed database instances. These definitions describe the desired state of your database clusters. Your definitions are used to automate the process of provisioning and configuring resources across your control and data planes.

Prerequisites

Use the DataStax Enterprise (DSE) UI

You need the following:

Use the CLI

You need the following:

  • Working knowledge of Kubernetes.

  • Access to a Kubernetes cluster.

  • kubectl installed and configured.

Provision and deploy a DSE cluster

You can provision a database cluster using the Mission Control UI (guided or advanced mode) or the CLI:

  • UI guided mode: DataStax recommends guided mode for new users. In this mode, Mission Control guides you through the minimum required configuration.

  • UI advanced mode: DataStax recommends advanced mode if you are familiar with the Kubernetes API and YAML configuration. In this mode, you define your YAML configuration file, and you have more granular control over your cluster configuration.

  • CLI: DataStax recommends the CLI if you are familiar with the kubectl command line tool.

For best practices, see Best practices for database clusters.

Use guided mode in the Mission Control UI

To provision a database cluster using guided mode, do the following:

  1. In the Mission Control UI, select a project, and then click Create cluster.

  2. Under General information, configure the cluster details:

    1. In Display name, enter a meaningful, human-readable cluster name.

      The Display name can be any string of characters, including international, alphanumeric, punctuation—dashes, spaces, underscores, and upper or lower case.

      Cluster names are permanent. You cannot change them after you create the cluster. The name uniquely identifies the cluster across all projects and all environments to prevent a logical cluster from inadvertently joining another.

    2. Select the database Type:

      • DataStax Enterprise (DSE)

      • Hyper-Converged Database (HCD)

      • Apache Cassandra

    3. In Version, enter a version or select one from the list. For example, 6.9.20.

    4. Optional: In Image, enter an optional override for the server container image. For example, datastax/dse-mgmtapi-6_8:6.8.39. Otherwise, leave this field blank.

  3. Under Capacity tier template, select a template as a starting point, or select Custom to define all settings:

    • Developer: 3 nodes (8 vCPU cores, 16 GiB RAM, 1024 GiB storage per node)

    • Small: 6 nodes (16 vCPU cores, 32 GiB RAM, 2048 GiB storage per node)

    • Medium: 3 nodes (16 vCPU cores, 64 GiB RAM, 3072 GiB storage per node)

    • Large: 18 nodes (32 vCPU cores, 128 GiB RAM, 8192 GiB storage per node)

    • Custom: Datacenter and rack names default. Define all other settings manually.

  4. Under Template configuration, review the datacenter settings and adjust them as needed:

    Click Edit on the Template configuration panel to edit the configuration. Adjusting these settings overrides the template defaults if you selected a template, or creates a custom configuration if you selected Custom.

    1. In the Customize configuration dialog, under Datacenter 1, click Edit.

    2. Enter a meaningful, human-readable datacenter name. Default: dc1.

      Datacenter names are permanent. You cannot change them after you create the cluster. The datacenter name:

      • Must start with an alphanumeric character.

      • Must be a single word.

      • Can be any capitalization: upper, lower, or mixed-case.

      • Can include dashes and underscores.

      • Must not include spaces.

    3. Select the Location (data plane context) where you want to deploy the cluster.

      By default, Mission Control deploys a database cluster to the control plane. If you deploy a data plane on another Kubernetes cluster, you can deploy the database cluster to that context. For more information, see Mission Control deployment topologies.

    4. In Nodes per rack, specify the number of database nodes to allocate per rack.

      DataStax recommends a minimum of three nodes for production clusters to support replication in a datacenter for high availability. With three replicas in a datacenter, this configuration can tolerate a failure of one node when using a strong consistency of LOCAL_QUORUM.

    5. In Use host network, keep the default Automatic setting, or choose another setting.

    6. Optional: In Stop this DC, specify the state of the datacenter after creation. Default: Running. Set to Stopped if required.

    7. Optional: Under Advanced workloads, enable Search or Graph if required. HCD doesn’t support advanced workloads.

    8. Under Rack 1, configure the first rack:

      1. Enter a Rack Name for the first rack. Default: rack1.

        Rack names are permanent. You cannot change them after you create the cluster. The rack name:

        • Must start with an alphanumeric character.

        • Must be a single word.

        • Can be any capitalization: upper, lower, or mixed-case.

        • Can have dashes and underscores.

        • Must not include spaces.

      2. Kubernetes schedules database pods, or nodes, using node affinity.

        Add the mission-control.datastax.com/role=database label to the rack configuration to ensure Kubernetes schedules database pods on database worker nodes only, not on platform worker nodes:

        • Label: mission-control.datastax.com/role

        • Value: database

      3. To add another rack, select Add rack and configure it as you did in the previous steps. Make sure that you add the node affinity label.

    9. Optional: Under Racks tolerations rules, select Add toleration to configure toleration rules for your racks.

      1. Enter a Toleration key.

      2. Select an Operator, Equal or Exists.

      3. Enter a Value.

      4. Select an Effect, NoSchedule, PreferNoSchedule, or NoExecute.

    10. Optional: Add the configuration property and its corresponding value in the Add cassandra.yaml setting sub-section if you require a non-standard Cassandra configuration. Mission Control merges datacenter-level overrides into cassandra.yaml.

    11. Optional: Add the configuration property and its corresponding value in the Add dse.yaml setting sub-section if you require a non-standard DSE configuration. Mission Control merges datacenter-level overrides into dse.yaml.

    12. Under Resources per node, enter the minimum available resources required for scheduling a database node on a server:

      • Datacenter total nodes

      • vCPU (cores)

      • Memory RAM (GiB)

      • Storage (GiB)

        DataStax recommends that you allocate the following minimum amounts of memory and storage:

        • 4 GB of RAM for development environments and 8 GB for nodes with Vector Search enabled.

        • 32 GB of RAM to production nodes and 64 GB for nodes with Vector Search enabled.

        • 500 GB of storage for production nodes.

        For more information, see Capacity planning and hardware selection for DSE deployments.

    13. Optional: To create a multi-datacenter cluster, select Add datacenter and configure it as above.

  5. Click Save changes.

  6. In the Create cluster dialog, under Additional settings, configure the storage class and heap settings:

    • Storage class: Select the storage class configured for your environment (for example, dynamic-rwo). This maps storage requests to a backing provider (SSD, spinning disk, local volumes, etc.). DataStax recommends a class backed by NVMe SSDs.

    • Heap (GiB): Specify the JVM heap allocation. DataStax recommends 25% of total RAM, with a maximum of 50%:

      System memory Recommended heap

      8 GB

      4 GB

      32 GB

      8-24 GB

      64 GB

      31 GB

  7. Under Backup configuration, select an existing Medusa configuration to enable backup and restore for the cluster, or create a new one:

    • Select an existing configuration from the Medusa configuration dropdown.

    • Select New config to define a new Medusa configuration.

    • Select None — skip backup configuration if you do not want to configure automated backups at this time.

  8. Under Security, configure superuser credentials and encryption options:

    • Superuser name: Mission Control derives the username from the cluster name (for example, <cluster-name>-superuser) and manages it. The superuser role is required to connect to the database cluster and perform operations.

    • Superuser password: Enter a custom password or leave the field empty to keep the automatically generated secure password.

    • Enable internode encryption: This toggle is enabled by default. DataStax recommends keeping internode encryption enabled to secure communication between database nodes, especially for production environments.

  9. Click Create cluster.

  10. Optional: Track the progress of the database pods:

    kubectl get pods -n mission-control

    DataStax Enterprise (DSE) assigns database pod names prefixed by the cluster name. Each node completes a standard bootstrap sequence in approximately 2-3 minutes. Once operational and ready to accept client requests, each pod displays 2/2 containers as READY with a STATUS of Running.

  11. Optional: Inspect pods that are not ready:

    kubectl describe pod -n mission-control POD_NAME

    Replace POD_NAME with the name of your pod.

Use advanced mode in the Mission Control UI

DataStax recommends advanced mode only if you are familiar with the Kubernetes API and YAML configuration.

For custom resource definition (CRD) details, see the Mission Control Custom Resource Definition (CRD) reference.

To provision a database cluster in Mission Control using advanced mode, do the following:

  1. In the Mission Control UI, select a project, and then click Create cluster.

  2. Click Advanced. The Create cluster page displays YAML configuration options.

  3. Edit the YAML configuration to define the cluster.

    As you make changes, autocomplete suggestions appear for some fields:

    • When you add a new array item (-), autocomplete provides intelligent suggestions based on the schema.

    • For arrays of objects, autocomplete suggests valid property names based on the object’s schema.

    • For arrays of enum strings, autocomplete suggests predefined values from the enum list.

  4. Click Create cluster.

    When you use advanced mode to copy your YAML definition and create a new cluster on another installation, you must omit the metadata.resourceVersion property. If you include this property, you cannot make updates to the new cluster with kubectl.

Use the CLI

Assuming that your data plane clusters have either the appropriate compute capacity or the capability to auto-scale, you can define a simple MissionControlCluster YAML file and invoke kubectl to create a running cluster.

Create a cluster by completing the following define and submit tasks. Review the automatic reconciliation workflow, and then monitor the reconciliation status with one kubectl command.

To define a new MissionControlCluster, start with creating a new YAML file that defines the topology and configuration for the new cluster. This file is an instance of a MissionControlCluster Kubernetes custom resource (CR), and it describes the target end-state for the cluster.

The following is a minimal example of a MissionControlCluster instance that creates a three-node database cluster. Each node has five GB of storage available for data and requests 32 GB of RAM.

For more information, see the Capacity planning and hardware selection for DSE deployments.

  1. On a local machine, create a manifest file named database-cluster.yaml to describe the cluster topology.

  2. Copy the following configuration into the file:

    apiVersion: missioncontrol.datastax.com/v1beta2
kind: MissionControlCluster
metadata:
  name: CLUSTER_NAME
  namespace: PROJECT_SLUG
spec:
  encryption:
    internodeEncryption:
      enabled: true
  k8ssandra:
    auth: true
    cassandra:
      serverVersion: SERVER_VERSION
      serverType: SERVER_TYPE
      storageConfig:
        cassandraDataVolumeClaimSpec:
          storageClassName: default
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 1024Gi
      config:
        cassandraYaml:
          dynamic_snitch: false
          server_encryption_options:
            internode_encryption: all
        jvmOptions:
          additionalJvmServerOptions:
          heapSize: 31Gi
      resources:
        limits:
          cpu: "32"
          memory: 128Gi
        requests:
          cpu: "28"
          memory: 128Gi
      datacenters:
        - metadata:
            name: dc1
          datacenterName: dc1
          stopped: false
          size: 3
          racks:
            - name: rack1
              nodeAffinityLabels:
                mission-control.datastax.com/role: database
            - name: rack2
              nodeAffinityLabels:
                mission-control.datastax.com/role: database
            - name: rack3
              nodeAffinityLabels:
                mission-control.datastax.com/role: database

    Replace the following:

    • CLUSTER_NAME: The name of the cluster

    • PROJECT_SLUG: The name of the project

    • SERVER_VERSION: The version of the database

    • SERVER_TYPE: The type of the database server: dse

  3. Change the storageClassName to a preferred value, matching the ones available in the installation, or leave the default value. To determine which storage classes are available in the environment, run:

    kubectl get sc

  4. Optional: Append the hostNetwork section at the same level as the config section in the database-cluster.yaml file if you use VMs with a Mission Control embedded Kubernetes runtime:

    ...
  networking:
    hostNetwork: true
  config:
...

    This makes the deployed services directly available on the network.

  5. Apply the manifest:

    kubectl apply -f MANIFEST_FILENAME.yaml

    Replace MANIFEST_FILENAME.yaml with the name of your file.

  6. Check that the pods representing the nodes appear:

    kubectl get pods -n mission-control
    NAME                                                  READY   STATUS    RESTARTS   AGE
cass-operator-controller-manager-6487b8fb6c-xkjjx     1/1     Running   0          41m
k8ssandra-operator-55b44544d6-n8gs8                   1/1     Running   0          41m
mission-control-controller-manager-54c64975cd-nvcm7   1/1     Running   0          41m
test-dc1-default-sts-0                                0/2     Pending   0          7s
test-dc1-default-sts-1                                0/2     Pending   0          7s
test-dc1-default-sts-2                                0/2     Pending   0          7s

    Each node must go through the standard bootstrapping process, which takes a few minutes. The cluster is operational when all of the nodes return 2/2 for READY and Running for STATUS:

    NAME                                                  READY   STATUS    RESTARTS   AGE
cass-operator-controller-manager-6487b8fb6c-xkjjx     1/1     Running   0          50m
k8ssandra-operator-55b44544d6-n8gs8                   1/1     Running   0          50m
mission-control-controller-manager-54c64975cd-nvcm7   1/1     Running   0          50m
test-dc1-default-sts-0                                2/2     Running   0          9m6s
test-dc1-default-sts-1                                2/2     Running   0          9m6s
test-dc1-default-sts-2                                2/2     Running   0          9m6s

    If any pods list their STATUS as Pending, there might be resource availability issues. Run the following command to check the pod status:

    kubectl describe pod POD_NAME

    Replace POD_NAME with the name of your pod.

  7. Discover the username of the automatically generated superuser by accessing the CLUSTER_NAME-superuser secret in the Kubernetes cluster in the mission-control namespace.

    Mission Control is secured by default, and it generates a unique superuser role after disabling the default cassandra role.

    kubectl get secret/CLUSTER_NAME-superuser -n mission-control -o jsonpath='{.data.username}' | base64 -d; echo

    The retrieved username is printed to the console.

  8. Read the username’s password:

    kubectl get secret/CLUSTER_NAME-superuser -n mission-control -o jsonpath='{.data.password}' | base64 -d; echo

    The retrieved password is printed to the console.

  9. Use the superuser username and password to connect to the cluster:

    Embedded Kubernetes cluster

    Because host networking is enabled, connect to any of the nodes through its Internet Protocol (IP) address or hostname using cqlsh with the correct superuser credentials. Port 9042 must be accessible from cqlsh.

    cqlsh --username CLUSTER_NAME-superuser --password SUPERUSER_PASSWORD ip-175-32-24-217
    Connected to test at ip-175-32-24-217:9042
[cqlsh 6.0.0 | Cassandra 4.0.7-c556d537c707 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
test-superuser@cqlsh>
    External Kubernetes cluster

    Port forward the service that exposes the cluster’s CQL port:

    kubectl port-forward svc/CLUSTER_NAME-DATACENTER_NAME-service 9042:9042 -n mission-control

    Then, connect using cqlsh pointing at localhost:

    cqlsh --username CLUSTER_NAME-superuser --password SUPERUSER_PASSWORD 127.0.0.1
    Connected to test at 127.0.0.1:9042.
[cqlsh 6.0.0 | Cassandra 4.0.7-c556d537c707 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
test-superuser@cqlsh>

Next steps

Was this helpful?

Give Feedback

How can we improve the documentation?

© Copyright IBM Corporation 2026 | Privacy policy | Terms of use |  Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: Contact IBM