Bitnami Apache Cassandra 软件包

Apache Cassandra 是一个开源分布式数据库管理系统，旨在跨多台服务器处理大量数据，提供高可用性且无单点故障。

Apache Cassandra 概述

商标说明：本软件列表由Bitnami打包。所提及的相应商标归各自公司所有，使用这些商标并不意味着任何关联或背书。

快速使用

console
helm install my-release oci://registry-1.docker.io/bitnamicharts/cassandra

希望在生产环境中使用Apache Cassandra？请尝试VMware Tanzu Application Catalog，即Bitnami目录的商业版本。

⚠️ 重要通知：Bitnami目录即将变更

自2025年8月28日起，Bitnami将升级其公共目录，在新的Bitnami Secure Images计划下提供精选的强化、安全聚焦镜像集。作为此过渡的一部分：

• 首次向社区用户提供流行容器镜像的安全优化版本访问权限。
• Bitnami将开始在其免费层级中弃用对非强化、基于Debian的软件镜像的支持，并将逐步从公共目录中移除非最新标签。因此，社区用户将只能访问数量减少的强化镜像，这些镜像仅以“latest”标签发布，适用于开发目的。
• 从8月28日开始，在两周内，所有现有容器镜像（包括旧版本或版本化标签，如2.50.0、10.6）将从公共目录（docker.io/bitnami）迁移到“Bitnami Legacy”仓库（docker.io/bitnamilegacy），且不再接收更新。
• 对于生产工作负载和长期支持，建议用户采用Bitnami Secure Images，包括强化容器、更小的***面、CVE透明度（通过VEX/KEV）、SBOM以及企业支持。

这些变更旨在通过推广软件供应链完整性和最新部署的最佳实践，提升所有Bitnami用户的安全态势。更多详情，请访问Bitnami Secure Images公告。

简介

本Chart使用Helm包管理器在Kubernetes集群上引导部署Apache Cassandra。

前提条件

• Kubernetes 1.23+
• Helm 3.8.0+
• 底层基础设施支持PV供应器

安装Chart

要使用发布名称my-release安装Chart：

console
helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/cassandra

注意：您需要将占位符REGISTRY_NAME和REPOSITORY_NAME替换为Helm Chart仓库和存储库的引用。例如，对于Bitnami，需使用REGISTRY_NAME=registry-1.docker.io和REPOSITORY_NAME=bitnamicharts。

这些命令以默认配置在Kubernetes集群上部署一个节点的Apache Cassandra。参数部分列出了可在安装过程中配置的参数。

提示：使用helm list列出所有发布版本

配置和安装详情

资源请求和限制

Bitnami Charts允许为Chart部署内的所有容器设置资源请求和限制，这些配置位于resources值中（参见参数表）。为生产工作负载设置请求至关重要，且应根据具体用例进行调整。

为简化此过程，Chart包含resourcesPreset值，可根据不同预设自动设置resources部分。有关这些预设，请查看bitnami/common chart。但在生产工作负载中，不建议使用resourcesPreset，因为它可能无法完全适应您的特定需求。有关容器资源管理的更多信息，请参阅***Kubernetes文档。

更新凭证

Bitnami Charts在首次启动时配置凭证。后续对密钥或凭证的任何更改都需要手动干预。请按照以下说明操作：

• 按照上游文档更新用户密码
• 使用新值更新密码密钥（替换SECRET_NAME和PASSWORD占位符）

shell
kubectl create secret generic SECRET_NAME --from-literal=cassandra-password=PASSWORD --dry-run -o yaml | kubectl apply -f -

滚动标签与不可变标签

强烈建议在生产环境中使用不可变标签。这可确保如果同一标签使用不同镜像更新，您的部署不会自动更改。

如果主容器有新版本、重大更改或严重漏洞，Bitnami将发布新Chart以更新其容器。

Prometheus监控指标

通过将metrics.enabled设置为true，本Chart可与Prometheus集成。这将在所有Pod中部署带有cassandra_exporter的边车容器，并通过Cassandra服务暴露指标。该服务将具有必要的注解，可被Prometheus自动抓取。

Prometheus要求

要使集成工作，需要安装Prometheus或Prometheus Operator。安装Bitnami Prometheus Helm Chart或Bitnami Kube Prometheus Helm Chart，可轻松在集群中部署可用的Prometheus。

与Prometheus Operator集成

本Chart可为与Prometheus Operator安装集成部署ServiceMonitor对象。为此，需将值metrics.serviceMonitor.enabled=true设置为true。确保集群中已安装Prometheus Operator CustomResourceDefinitions，否则将失败并显示以下错误：

