Apache Cassandra Lunch #78: Cass Operator

In Cassandra Lunch #78, we will deploy Cassandra using DSE Operator to Kubernetes. The live recording of Cassandra Lunch, which includes a more in-depth discussion and a demo, is embedded below in case you were not able to attend live. If you would like to attend Apache Cassandra Lunch live, it is hosted every Wednesday at 12 PM EST. Register here now!

What is Cass Operator?

DataStax Kubernetes Operator automates the process of deploying and managing open-source Apache Cassandra® or DataStax Enterprise (DSE) in a Kubernetes cluster.

Cass Operator distills the user-supplied information down to the number of nodes and cluster name to manage the lifecycle of individual Kubernetes resources. Now the process of managing the distributed Cassandra or DSE data platform is turnkey and much easier, which means your team is free to focus on the application layer and its functionality.

Kubernetes and Containers

Containers are a popular technology used to accelerate today’s application development. Thanks to prevalent container platforms like Docker, you can package applications efficiently. With containers, apps, and all of their dependencies are packaged together into a minimal deployable image. As a developer, you can use containers to move applications between environments and guarantee that your apps behave as expected. These goals led to the creation of container orchestration platforms. The leader in this space is Kubernetes.

• Kubernetes accepts definitions for services and handles the assignment of containers to servers and connecting them together.
• Kubernetes dynamically tracks the health of the running containers. If a container goes down, Kubernetes handles restarting it, and can schedule its container replacement on other hardware.
• By using Kubernetes to orchestrate containers, you can rapidly build microservice-powered applications and ensure they run as designed across any Kubernetes platform.

Cassandra and Kubernetes

Apache Cassandra is an open-source, NoSQL database built from the foundation of geographically distributed and fault-tolerant data replication. Given the nature of containers, Cassandra is a logical fit as the cloud-native data plane for Kubernetes.

• All nodes are equal, and each node is capable of handling read and write requests with no single point of failure.
  
• Data is automatically replicated between failure zones to prevent the loss of a single container taking down your application.
  
• With simple configuration options in Cass Operator, Cassandra and DSE databases can rapidly take advantage of Kubernetes orchestration and are well suited for the container-first approach in your enterprise.

Demo: Tutorial

To spin up a Cassandra cluster using the cases operator is fairly simple and takes a few moments in a local environment. I have created a repo on GitHub which you can follow along.

1. We need a Kubernetes cluster and the easiest way to spin up a local cluster is by using Minikube, if you are new to kubernetes i reccomend you read this article which explains more in depth how to start minikube.
   minikube start --cpus=5 --memory='10128m'
   
2. Cert-manager is a Kubernetes add-on to automate the management and issuance of TLS certificates from various issuing sources. It will ensure certificates are valid and up to date periodically, and attempt to renew certificates at an appropriate time before expiry. Default install requires cert-manager to be installed, since webhooks require TLS certificates to be injected.
   kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.5.3/cert-manager.yaml
   
3. For the cass-operator we need a StorageClass with WaitForFirstConsumer Volume Binding Mode and if you are deploying it to a cloud service make sure to use server-storage StorageClass but for the local deployment we need local-path
   kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
   
4. Default installation in cass-operator namespace, keep in mind that this will create a new namespace and the cass-operator will be installed there
   kubectl apply -k github.com/k8ssandra/cass-operator/config/deployments/default
   
5. In the repo you can find 3 yaml files where you can choose whichever you want to deploy, just make sure you use the flag -n cass-operator
kubectl -n cass-operator apply -f dc.yaml
   
6. The operator creates a secure Cassandra cluster by default, with a new superuser (not the traditional cassandra user) and a random password. You can get those out of a Kubernetes secret and use them to log into your Cassandra cluster for the first time. For example:

CASS_USER=$(kubectl -n cass-operator get secret cluster1-superuser -o json | jq -r '.data.username' | base64 --decode)
CASS_PASS=$(kubectl -n cass-operator get secret cluster1-superuser -o json | jq -r '.data.password' | base64 --decode)
kubectl -n cass-operator exec -ti cluster1-dc1-default-sts-0 -c cassandra -- sh -c "cqlsh -u '$CASS_USER' -p '$CASS_PASS'"

If you missed Cassandra Lunch #78: Cass Operator, it is embedded below! Additionally, all of our live events can be rewatched on our YouTube channel, so be sure to subscribe and turn on your notifications!

Cassandra.Link

Cassandra.Link is a knowledge base that we created for all things Apache Cassandra. Our goal with Cassandra.Link was to not only fill the gap of Planet Cassandra but to bring the Cassandra community together. Feel free to reach out if you wish to collaborate with us on this project in any capacity.

We are a technology company that specializes in building business platforms. If you have any questions about the tools discussed in this post or about any of our services, feel free to send us an email!