In this step, we'll install the Cassandra Kubernetes operator.

Note: We are working with two types of clusters: a Kubernetes cluster and a Cassandra cluster. The Kubernetes cluster is a set of machines (in this case pseudo-virtual machines inside a Docker container) called Kubernetes nodes. The Cassandra cluster is a set of those Kubernetes nodes that host and run the Cassandra software.

Let's lay the groundwork for creating our Cassandra cluster. We'll start by creating a Kubernetes namespace named cass-operator.

kubectl create ns cass-operator

Next, we want to create a StorageClass where the Cassandra nodes can write the data. We can list the existing StorageClasss in the Kubernetes cluster with the following command.

kubectl get storageclass

We see there is already a standard StorageClass. Let's look at it.

kubectl describe storageclass standard

Our configuration of the Kubernetes Operator looks for a StorageClass instance named server-storage. So, we'll create a new StorageClass instance. If you are interested, you can inspect the new StorageClass configuration here: storageclass-kind.yaml

kubectl -n cass-operator apply -f storageclass-kind.yaml

Check out the StroageClass's again to see the server-storage instance.

kubectl get storageclass

Next, we'll install the Cassandra Kubernetes operator.

kubectl -n cass-operator apply -f install-cass-operator-v1.1.yaml

(You can ignore Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply namespace/cass-operator configured)

Let's wait until the pod is up and running.

Note: In commands like the following, watch repeatedly executes a command so we can monitor the status. To exit the watch loop, use Ctrl-C

watch kubectl -n cass-operator get pod

Notice the cass-operator's ID. We can use this ID to investigate the pod.

This command yields just the pod ID.

kubectl -n cass-operator get pod | \
tail -n 1 | \
cut -d " " -f 1

We'll embed that command inside $() to supply the pod ID for another command. The output of outer command describes the operator pod and its events.

kubectl -n cass-operator describe pods \
$(kubectl -n cass-operator get pod | \
tail -n 1 | \
cut -d " " -f 1)

We see the final event is Started, which means the operator is ready to go.

Excellent! Now you have the Cassandra Kubernetes operator installed!

In the first two steps, we created a Kubernetes cluster and installed the Cassandra Kubernetes operator. In this step, we'll create a single node Cassandra cluster.

We create the Cassandra cluster by applying cassandra-cluster.yaml.

kubectl -n cass-operator apply -f cassandra-cluster.yaml

Now, when we check out the pods, we see the Kubernetes operator and the Cassandra cluster/node.

watch kubectl -n cass-operator get pod

Once again, wait for the Cassandra pod (named cluster1-dc1-default-sts-0) to reach the Running status. Then you can exit the watch loop with Ctrl-C.

Eventhough the pod is running, it may take Cassandra a bit longer to initialize. You can track Cassandra's progress with this command.

watch kubectl -n cass-operator -c cassandra exec -it cluster1-dc1-default-sts-0  -- nodetool status

Once the node shows a status of UN (Up and Normal), exit the watch loop using Ctrl-C.

When the operator creates your cluster, it also sets up a Cassandra administrative user named <cluster name>-superuser. We can find the credentials with this command.

kubectl -n cass-operator get secret cluster1-superuser -o yaml

Note: The listed credentials are base64 encoded. We can decode them with the base64 command.

If we post-process the command, we can isolate the username and decode it.

kubectl -n cass-operator get secret cluster1-superuser -o yaml | \
grep username | \
cut -d " " -f 4 | \
base64 -d \
&& echo ""

We can get the generated password for this user in a similar manner.

kubectl -n cass-operator get secret cluster1-superuser -o yaml | \
grep password | \
cut -d " " -f 4 | \
base64 -d \
&& echo ""

We will use these credentials to login to cqlsh on the Cassandra cluster.

Note: The generated username is deterministic as described, so we have hard-coded its value. However, the password will be unique for each cluster, so we use an embedded command (via $()) to supply it. As a result, the command looks a bit lengthy, but the embedded command (i.e., the last four lines) are merely the previous command that supplies the password.

kubectl -n cass-operator exec -c cassandra -it cluster1-dc1-default-sts-0  -- /opt/cassandra/bin/cqlsh -u cluster1-superuser -p \
$(kubectl -n cass-operator get secret cluster1-superuser -o yaml | \
grep password | \
cut -d " " -f 4 | \
base64 -d)

Just to see cqlsh work, list the existing keyspaces.

describe keyspaces;

Amazing! You have used Kubernetes to launch a single node cluster and have accessed it using kubectl and cqlsh!

With the Cassandra cluster up and running and cqlsh open, let's add some sample data.

We'll use cqlsh to:

• Create a user_management keyspace
• Set user_management as the default keyspace
• Create a table named users
• Add some user records to the table