text
no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"

安装Bitnami Kube Prometheus Helm Chart以获取必要的CRD和Prometheus Operator。

启用TLS

本Chart支持客户端与服务器之间以及节点之间的TLS，如下所述：

• 对于节点间集群加密，将tls.internodeEncryptionChart参数设置为非none的值。可用值为all、dc或rack。
• 对于客户端-服务器加密，将tls.clientEncryptionChart参数设置为true。

在这两种情况下，还需要创建包含密钥库和信任库证书及其相应保护密码的密钥，并在部署时通过tls.existingSecret参数将此密钥传递给Chart，如下所示：

text
tls.internodeEncryption=all
tls.clientEncryption=true
tls.existingSecret=my-exisiting-stores
tls.passwordsSecret=my-stores-password

提示：可使用--from-file=./keystore、--from-file=./truststore、--from-literal=keystore-password=KEYSTORE_PASSWORD和--from-literal=truststore-password=TRUSTSTORE_PASSWORD选项以标准方式创建密钥。假设存储库在当前工作目录中，且KEYSTORE_PASSWORD和TRUSTSTORE_PASSWORD占位符替换为正确的密钥库和信任库密码。示例：

console
kubectl create secret generic my-exisiting-stores --from-file=./keystore --from-file=./truststore
kubectl create secret generic my-stores-password --from-literal=keystore-password=KEYSTORE_PASSWORD --from-literal=truststore-password=TRUSTSTORE_PASSWORD

密钥库和信任库文件可从证书文件动态创建。在这种情况下，需要包含pem格式的tls.crt、tls.key和ca.crt的密钥。以下示例显示如何创建密钥，并假设所有证书文件都在工作目录中：

console
kubectl create secret tls my-certs --cert ./tls.crt --key ./tls.key
kubectl patch secret my-certs -p="{\"data\":{\"ca.crt\": \"$(cat ./ca.crt | base64 )\"}}"

要启用此功能，必须设置tls.autoGenerated，并将新密钥设置在tls.certificateSecret中：

text
tls.internodeEncryption=all
tls.clientEncryption=true
tls.autoGenerated=true
tls.certificatesSecret=my-certs
tls.passwordsSecret=my-stores-password

初始化数据库

Apache Cassandra镜像支持使用自定义脚本初始化新实例。可通过创建包含必要.sh或.cql脚本的Kubernetes ConfigMap，并通过initDBConfigMap参数将此ConfigMap传递给Chart来实现。

使用自定义配置文件

本Chart还支持挂载Apache Cassandra的自定义配置文件。通过将existingConfiguration参数设置为包含自定义配置文件的ConfigMap名称来实现。以下是使用存储在名为cassandra-configuration的ConfigMap中的自定义配置文件部署Chart的示例：

text
existingConfiguration=cassandra-configuration

注意：此ConfigMap将覆盖Chart中设置的其他Apache Cassandra配置变量。

备份和恢复

请参阅详细教程在Kubernetes上备份和恢复Bitnami Apache Cassandra部署。

设置Pod亲和性

本Chart允许使用XXX.affinity参数设置自定义Pod亲和性。有关Pod亲和性的更多信息，请参阅Kubernetes文档。

作为替代方案，您可以使用bitnami/commonChart中提供的Pod亲和性、Pod反亲和性和节点亲和性预设配置。为此，设置XXX.podAffinityPreset、XXX.podAntiAffinityPreset或XXX.nodeAffinityPreset参数。

持久化

Bitnami Apache Cassandra镜像将Apache Cassandra数据存储在容器的/bitnami/cassandra路径下。

持久卷声明（Persistent Volume Claims）用于跨部署保留数据。已知在GCE、AWS和minikube中有效。 请参阅参数部分配置PVC或禁用持久化。

如果在使用持久卷时遇到错误，请参阅持久卷故障排除指南。

调整持久卷挂载点的权限

由于镜像默认以非root用户运行，需要调整持久卷的所有权，以便容器可以写入数据。有两种方法可实现此目的：

• 通过将podSecurityContext.enabled和containerSecurityContext.enabled设置为true来使用Kubernetes SecurityContexts。此选项在Chart中默认启用。但并非所有Kubernetes发行版都支持此功能。
• 使用初始化容器在将卷挂载到最终目标之前更改卷的所有权。通过将volumePermissions.enabled参数设置为true启用此容器。

参数

全局参数

通用参数

Cassandra参数