Configure Cassandra or DSE in Kubernetes with Cassandra Operator

Configure Cassandra or DSE in Kubernetes with Cass Operator.

1. Create a namespace
   Cass Operator is built to watch over pods running Cassandra 3.11 or later, or DSE 6.8.0 or later, in a Kubernetes namespace. Create a namespace for the cluster. Example:

   kubectl create ns my-db-ns

   In this topic, we will use the namespace my-db-ns. Adjust subsequent commands to match the namespace that you defined.
2. Define a storage class
   Kubernetes uses the StorageClass resource as an abstraction layer between pods needing persistent storage and the physical storage resources that a specific Kubernetes cluster can provide.

   Tip: For an introduction to the storage class, refer to the Kubernetes documentation.

   DataStax recommends that you use the fastest type of networked storage available. For example, on Google Kubernetes Engine (GKE), the following YAML parameters would define persistent network SSD-backed volumes.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: server-storage
   provisioner: kubernetes.io/gce-pd
   parameters:
     type: pd-ssd
     replication-type: none
   volumeBindingMode: WaitForFirstConsumer

   You can customize the values for your environment and save the configuration. For example, as server-storage.yaml. This topic assumes you have defined a StorageClass and named it server-storage. Using the kubectl command, apply that file and get the resulting storage classes from Kubernetes with the following:

   kubectl -n my-db-ns apply -f ./server-storage.yaml

   To verify the storage class configuration:

   kubectl -n my-db-ns get storageclass

   NAME                 PROVISIONER            AGE
   server-storage       kubernetes.io/gce-pd   1m
   standard (default)   kubernetes.io/gce-pd   16m

3. Deploy the operator
   The examples in this guide present several Kubernetes resources in a single operator YAML manifests file. It contains the properties needed to deploy the operator. DataStax provides a set of Cass Operator sample manifest YAML files based on supported Kubernetes releases. Download and customize the relevant YAML for your environment. The file includes values for the following resources:

   1. ServiceAccount, Role, and RoleBinding to describe a user and set of permissions necessary to run the operator. In non-production environments that do not have role-based access control enabled, these extra steps are unnecessary but do no harm to have defined, and serve as a best practice example ahead of your eventual production deployments.
   2. CustomResourceDefinition (CRD) for the CassandraDatacenter resources used to configure clusters managed by Cass Operator.
   3. Deployment parameters to start the operator in a state where it waits and watches for CassandaDatacenter resources.

   Generally, cluster-admin privileges are required to register a CRD. All privileges needed by Cass Operator are present within the release-specific sample manifest YAML files hosted by DataStax.

   Note: The operator does not require cluster-admin privileges. Only the user defining the CRD requires those permissions.

   Using kubectl, apply the cass-operator-manifests YAML file and wait for the deployment to become ready. Example:

   kubectl -n my-db-ns apply -f ./cass-operator-manifests.yaml

4. Track progress during deployment
   For this async operation, you can watch the status by periodically checking the list of pods for the namespace. Example:

   kubectl -n my-db-ns get pod 

   NAME                           READY  STATUS   RESTARTS  AGE 
   cass-operator-f74447c57-kdf2p  1/1    Running  0         1h 

   When the pod status is Running, the operator is ready to use.