Apache Cassandra is an open source distributed database management system designed to handle large amounts of data across many servers, providing high availability with no single point of failure.
[Overview of Apache Cassandra](http://cassandra.apache.org/)
Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.
This chart bootstraps an [Apache Cassandra](https://github.com/bitnami/containers/tree/main/bitnami/cassandra) deployment on a [Kubernetes](https://kubernetes.io) cluster using the [Helm](https://helm.sh) package manager.
Bitnami charts can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
## Prerequisites
- Kubernetes 1.19+
- Helm 3.2.0+
- PV provisioner support in the underlying infrastructure
## Installing the Chart
To install the chart with the release name `my-release`:
These commands deploy one node with Apache Cassandra on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation.
> **Tip**: List all releases using `helm list`
## Uninstalling the Chart
To uninstall/delete the `my-release` release:
```console
$ helm delete my-release
```
The command removes all the Kubernetes components associated with the chart and deletes the release.
| `dbUser.user` | Cassandra admin user | `cassandra` |
| `dbUser.forcePassword` | Force the user to provide a non | `false` |
| `dbUser.password` | Password for `dbUser.user`. Randomly generated if empty | `""` |
| `dbUser.existingSecret` | Use an existing secret object for `dbUser.user` password (will ignore `dbUser.password`) | `""` |
| `initDBConfigMap` | ConfigMap with cql scripts. Useful for creating a keyspace and pre-populating data | `""` |
| `initDBSecret` | Secret with cql script (with sensitive data). Useful for creating a keyspace and pre-populating data | `""` |
| `existingConfiguration` | ConfigMap with custom cassandra configuration files. This overrides any other Cassandra configuration set in the chart | `""` |
| `cluster.name` | Cassandra cluster name | `cassandra` |
| `cluster.seedCount` | Number of seed nodes | `1` |
| `cluster.numTokens` | Number of tokens for each node | `256` |
| `cluster.datacenter` | Datacenter name | `dc1` |
| `persistence.size` | PVC Storage Request for Cassandra data volume | `8Gi` |
| `persistence.commitLogsize` | PVC Storage Request for Cassandra commit log volume. Unset by default | `2Gi` |
| `persistence.mountPath` | The path the data volume will be mounted at | `/bitnami/cassandra` |
| `persistence.commitLogMountPath` | The path the commit log volume will be mounted at. Unset by default. Set it to '/bitnami/cassandra/commitlog' to enable a separate commit log volume | `""` |
| `volumePermissions.image.digest` | Init container volume image digest in the way sha256:aa.... Please note this parameter, if set, will override the tag | `""` |
| `metrics.readinessProbe.periodSeconds` | Period seconds for readinessProbe | `10` |
| `metrics.readinessProbe.timeoutSeconds` | Timeout seconds for readinessProbe | `45` |
| `metrics.readinessProbe.failureThreshold` | Failure threshold for readinessProbe | `3` |
| `metrics.readinessProbe.successThreshold` | Success threshold for readinessProbe | `1` |
| `metrics.extraVolumeMounts` | Optionally specify extra list of additional volumeMounts for cassandra-exporter container | `[]` |
| `metrics.podAnnotations` | Metrics exporter pod Annotation and Labels | `{}` |
| `metrics.serviceMonitor.enabled` | If `true`, creates a Prometheus Operator ServiceMonitor (also requires `metrics.enabled` to be `true`) | `false` |
| `metrics.serviceMonitor.namespace` | Namespace in which Prometheus is running | `monitoring` |
| `metrics.serviceMonitor.interval` | Interval at which metrics should be scraped. | `""` |
| `metrics.serviceMonitor.scrapeTimeout` | Timeout after which the scrape is ended | `""` |
| `tls.internodeEncryption` | Set internode encryption | `none` |
| `tls.clientEncryption` | Set client-server encryption | `false` |
| `tls.autoGenerated` | Generate automatically self-signed TLS certificates. Currently only supports PEM certificates | `false` |
| `tls.existingSecret` | Existing secret that contains Cassandra Keystore and truststore | `""` |
| `tls.passwordsSecret` | Secret containing the Keystore and Truststore passwords if needed | `""` |
| `tls.keystorePassword` | Password for the keystore, if needed. | `""` |
| `tls.truststorePassword` | Password for the truststore, if needed. | `""` |
| `tls.resources.limits` | The resources limits for the TLS init container | `{}` |
| `tls.resources.requests` | The requested resources for the TLS init container | `{}` |
| `tls.certificatesSecret` | Secret with the TLS certificates. | `""` |
| `tls.tlsEncryptionSecretName` | Secret with the encryption of the TLS certificates | `""` |
The above parameters map to the env variables defined in [bitnami/cassandra](https://github.com/bitnami/containers/tree/main/bitnami/cassandra). For more information please refer to the [bitnami/cassandra](https://github.com/bitnami/containers/tree/main/bitnami/cassandra) image documentation.
Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example,
> **Tip**: You can use the default [values.yaml](values.yaml)
## Configuration and installation details
### [Rolling vs Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
### Enable TLS
This chart supports TLS between client and server and between nodes, as explained below:
* For internode cluster encryption, set the `tls.internodeEncryption` chart parameter to a value different from `none`. Available values are `all`, `dc` or `rack`.
* For client-server encryption, set the `tls.clientEncryption` chart parameter to `true`.
In both cases, it is also necessary to create a secret containing the keystore and truststore certificates and their corresponding protection passwords. This secret is to be passed to the chart via the `tls.existingSecret` parameter at deployment-time.
Refer to the chart documentation for more [information on creating the secret and a TLS deployment example](https://docs.bitnami.com/kubernetes/infrastructure/cassandra/administration/enable-tls/).
### Use a custom configuration file
This chart also supports mounting custom configuration file(s) for Apache Cassandra. This is achieved by setting the `existingConfiguration` parameter with the name of a ConfigMap that includes the custom configuration file(s).
> NOTE: This ConfigMap will override other Apache Cassandra configuration variables set in the chart.
Refer to the chart documentation for more [information on customizing an Apache Cassandra deployment](https://docs.bitnami.com/kubernetes/infrastructure/cassandra/configuration/customize-new-instance/).
### Initialize the database
The [Bitnami Apache Cassandra image](https://github.com/bitnami/containers/tree/main/bitnami/cassandra) image supports the use of custom scripts to initialize a fresh instance. This may be done by creating a Kubernetes ConfigMap that includes the necessary *sh* or *cql* scripts and passing this ConfigMap to the chart via the *initDBConfigMap* parameter.
Refer to the chart documentation for more [information on customizing an Apache Cassandra deployment](https://docs.bitnami.com/kubernetes/infrastructure/cassandra/configuration/customize-new-instance/).
### Set pod affinity
This chart allows you to set custom pod affinity using the `XXX.affinity` parameter(s). Find more information about pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
As an alternative, you can use the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters.
## Persistence
The [Bitnami Apache Cassandra](https://github.com/bitnami/containers/tree/main/bitnami/cassandra) image stores the Apache Cassandra data at the `/bitnami/cassandra` path of the container.
Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, and minikube.
See the [Parameters](#parameters) section to configure the PVC or to disable persistence.
If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/).
### Adjust permissions of persistent volume mountpoint
As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. There are two approaches to achieve this:
* Use Kubernetes SecurityContexts by setting the `podSecurityContext.enabled` and `containerSecurityContext.enabled` to `true`. This option is enabled by default in the chart. However, this feature does not work in all Kubernetes distributions.
* Use an init container to change the ownership of the volume before mounting it in the final destination. Enable this container by setting the `volumePermissions.enabled` parameter to `true`.
## Backup and restore
Refer to our detailed tutorial on [backing up and restoring Bitnami Apache Cassandra deployments on Kubernetes](https://docs.bitnami.com/tutorials/backup-restore-data-cassandra-kubernetes/).
## Troubleshooting
Find more information about how to deal with common errors related to Bitnami's Helm charts in [this troubleshooting guide](https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues).
## Upgrading
It's necessary to set the `dbUser.password` parameter when upgrading for readiness/liveness probes to work properly. When you install this chart for the first time, some notes will be displayed providing the credentials you must use. Please note down the password and run the command below to upgrade your chart:
| Note: you need to substitute the placeholder _[PASSWORD]_ with the value obtained in the installation notes.
### To 9.0.0
This major release renames several values in this chart and adds missing features, in order to be inline with the rest of assets in the Bitnami charts repository.
Affected values:
-`serviceMonitor.labels` renamed as `serviceMonitor.selector`.
-`service.port` renamed as `service.ports.cql`.
-`service.metricsPort` renamed as `service.ports.metrics`.
-`service.nodePort` renamed as `service.nodePorts.cql`.
-`updateStrategy` changed from String type (previously default to 'rollingUpdate') to Object type, allowing users to configure other updateStrategy parameters, similar to other charts.
- Removed value `rollingUpdatePartition`, now configured using `updateStrategy` setting `updateStrategy.rollingUpdate.partition`.
### To 8.0.0
Cassandra's version was bumped to `4.0`, [the new major](https://cassandra.apache.org/_/blog/Apache-Cassandra-4.0-is-Here.html) considered LTS. Among other features, this release removes support for [Thrift](https://issues.apache.org/jira/browse/CASSANDRA-11115), which means that the following properties of the chart will no longer be available:
-`cluster.enableRPC`
-`service.thriftPort`
-`service.nodePorts.thrift`
-`containerPorts.thrift`
For this version, there have been [intensive efforts](https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans) from Apache to ensure that a safe cluster upgrade can be performed. Nevertheless, a backup creation prior to undergoing the upgrade process is recommended. Please, refer to the [official guide](https://cassandra.apache.org/doc/latest/operating/backups.html#snapshots) for further information.
### To 7.0.0
[On November 13, 2020, Helm v2 support was formally finished](https://github.com/helm/charts#status-of-the-project), this major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm v3 and to be consistent with the Helm project itself regarding the Helm v2 EOL.
[Learn more about this change and related upgrade considerations](https://docs.bitnami.com/kubernetes/infrastructure/cassandra/administration/upgrade-helm3/).
### To 6.0.0
- Several parameters were renamed or disappeared in favor of new ones on this major version:
-`securityContext.*` is deprecated in favor of `podSecurityContext` and `containerSecurityContext`.
- Parameters prefixed with `statefulset.` were renamed removing the prefix. E.g. `statefulset.rollingUpdatePartition` -> renamed to `rollingUpdatePartition`.
-`cluster.replicaCount` is renamed to `replicaCount`.
-`cluster.domain` is renamed to `clusterDomain`.
- Chart labels were adapted to follow the [Helm charts standard labels](https://helm.sh/docs/chart_best_practices/labels/#standard-labels).
- This version also introduces `bitnami/common`, a [library chart](https://helm.sh/docs/topics/library_charts/#helm) as a dependency. More documentation about this new utility could be found [here](https://github.com/bitnami/charts/tree/main/bitnami/common#bitnami-common-library-chart). Please, make sure that you have updated the chart dependencies before executing any upgrade.
Consequences:
- Backwards compatibility is not guaranteed. To upgrade to `6.0.0`, install a new release of the Cassandra chart, and migrate the data from your previous release. To do so, create an snapshot of the database, and restore it on the new database. Check [this guide](https://cassandra.apache.org/doc/latest/operating/backups.html#snapshots) for more information.
### To 5.4.0
The `minimumAvailable` option has been renamed to `minAvailable` for consistency with other charts. This is not a breaking change as `minimumAvailable` never worked before because of an error in chart templates.
### To 5.0.0
An issue in StatefulSet manifest of the 4.x chart series rendered chart upgrades to be broken. The 5.0.0 series fixes this issue. To upgrade to the 5.x series you need to manually delete the Cassandra StatefulSet before executing the `helm upgrade` command.
