Administer clusters
Mission Control clusters are objects describing the topology and settings of Apache Cassandra® and DataStax Enterprise (DSE) database instances.
Mission Control creates at least one project to contain a logical group of clusters.
DataStax Enterprise (DSE) cluster management encompasses the entire lifecycle of cluster components. This includes creating datacenter-level resources across Kubernetes cluster boundaries, orchestrating automation steps at appropriate intervals given a specific cluster state, and remediating issues as they arise. Given the distributed nature of Mission Control, there are Kubernetes operators local to each Kubernetes cluster which respond to events within the local cluster. This enables continuous operations and remediation even during periods of network partitioning.
Use Mission Control for database cluster tasks such as configuration, execution, and monitoring status during a cluster lifecycle or a:
-
datacenter lifecycle addressing Add a datacenter to an existing DataStax Enterprise (DSE) cluster or Terminate a datacenter within an existing DSE cluster.
-
node lifecycle addressing Add nodes to a cluster, Replace a node, Remove nodes from a cluster, or Use per-node configurations.
Interactions with Mission Control are broadly categorized as declarative or imperative. Use declarative APIs to define a desired end-state and Mission Control constantly takes steps to achieve that declared goal. For example, handle the definition of a DataStax Enterprise (DSE) cluster or datacenter through declarative APIs because these are long-lived resources that require reconciliation. In comparison, imperative APIs describe a singular operation or task to be run to completion with an associated status. Imperative APIs within Mission Control include operational tasks on a specified cluster, such as performing a rolling restart.
Perform declarative or imperative operations at either the cluster or the datacenter level.
- Cleanup
-
Run the DSE
nodetool cleanup
command for specific keyspaces on all nodes in a particular datacenter (DC). - Rebuild
-
Run the DSE
nodetool rebuild
command across a datacenter to populate data by streaming from another (source) datacenter (DC). - Replace a DSE node
-
Replaces an existing node with a new, empty pod owning the same token ranges.
- Rolling Restart
-
Restart all nodes in a cluster in a rolling fashion while applications continue to run with zero downtime.
- Backup data
-
Backs up Apache Cassandra® and DataStax Enterprise (DSE) data in Kubernetes.
- Restore a data backup
-
Restores Apache Cassandra® and DataStax Enterprise (DSE) data in Kubernetes.
- Upgrade SSTables
-
Upgrade all SSTables to newer formats where required.
Pre-configure a cluster manifest
In order to provide traceability and repeatability of the cluster creation process, the recommendation is to
store the cluster manifest in a Git repository.
Use your configured cluster manifest to Create a new cluster using either the UI or a CLI command.
The manifest also exposes a partial subset of the MissionControlCluster
resource definition, which can be changed
by editing the cluster manifest.
Access the Mission Control User Interface (UI)
Mission Control provides a UI through the IP address of any node using port 30880
on the Control-Plane
cluster.
For example, issue https://10.0.0.3:30880
from a web browser, where 10.0.0.3
is a qualifying nodes' IP address.
Prerequisites
Because Mission Control organizes clusters by projects, an existing project is required. See create project.
Cluster tasks
Create a new cluster
-
UI
-
CLI
-
In order to display a cluster manifest, click on the Output button of the Cluster Creation page:
-
After creating at least one project and clicking on it in the UI sidebar, you can create a new cluster by clicking on the Create Cluster button on the Project page:
This displays the Create Cluster form:
-
Required fields are annotated with a red asterisk. The form does not allow you to submit it if any of the required fields are missing.
-
The version number is expected in the
#.#.#
format (for example, 0.8.0), and should point to a valid version of Apache Cassandra® and DataStax Enterprise (DSE) that Mission Control supports. Supported versions evolve from one release to the next. Refer to the DataStax supported software and retention policy.
Please refer to the Mission Control Release Notes for a complete list of supported versions.
-
-
You are required to specify at least one datacenter and one rack to create a cluster. You can add more datacenters and racks upon creation or during cluster modification.
-
Clicking the Create Cluster button creates the cluster and redirects you to the Project page which should display the newly created cluster in a card:
The card list is limited to three clusters. Display the complete list by clicking on the
Clusters →
sidebar menu item:This displays the list of clusters and datacenters:
The cluster manifest is generated from a MissionControlCluster
resource definition.
Here is an example of a cluster definition:
apiVersion: missioncontrol.datastax.com/v1beta1
kind: MissionControlCluster
metadata:
name: test
namespace: <project-slug>
spec:
k8ssandra:
cassandra:
serverVersion: 6.8.36
serverType: dse
storageConfig:
cassandraDataVolumeClaimSpec:
storageClassName: standard
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
networking:
hostNetwork: true
config:
jvmOptions:
heapSize: 512M
datacenters:
- metadata:
name: dc1
size: 3
resources:
requests:
memory: 1Gi
The complete list of fields used by Mission Control in the k8ssandra:
section is documented in
the Mission Control Cluster[full MissionControlCluster
manifest template].
-
Replace the
<project-slug>
placeholder with the namespace of the project where you want to create the cluster. -
After saving this generated manifest to a file, create the cluster with the following command:
kubectl apply -f <manifest-filename>.yaml
-
In addition to the
k8ssandra:
section, theMissionControlCluster
resource definition also contains settings which are specific to Mission Control:apiVersion: missioncontrol.datastax.com/v1beta1 kind: MissionControlCluster metadata: name: test namespace: <project-slug> spec: k8ssandra: ... createIssuer: true encryption: internodeEncryption: enabled: true certs: createCerts: true certTemplate: ...
-
The
createIssuer
field, whentrue
, enables Mission Control to manage the Transport Layer Security (TLS) issuer. Setting this field tofalse
indicates the user must provision secrets (certificates) when utilizing TLS.controls whether Mission Control should create a Cert-Manager Certificate Issuer resource to manage the certificates used for internode encryption.
-
The
encryption:
section contains the settings for the internode encryption certificates. Internode encryption is enabled by default, and can be disabled by setting.spec.encryption.internodeEncryption.enabled
tofalse
. See detailed information in the internode encryption documentation.
Modify a cluster
-
UI
-
CLI
TBD.
You can modify a cluster by editing the cluster manifest and applying the changes with the kubectl apply
command.
kubectl apply -f <manifest-filename>.yaml
Delete a cluster
-
UI
-
CLI
TBD.
Deleting a cluster is as simple as deleting the `MissionControlCluster` resource: [source,shell]
kubectl delete missioncontrolcluster <name> -n <project-slug>
Substitute the name of the `MissionControlCluster` resource in the <name> variable and the namespace of the chosen project for the <project-slug> variable.