CassKop Documentation

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.

Tokens
33.3K
Snippets
138
Records
208
Agent score
74%

What's inside CassKop

  1. Overview of CassKop Kubernetes Operator

    CassKop is an open-source Kubernetes custom controller (released under the Apache 2.0 license) designed to manage Cassandra clusters. It introduces a new Kubernetes custom resource (CRD) called CassandraCluster, which is used to describe and instantiate Cassandra clusters within a Kubernetes environment.
  2. Overview of CassKop Cassandra Kubernetes Operator

    CassKop is a Kubernetes operator designed to automate the provisioning, management, autoscaling, and operations of Apache Cassandra clusters. It is built using the CoreOS operator-sdk and is space-scoped, meaning one instance of CassKop is required per Kubernetes namespace. A single operator instance can manage multiple Cassandra clusters within its own namespace, providing security and isolation between different namespaces.
  3. Understand CassKop's StatefulSet-per-rack architecture

    CassKop creates a dedicated Kubernetes StatefulSet and Service for every 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).
  4. Understand the CassKop Cassandra bootstrap process

    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.

    1. base-config-builder: Copies default Cassandra configuration from the user-provided Cassandra image to the /bootstrap directory using cp -vr /etc/cassandra/* /bootstrap.
    2. config-builder: Uses the 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).
    3. bootstrap: Finalizes the configuration by adding files/jars from the bootstrap image, applying ConfigMap overrides, updating the cluster name, setting the seed list, and adding the Cassandra exporter and Jolokia agent.
  5. Manage Cassandra clusters using Kubernetes StatefulSets

    The CassKop Operator utilizes Kubernetes StatefulSets to deploy Apache Cassandra clusters. This ensures that each Cassandra node has a unique identifier, sticky identity across rescheduling, networking via headless services, and dedicated Persistent Volumes.
  6. Initialize a Cassandra cluster with a custom topology

    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:

    • Granular Scaling: Override the global nodesPerRacks by specifying nodesPerRacks within a specific DC.
    • DC-Specific Config: Provide specific Cassandra configurations (e.g., num_tokens) per DC.

    Initialization Process:

    1. FirstPodPerRack: CassKop creates one pod in each declared rack.
    2. NextPodPerRack: CassKop scales out racks one by one, adding pods until the desired count is reached.
    3. Running: The cluster enters the Running phase once all racks reach the desired node count.
    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
  7. Run e2e tests with kuttl

    Run all test cases located in the /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 ScaleUpAndDown
  8. Configure cross-cluster API access using kubemcsa

    To allow the Multi-CassKop controller in the master cluster to access the slave cluster, use kubemcsa 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 -
  9. Prerequisites for Multi-CassKop GKE deployment

    To deploy Multi-CassKop on GKE, the following tools and environment requirements must be met:
    - 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 DNS
  10. Trigger a Cassandra cleanup operation on a Pod

    A cleanup operation can be triggered automatically by CassKop after scaling the cluster, via the kubectl plugin, or manually by applying specific labels to the target Pod. CassKop detects these labels and updates the podLastOperation 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 --overwrite
  11. Clean up and delete Multi-CassKop deployment

    To remove the Multi-CassKop deployment, delete the MultiCassKop 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