k8ssandra / k8ssandra-client Goto Github PK

0.0 0.0 4.0 456 KB

License: Apache License 2.0

Makefile 2.04% Dockerfile 0.64% Go 89.09% Shell 8.23%

k8ssandra-client's Introduction

[DEPRECATED]

This project is deprecated and replaced by k8ssandra-operator

Read this blog post to see what differences exist between K8ssandra and k8ssandra-operator, and why we decided to build an operator.
Follow our migration guide to migrate from K8ssandra (and Apache Cassandra®) to k8ssandra-operator.

K8ssandra

K8ssandra is a simple to manage, production-ready, distribution of Apache Cassandra and Stargate that is ready for Kubernetes. It is built on a foundation of rock-solid open-source projects covering both the transactional and operational aspects of Cassandra deployments. This project is distributed as a collection of Helm charts. Feel free to fork the repo and contribute. If you're looking to install K8ssandra head over to the Quickstarts.

Components

K8ssandra is composed of a number of sub-charts each representing a component in the K8ssandra stack. The default installation is focused on developer deployments with all of the features enabled and configured for running with a minimal set of resources. Many of these components may be deployed independently in a centralized fashion. Below is a list of the components in the K8ssandra stack with links to the appropriate projects.

Apache Cassandra

K8ssandra packages and deploys Apache Cassandra via the cass-operator project. Each Cassandra container has the Management API for Apache Cassandra (MAAC) and Metrics Collector for Apache Cassandra(MCAC) pre-installed and configured to come up automatically.

Stargate

Stargate provides a collection of horizontally scalable API endpoints for interacting with Cassandra databases. Developers may leverage REST and GraphQL alongside the traditional CQL interfaces. With Stargate operations teams gain the ability to independently scale coordination (Stargate) and data (Cassandra) layers. In some use-cases, this has resulted in a lower TCO and smaller infrastructure footprint.

Monitoring

Monitoring includes the collection, storage, and visualization of metrics. Along with the previously mentioned MCAC, K8ssandra utilizes Prometheus and Grafana for the storage and visualization of metrics. Installation and management of these pieces is handled by the Kube Prometheus Stack Helm chart.

Repairs

The Last Pickle Reaper is used to schedule and manage repairs in Cassandra. It provides a web interface to visualize repair progress and manage activity.

Backup & Restore

Another project from The Last Pickle, Medusa, manages the backup and restore of K8ssandra clusters.

Next Steps

If you are looking to run K8ssandra in your Kubernetes environment check out the Getting Started guide, with follow-up details for developers and site reliability engineers.

We are always looking for contributions to the docs, helm charts, and underlying components. Check out the code contribution guide and docs contribution guide

If you are a developer interested in working with the K8ssandra code, here is a guide that will give you an introduction to:

Important technologies and learning resources
Project components
Project processes and resources
Getting up and running with a basic IDE environment
Deploying to a local docker-based cluster environment (kind)
Understanding the K8ssandra project structure
Running unit tests
Troubleshooting tips

Dependencies

For information on the packaged dependencies of K8ssandra and their licenses, check out our open source report.

k8ssandra-client's People

Watchers

Forkers

burmanm sseidman dnugmanov miles-garnsey

k8ssandra-client's Issues

cluster_name not populated in cassandra.yaml by k8ssandra-client

Issue Description:

I've noticed that the k8ssandra-client does not fill the cluster_name field in cassandra.yaml. The ClusterInfo struct contains a field for the cluster name, but it doesn't seem to be used anywhere in the code. This leads to incorrect monitoring metrics from the exporter because it fills the cluster_name label according to the cassandra.yaml parameters.

Example:

❯ cassandra@damir-test-damir-test-dc-rack1-sts-0:/$ cat /etc/cassandra/cassandra.yaml | grep cluster_name
cluster_name: Test Cluster

❯ k get pods -n mynamespace -o yaml | grep CONFIG_FILE_DATA -A 1
  - name: CONFIG_FILE_DATA
    value: '{"cassandra-env-sh":{"___OMITTED:___"cluster-info":{"name":"damir-test","seeds":"damir-test-seed-service,damir-test-damir-test-dc-additional-seed-service"},___OMITTED:___}'

Expected Behavior:

I believe the cluster_name field in cassandra.yaml should be properly filled by the k8ssandra_client.

Additional Information:

k8ssandra-client version: v0.2.0

Config builder needs to copy logback.xml and jvm*-client.options

The missing logback.xml causes the server-system-logger to miss logging. While we do log stdout.log, the system.log is what we want in our other configuration in cass-operator.

The missing jvm*-client.options on the other hand causes the nodetool to not work correctly on the 4.1.4 image.

Add kind backed envtests

For the data plane registration work, we need all native k8s controllers running to ensure we can get SA secrets populated.

We propose to add envtests backed by kind clusters to make this happen.

Move the dataplane registration into the kubectl plugin

We currently use a script to register dataplanes and making this feature available in the kubectl plugin would create a better experience for this operation.

DoD

Beta Give feedback

dataplanes can be registered into the CP using the kubectl plugin
Options

Need warnings / errors for 5.0 settings which we can't merge

If user upgrades from <5.0 to 5.0 and uses their old settings for PasswordAuthenticator, this could cause the user to expose their Cassandra cluster as unauthenticated. The reason is the change in cassandra_latest.yaml from:

authenticator: PasswordAuthenticator

authenticator:
  class_name : org.apache.cassandra.auth.PasswordAuthenticator

If user has their existing setting in the cass-operator input:

  config:
    cassandra-yaml:
      authenticator: PasswordAuthenticator

This will result in the output with the default value from cassandra_latest.yaml which is AllowAllAuthenticator. This is because of a limitation of goalesce, which doesn't throw an error if it fails to actually set the value but instead will use the default value (while it should use the new value whatever that is). The input is of type map[string]interface{} turning to map[string]string while the target is map[string]interface{} being casted to map[string]map[string]interface{}.