How do we use Configmap utility in k8ssandra helm?

Question

I am trying to migrate cassandra DB to AKS using k8ssandra. I would like to retain the source DB's cassandra.yaml configuration in the target as well, like increase the timeout parameters ( to handle client requests). I see the configmap placeholder in the k8ssandra's values.yaml file. Would it help to retain the source configurations? Detailed guideline on how to use it is much appreciated :)

Answer 1

Support for specifying Casssandra configs via a ConfigMap was added in this PR and made available in K8ssandra 1.4.0.

The new chart property name is cassandraYamlConfigMap. Here is what the docs for the property say:

# -- Specifies the name of a ConfigMap that contains a custom cassandra.yaml. The
# ConfigMap should have a key named cassandra.yaml. The values will be merged with the
# base configuration. The following properties should NOT be specified in the ConfigMap:
#    * cluster_name
#    * seed_provider
#    * authenticator
#    * authorizer
#    * commitlog_directory
#    * data_file_directories
#    * saved_caches_directory
#    * hints_directory
#    * endpoint_snitch

Here is an example ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cassandra-config
data:
  cassandra.yaml: |-
    auto_snapshot: false
    memtable_flush_writers: 1
    commitlog_segment_size_in_mb: 2
    concurrent_compactors: 1
    compaction_throughput_mb_per_sec: 0
    sstable_preemptive_open_interval_in_mb: 0
    key_cache_size_in_mb: 0
    prepared_statements_cache_size_mb: 1
    slow_query_log_timeout_in_ms: 0
    counter_cache_size_in_mb: 0
    concurrent_reads: 2
    concurrent_writes: 2
    concurrent_counter_writes: 2
    read_request_timeout_in_ms: 90000
    range_request_timeout_in_ms: 90000
    write_request_timeout_in_ms: 90000
    truncate_request_timeout_in_ms: 90000
    request_timeout_in_ms: 90000

Here's how this works. The cassandra.yaml, jvm-server-options, etc. are generated as normal when cassandraYamlConfigMap is set. After the server-config-init init container generates the configs, then a new init container called apply-custom-config does a merge using yq of the cassandra.yaml in the ConfigMap and the cassandra.yaml generated by server-config-init. The ConfigMap takes precedence.

Make sure to pay attention to the properties that should not be specified. No validation checks are performed on the ConfigMap.

Note that you will need to use the cassandraYamlConfigMap property if you want to configure internode encryption. See this post for a detailed explanation.

Lastly, I want to point out that there is improved support for configuring cassandra.yaml in K8ssandra Operator. The operator does not allow you to specify a custom ConfigMap but all cassandra.yaml properties are available in the K8ssandraCluster CRD. See here for an example.