Create the user_management keyspace with the following.

CONSISTENCY LOCAL_QUORUM;
CREATE KEYSPACE IF NOT EXISTS user_management
  WITH replication = {
    'class': 'NetworkTopologyStrategy', 'dc1': '1'
  } AND durable_writes = true;

Set the default keyspace to user_management.

USE user_management;

Now, let's create a table named users as follows.

• Four text columns: last_name, first_name, email and address
• The partition key is the last_name column
• The first_name and email columns are clustering columns
• The address column is a payload column - payload columns just go along for the ride

CREATE TABLE IF NOT EXISTS users (
  last_name   text,
  first_name  text,
  email       text,
  address     text,
  PRIMARY KEY((last_name), first_name, email)
);

Let's put some rows in the table with the following values:

INSERT INTO users
  (last_name, first_name, email, address)
  VALUES(
    'Smith',
    'Alex',
    '[email protected]',
    '123 Main st.');
INSERT INTO users
  (last_name, first_name, email, address)
  VALUES(
    'Smith',
    'Bailey',
    '[email protected]',
    '234 Elm st.');
INSERT INTO users
  (last_name, first_name, email, address)
  VALUES(
    'Jones',
    'Chris',
    '[email protected]',
    '345 Pine st.');

Finally, let's review the contents of the table.

SELECT * FROM users;

NOTE: The previous unconstrained query requires a full table scan. We would not advise using this type of query on production databases because these queries can impact performance. However, for educational purposes on small tables, it's OK.

Exit cqlsh.

quit

Superb! We have Cassandra running with a table containing data!

Imagine you have an app that uses your Cassandra cluster, and the app goes viral! You would need to scale your cluster.

In an unmanaged Cassandra cluster, this can be a bit scary. But, with Kubernetes, it's really easy. Let's give it a try!

Refer back to the cluster description file cassandra-cluster.yaml.

Do you see the line containing size: 1? That line specifies how many nodes there are in the Cassandra cluster. Let's change that to 3.

size: 3

(You will need to wait for the editor to save the changes as indicated when the edited area background changes from yellow to white)

Now, apply the changes to the Cassandra cluster.

kubectl -n cass-operator apply -f cassandra-cluster.yaml

We'll need to wait for the nodes in the cluster to start running. This may take a few minutes, but when you see all the nodes Running, exit the watch loop with Ctrl-C.

watch kubectl -n cass-operator get pod

Once all pods are Running, which make take a minute or better, exit the watch loop with Ctrl-C.

Just because the pods are running doesn't mean the Cassandra cluster is ready. You can check the status of the Cassandra cluster with this command.

watch kubectl -n cass-operator exec -c cassandra -it cluster1-dc1-default-sts-0  -- nodetool status

Once all three nodes have a UN (Up and Normal) status, exit the watch loop using Ctrl-C.

In a previous command, we connected to the node cluster1-dc1-default-sts-0. When Cassandra added the other nodes, it also distributed the data across the nodes. Let's connect with a different node - say, cluster1-dc1-default-sts-1.

kubectl -n cass-operator exec -c cassandra -it cluster1-dc1-default-sts-1  -- /opt/cassandra/bin/cqlsh -u cluster1-superuser -p \
$(kubectl -n cass-operator get secret cluster1-superuser -o yaml | \
grep password | \
cut -d " " -f 4 | \
base64 -d)

Now, let's access the table from this node.

CONSISTENCY LOCAL_QUORUM;
SELECT * FROM user_management.users;

NOTE: The previous unconstrained query requires a full table scan. We would not advise using this type of query on production databases because these queries can impact performance. However, for educational purposes on small tables, it's OK.

We see we can connect from another node, but let's have Cassandra take advantage of these additional nodes in another way. We want to spread replicas of the data across the nodes so we improve availability and accessibility. We do this by increasing the keyspace replication factor to three.

alter keyspace user_management with replication={'class':'NetworkTopologyStrategy', 'dc1':3};

Quit out of cqlsh from this node.

quit

Finally, let's connect to the third Cassandra node - just to show off!

kubectl -n cass-operator exec -c cassandra -it cluster1-dc1-default-sts-2  -- /opt/cassandra/bin/cqlsh -u cluster1-superuser -p \
$(kubectl -n cass-operator get secret cluster1-superuser -o yaml | \
grep password | \
cut -d " " -f 4 | \
base64 -d)

Check out the table again.

CONSISTENCY LOCAL_QUORUM;
SELECT * FROM user_management.users;

You now have a resilient Cassandra cluster with three replicas of the data spread across three nodes!

Dazzling! Kubernetes makes it sooooo easy to scale out a Cassandra cluster!