Get started with Cassandra Operator

Get started with Cass Operator in Kubernetes.

To get started, follow the steps in this topic.

Tip: If you haven't already, create a Kubernetes cluster. For a walkthrough of the steps – especially if you're new to Kubernetes – see the Google Kubernetes Engine (GKE) cloud example in this guide's topic, Create a Kubernetes cluster.

Quick start

The following kubectl commands create Cass Operator and Apache Cassandra® resources on an existing GKE cloud that's running Kubernetes version 1.16. Adjust the commands based on your cloud, storage, and database options.

Recall from this guide's prior topic, Create a Kubernetes cluster, you must have already established an authorized connection between your local machine (from which you'll run kubectl commands) and your existing Kubernetes cluster. See especially these sections from that topic:

The first kubectl command references YAML that applies the Cass Operator manifest's definitions to the connected Kubernetes cluster. In this example, the definitions are for a Kubernetes v1.16 cluster. For the complete set of version-specific manifests, see this GitHub page. Here's the direct link to the YAML applied in this v1.16 example.
```
kubectl create -f https://raw.githubusercontent.com/datastax/cass-operator/v1.6.0/docs/user/cass-operator-manifests-v1.16.yaml
```
The next kubectl command applies YAML that defines the storage settings to use for Cassandra nodes in a cluster. Example: SSD as storage type. In this case, it's for a GKE cluster. 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. For more options, see this GitHub page. Here's the direct link to the YAML applied in this storage configuration example.
```
kubectl create -f https://raw.githubusercontent.com/datastax/cass-operator/v1.6.0/operator/k8s-flavors/gke/storage.yaml
```
Finally, the third kubectl command applies YAML that defines a CassandraDatacenter with the open-source Apache Cassandra® 3.11.7 image, with three nodes on one rack, in the Kubernetes cluster. For the complete set of database-specific datacenter configurations, DSE or Cassandra, see this GitHub page. Here's the direct link to the YAML applied in this Cassandra 3.11.7 datacenter configuration example.
```
kubectl -n cass-operator create -f https://raw.githubusercontent.com/datastax/cass-operator/v1.6.0/operator/example-cassdc-yaml/cassandra-3.11.x/example-cassdc-minimal.yaml
```
Tip: As an alternative to the step 3 command above, to instead create the CassandraDatacenter with the DSE 6.8.4 image, with three Kubernetes worker nodes on one rack, use:
```
kubectl -n cass-operator create -f https://raw.githubusercontent.com/datastax/cass-operator/master/operator/example-cassdc-yaml/dse-6.8.x/example-cassdc-minimal.yaml
```

Resources deployed and visible in Cloud Console

Having applied the Cass Operator manifest, storage class, and datacenter definitions to the Kubernetes cluster with the commands above, it's time to look at the resources created and now visible in the Kubernetes cluster. For this GKE example, we'll use the Google Cloud Console, and the resources already established in Create a Kubernetes cluster.

Note: Subsequent text refers to the Google Cloud Console as Cloud Console.

Navigate to the Kubernetes Engine page in Cloud Console, and log into your account. If you haven't already done so, select your project.

On the Clusters tab, click the link for your cluster's name. Navigate through the Details, Storage, and Nodes sections to familiarize yourself with the created resources. Example from the Storage section of the Clusters tab:

Storage details in Cloud Console's Kubernetes Engine Clusters tab reflecting the settings created by the applied YAML files

You can access similar information, plus the YAML used to define the configuration, from the Storage tab in the left navbar.

Next, click the Workloads tab. Workloads are deployable computing units that can be created and managed in the Kubernetes cluster. From the YAML applied by the Cass Operator manifest, we defined the cass-operator namespace and workload. Click its link on the Workloads page to load details about the Cass Operator and Cassandra deployments in the Kubernetes cluster. For example:

Workload details for cass-operator in Cloud Console

On the Services & Ingress tab, notice how the Service labels for the deployed cluster1 Cassandra cluster, and for the dc1 datacenter, correspond to the YAML applied earlier in this topic via kubectl. Also notice the three serving pods. Services are sets of Pods with a network endpoint that can be used for discovery and load balancing. Ingresses are collections of rules for routing external HTTP or HTTPS traffic to Services.

From the initial Services tab, having clicked on the cluster1-dc1-service, Cloud Console displays the status. Example:

Service details for cluster1 Cassandra cluster and dc1 datacenter Cloud Console Kubernetes Engine Services tab

In the Serving pods section, to get more details, click the link for one of the serving pods. Cloud Console switches to the Workloads tab, and the Pod details page includes the status labels, such as cassandra.datastax.com/node-state: Started and additional metadata. Scroll down to the Containers section and notice the running container for the cassandra 3.11.7 image, deployed to your Kubernetes cluster, again matching the YAML configuration applied earlier in this topic. Example:

Services tab has Containers section with status of the Cassandra 3.11.7 image container

Tip: While many more options are available in Cloud Console, the introduction above was meant to familiarize you with the basics, and how applying the provided YAML files earlier in this topic resulted in the creation and deployment of those Cass Operator and Cassandra resources in the Kubernetes cluster.

What's next?

Now that you've deployed Cass Operator and Cassandra to your Kubernetes cluster, proceed to the next topic. It explains how to connect within the Kubernetes cluster to the deployed Cassandra database.