Overview of CassKop Kubernetes Operator
CassandraCluster, which is used to describe and instantiate Cassandra clusters within a Kubernetes environment.website·Indexed 30 days ago
https://cscetbon.github.io/casskop/CassKop is a Kubernetes operator for managing the lifecycle of Cassandra nodes. It provides capabilities for cluster operations including scaling, backup and restore, health checks, and multi-site deployments on platforms like GKE and minikube. The documentation covers the CassandraCluster and MultiCasskop resources, pod-level operations such as OperationCleanup and OperationRebuild, and integration with Prometheus for metrics export.
CassandraCluster, which is used to describe and instantiate Cassandra clusters within a Kubernetes environment.dc-rack pair defined in the topology section of the CassandraCluster CRD. This architecture ensures a consistent number of Cassandra nodes across each rack within a specified Data Center (DC).CassKop uses three init-containers to configure the Cassandra image before the main Cassandra container starts. A specific bootstrap image (configurable via Spec.bootstrapImage) provides the necessary scripts and files.
/bootstrap directory using cp -vr /etc/cassandra/* /bootstrap.cass-config-builder tool from Datastax to generate configuration files (e.g., cassandra.yaml, jvm.options) based on the CassandraCluster object specifications (spec, datacenters, and racks).Defining a topology allows you to specify multiple datacenters (DCs) and racks. You can use Kubernetes node labels to ensure Cassandra nodes are spread across specific regions or zones.
Key capabilities include:
nodesPerRacks by specifying nodesPerRacks within a specific DC.num_tokens) per DC.Initialization Process:
apiVersion: "db.orange.com/v2"
kind: "CassandraCluster"
metadata:
name: cassandra-demo
spec:
nodesPerRacks: 2
topology:
dc:
- name: dc1
labels:
failure-domain.beta.kubernetes.io/region: europe-west1
rack:
- name: rack1
labels:
failure-domain.beta.kubernetes.io/zone: europe-west1-b
- name: rack2
labels:
failure-domain.beta.kubernetes.io/zone: europe-west1-c
- name: dc2
nodesPerRacks: 3
config:
cassandra-yaml:
num_tokens: 32
labels:
failure-domain.beta.kubernetes.io/region: europe-west1
rack:
- name: rack1
labels:
failure-domain.beta.kubernetes.io/zone: europe-west1-d/test/e2e/kuttl/ directory in parallel. Each test case is executed in a separate generated namespace with CassKop automatically installed. To run a specific test case, use the --test flag followed by the directory name of the test case (e.g., ScaleUpAndDown).# Run all tests
kubectl kuttl test /test/e2e/kuttl/
# Run a specific test case
kubectl kuttl test --test ScaleUpAndDownkubemcsa to export the slave cluster's secret to the master cluster.# Install kubemcsa
export RELEASE_VERSION=v0.6.1
wget https://github.com/admiraltyio/multicluster-service-account/releases/download/${RELEASE_VERSION}/kubemcsa-linux-amd64
mkdir -p ~/tools/kubemcsa/${RELEASE_VERSION} && mv kubemcsa-linux-amd64 tools/kubemcsa/${RELEASE_VERSION}/kubemcsa
chmod +x ~/tools/kubemcsa/${RELEASE_VERSION}/kubemcsa
sudo ln -sfn ~/tools/kubemcsa/${RELEASE_VERSION}/kubemcsa /usr/local/bin/kubemcsa
# Export secret from slave to master
kubectx <master-cluster-context>
kubens ${NAMESPACE}
kubemcsa export --context=gke_poc-rtc_europe-west1-c_cassandra-europe-west1-c-slave --namespace ${NAMESPACE} casskop --as gke-slave-west1-c | kubectl apply -f -- terraform v0.12.7+
- kubectl v1.13.3+
- kubectx & kubens
- Helm v2.15.1+
- gcloud sdk 272.0.0+
- GCP Service Account with 'editor' permissions
- A configured DNS zone in Google Cloud DNSpodLastOperation status in the cluster state.# Using the plugin
kubectl casskop cleanup start
# Manually using labels
kubectl label pod <pod_name> operation-name=cleanup --overwrite
kubectl label pod <pod_name> operation-status=ToDo --overwriteoperator.image.tag parameter during the Helm installation process.helm install --name=casskop --namespace=cassandra --set operator.image.tag=x.y.z oci://ghcr.io/cscetbon/casskop-helmMultiCassKop custom resource and the Helm release. If deleteCassandraCluster was set to true in the configuration, deleting the MultiCassKop object will automatically trigger the deletion of the associated CassandraCluster objects in the targeted Kubernetes clusters, which in turn allows local CassKop instances to delete the Cassandra clusters.kubectl delete multicasskops.db.orange.com multi-casskop-demo
helm delete --purge multi-casskop