基于Kubernetes的Cassandra一键部署、自动扩缩容及配置自动化问询

我来分享一下针对你需求的具体实现思路和步骤，分两部分来拆解：

因为你已经用StatefulSet搭了单节点，接下来要扩展成可一键扩缩容的多节点集群，核心是利用Kubernetes StatefulSet的特性+自动化工具来实现：

• 优化StatefulSet配置：

  • 把podManagementPolicy改成Parallel，默认是OrderedReady（串行创建/删除Pod），改成并行后扩缩容速度会快很多，适合多节点场景。
  • 配置Headless Service（必须），Cassandra依赖稳定的DNS标识来发现节点，Headless Service会给每个StatefulSet Pod分配固定的pod-name.service-name.namespace.svc.cluster.local格式的DNS记录。
  • 用PersistentVolumeClaim模板定义存储，确保每个节点有独立的持久化存储，同时配置动态存储类（StorageClass），让Kubernetes自动为新节点分配PV，不用手动创建。

• 实现一键扩缩容：

  • 推荐用Helm封装Cassandra部署：把StatefulSet、Service、ConfigMap等资源打包成Helm Chart，在values.yaml里定义replicaCount参数。这样一键部署可以用helm install cassandra ./cassandra-chart --set replicaCount=3，扩缩容只需执行helm upgrade cassandra ./cassandra-chart --set replicaCount=5（缩容同理）。
  • 如果你不想用Helm，也可以写个简单的Shell脚本，集成Kubectl命令和Cassandra节点操作：

    # 示例扩容脚本
    # 参数1：目标节点数
    target_replicas=$1
    kubectl scale statefulset cassandra --replicas=$target_replicas
    # 等待所有Pod就绪后，验证节点加入集群
    kubectl wait --for=condition=ready pod -l app=cassandra --timeout=5m
    kubectl exec cassandra-0 -- nodetool status
    

    缩容的时候要注意：Cassandra不能直接删除节点，必须先执行nodetool decommission把节点数据迁移走，所以脚本里要先找到要删除的节点（比如从当前副本数到目标副本数之间的节点），逐个执行decommission，再scale down：

    # 示例缩容脚本片段
    current_replicas=$(kubectl get statefulset cassandra -o jsonpath='{.spec.replicas}')
    target_replicas=$1
    for ((i=current_replicas-1; i>=target_replicas; i--)); do
      echo "Decommissioning cassandra-$i..."
      kubectl exec cassandra-$i -- nodetool decommission
      # 等待节点完成数据迁移
      sleep 60
    done
    kubectl scale statefulset cassandra --replicas=$target_replicas
    

  • 可选配置HPA（Horizontal Pod Autoscaler）：基于CPU/内存使用率，或者Cassandra自定义指标（比如pending compactions、读写延迟）实现自动扩缩容，这样不用手动触发，集群会根据负载自动调整节点数。

当代码仓库里的Cassandra配置变更时，用Jenkins实现自动部署，核心是Webhook触发流水线+滚动更新StatefulSet：

• 配置仓库Webhook：
  在GitHub或你的代码仓库中，添加Jenkins的Webhook地址（比如http://jenkins-url/github-webhook/），设置触发条件为“当配置文件（如cassandra.yaml、jvm.options、logback.xml等）变更时”，这样每次提交配置修改都会触发Jenkins流水线。

• 设计Jenkins流水线（Pipeline）：
  用Jenkinsfile定义流水线步骤，确保配置变更安全、可控：

  1. 拉取最新配置：用Git插件拉取仓库中的最新配置文件。
  2. 配置校验：先本地校验配置文件的语法正确性，避免错误配置上线。可以用Cassandra镜像来执行校验：

     docker run --rm -v $(pwd)/config:/config cassandra:latest cassandra -f /config/cassandra.yaml
     

     如果校验失败，流水线直接中止，避免部署错误。
  3. 更新配置存储：如果你的Cassandra配置是通过ConfigMap或Secret挂载的，先更新Kubernetes中的ConfigMap：

     kubectl create configmap cassandra-config --from-file=./config/cassandra.yaml --from-file=./config/jvm.options --dry-run=client -o yaml | kubectl apply -f -
     

  4. 触发StatefulSet滚动更新：因为ConfigMap更新后，Pod不会自动重启，需要手动触发滚动更新。可以通过修改Pod模板的annotation来触发：

     kubectl patch statefulset cassandra -p '{"spec":{"template":{"metadata":{"annotations":{"last-config-updated":"'$(date +%Y%m%d%H%M%S)'"}}}}}'
     

     Kubernetes会逐个重启Pod，每个Pod重启后会加载新的ConfigMap配置。
  5. 验证部署结果：每个Pod重启后，检查节点状态和配置是否生效：

     # 等待所有Pod就绪
     kubectl wait --for=condition=ready pod -l app=cassandra --timeout=10m
     # 随机选一个Pod验证配置是否加载
     kubectl exec $(kubectl get pods -l app=cassandra -o jsonpath='{.items[0].metadata.name}') -- cat /etc/cassandra/cassandra.yaml | grep "<your-updated-config-key>"
     # 检查Cassandra节点状态
     kubectl exec cassandra-0 -- nodetool status
     

• 特殊配置处理：
  有些Cassandra配置可以动态加载（比如部分cassandra.yaml参数），不需要重启Pod，这时候可以在Jenkins流水线中执行批量命令，直接更新集群配置：

  # 示例：动态修改read_request_timeout_in_ms参数
  kubectl exec cassandra-* -- nodetool setconfig read_request_timeout_in_ms 10000
  

  这种方式更高效，不用重启Pod，但要确认配置是否支持动态修改，可以参考Cassandra官方文档。

• 永远用ConfigMap/Secret管理配置，不要把配置硬编码到Docker镜像中，这样变更更灵活，也符合Kubernetes最佳实践。
• 配置监控：用Prometheus+Grafana监控Cassandra的节点状态、读写性能、存储使用情况，扩缩容和配置变更后能及时发现问题。
• 备份数据：在扩缩容或配置变更前，执行nodetool snapshot做数据快照，避免意外数据丢失。
• 灰度验证：如果集群规模大，可以先在一个节点上测试配置变更，确认没问题后再全量滚动更新。

内容的提问来源于stack exchange，提问作者user1860462