What’s New With The K8ssandra Operator
Author: John Sanda
In this post, we’ll give an overview of the latest release of the K8ssandra Operator, which now provides multi-cluster and multi-region support for Apache Cassandra® databases deployed in Kubernetes.
If you’ve ever used Kubernetes, you know it’s a powerful framework for cloud-based systems. You also probably know that creating, deploying, and managing these systems can be a nightmare.
Besides creating the necessary Kubernetes objects such as pods, deployments, services, and configMaps, you also have to wire all the pieces together so they can talk to each other. The more components your system has, the more complex it all becomes.
K8ssandra is an open-source project built to simplify running Cassandra on Kubernetes. It does this by providing a suite of tools that automate operational tasks, such as repairs, backup/restore, and monitoring.
Part of the overall K8ssandra project is the K8ssandra Operator, which provides single or multi-cluster, multi-region support in Kubernetes when deployed with K8ssandra. In short, by using this Operator, all of the components for metrics, backup and more are already installed and wired together, (which is good news for your team).
So, now that we’ve dropped the latest release of the K8ssandra Operator, here’s a quick peek into what it’s all about, what’s new, and why it matters to developers.
Meet the K8ssandra Operator
Our newest implementation, K8ssandra Operator, allows developers to deploy Cassandra databases in multi-cluster and multi-region Kubernetes environments. It also works in single-cluster and single-region Kubernetes deployments. Here’s an architecture diagram from the project’s Readme on Github.
To closely match this setup, we’ve set up a Google Kubernetes Engine (GKE), a managed environment that allows you to deploy, manage, and scale your containerized applications using Google.
In Figure 1, there are three Kubernetes clusters with a K8ssandra operator in each. The bottom two are the “data-plane,” and the top cluster is the “control-plane.” In US East 1, there are two data plane clusters in US East 1 and a control plane cluster. In US West 1, there’s one data plane cluster.
One difference between a data plane and a control plane is that some controllers only run in the control plane due to a configuration setting. But the most important distinction is that we only create connections to remote clusters and orchestrate across the clusters in the control plane.
For now, the Operator requires you to have routable pod IPs between Kubernetes clusters, though this may be relaxed in the future. If you’re running the Operator in a cloud provider like Amazon Web Services, you can get routable IPs by installing the Kubernetes clusters in the same Virtual Private Cloud (VPC). If you’re running multiple kind clusters locally, you’ll have routable pod IPs assuming that they can run on the same Docker network which is normally the case.
So, what else is new?
Our focus for the K8ssandra Operator v1.1 was the ability to restore Medusa backups from one cluster to another. Here’s a quick list of the changes this remote restore support involves, plus a few other enhancements v1.1 brings to your K8ssandra clusters.
- Remote restore with Medusa (feature)
- New Custom Resource Definitions (CRDs)
- Purging backups
- Medusa CLI compiled in the Docker image
- Improvements around adding a DC to an existing cluster (bug fix)
- Configure Java garbage collection properties (bug fix)
This post introduced you to the latest upgrades to the K8ssandra Operator! Stay tuned for an upcoming YouTube workshop that will take a deeper dive into the Dos and Don’ts of using the K8ssandra Operator to deploy Apache Cassandra Databases on Multi-Cluster Kubernetes.
In the meantime, if you’re coming to KubeCon/CloudNativeCon Europe 2022, stop by the DataStax booth for a quick demo.