Kubernetes中运行Cassandra的节点故障恢复方案咨询

我来分享几个经过实践验证的可靠方案，帮你搞定Kubernetes里Cassandra StatefulSet故障Worker节点替换的问题——这个场景我之前处理过好几次，官方流程确实有点绕，下面的方法能帮你简化操作：

方案1：强制清理故障节点+重建Pod（最直接的应急方案） #

这个方案适合已经出现故障后的应急处理，核心是先把Cassandra集群里的故障节点信息移除，再让StatefulSet重建Pod：

• 第一步：清理集群内的故障节点信息
  先通过正常运行的Cassandra Pod查看集群状态，确认故障节点的ID：

  kubectl exec -it cassandra-0 nodetool status
  

  故障节点通常会显示DN（Down）状态，记下它的节点ID。如果故障节点已经完全离线，用decommission命令可能失效，这时候直接用removenode强制移除：

  kubectl exec -it cassandra-0 nodetool removenode <故障节点ID>
  

  等待集群完成数据平衡，再次用nodetool status确认故障节点已经被移除。
• 第二步：强制删除故障Pod和关联资源
  因为原Worker节点故障，对应的Pod可能卡在Terminating状态，需要强制删除：

  kubectl delete pod cassandra-2 --force --grace-period=0
  

  如果旧Pod的PVC还绑定在故障Worker的PV上，也可以删除PVC（如果PV是持久化的，数据会保留，新Pod启动后会同步数据）：

  kubectl delete pvc data-cassandra-2
  

• 第三步：等待StatefulSet重建Pod
  StatefulSet会自动在新的Worker节点上调度并创建新的Pod，这时候新Pod会以原来的节点身份加入集群（因为旧节点信息已经被清理），不会出现集群节点数变成4个的问题。

方案2：配置Cassandra使用稳定DNS标识（从根源避免IP依赖） #

这个是预防+解决的方案，让Cassandra节点用StatefulSet的DNS名称而非IP作为标识，这样即使Pod调度到新Worker节点，身份也不会变：

• 修改Cassandra的cassandra.yaml配置，把节点地址设置为Pod的FQDN（全限定域名）：

  listen_address: $(hostname -f)
  broadcast_address: $(hostname -f)
  rpc_address: 0.0.0.0
  broadcast_rpc_address: $(hostname -f)
  

  你可以通过ConfigMap挂载这个配置文件到Pod里，或者用环境变量注入的方式动态设置。
• 配置完成后，新Pod调度到新Worker节点时，会用cassandra-2.cassandra.default.svc.cluster.local这类稳定的DNS名称加入集群，Cassandra会识别出这是原来的节点，自动同步数据，不需要手动移除旧节点。

方案3：使用Cassandra Operator（长期运维最优解） #

如果你们经常需要管理Cassandra集群，建议用专门的Cassandra Operator（比如DataStax的Cassandra Operator），它能自动化处理大部分运维工作：

• Operator会自动检测故障的Worker节点，在新节点上调度新Pod，并且自动完成旧节点的移除、新节点的引导和数据同步，全程不需要手动执行nodetool命令。
• 它还能帮你管理Cassandra的配置更新、备份恢复、监控告警等，大大降低运维复杂度。

注意事项 #

• 操作前一定要先给Cassandra集群做快照备份，比如用nodetool snapshot命令，避免数据丢失。
• 执行removenode后，要等待集群完成数据重新平衡（可以用nodetool status查看所有节点状态是否为UN），再进行下一步操作。
• 确认StatefulSet的PV回收策略符合你的需求：如果需要保留数据，设置为Retain；如果可以自动清理，设置为Delete。

内容的提问来源于stack exchange，提问作者Kamil Szczygieł