Kubernetes StatefulSets部署Solr Cloud滚动更新写入报错求方案

我来帮你拆解下这个问题——Solr Cloud在K8s StatefulSet滚动更新时，leader节点切换的窗口期确实容易触发写入报错，哪怕你已经尝试了preStop钩子转移leader，可能还是有细节没做到位。下面是几个经过验证的可行方案，你可以结合自己的集群情况尝试：

1. 优化PreStop钩子的Leader转移逻辑 #

你用了preStop但没解决问题，大概率是钩子的执行逻辑不够严谨：

• 别用“重新平衡”这种笼统操作，直接执行明确的Leader转移命令：针对每个集合，调用Solr API把当前leader转移到其他可用节点，比如：

  # 先调整leader选举等待时间，避免选举超时
  curl -X POST 'http://<solr-service-name>:8983/solr/admin/collections?action=CLUSTERPROP&name=leaderVoteWait&value=5000'
  # 针对指定集合转移leader到目标节点（先通过Solr API获取可用节点ID）
  curl -X POST 'http://<solr-service-name>:8983/solr/admin/collections?action=REASSIGNLEADER&collection=your-collection-name&targetNode=solr-1:8983_solr'
  

• 转移命令执行后一定要加足够的等待时间，比如sleep 20，给集群足够时间完成leader选举、同步状态，也让客户端有机会刷新集群路由信息，别让K8s急着kill pod。
• 检查钩子的执行权限，确保pod里的进程能正常访问Solr内部API，比如有没有网络策略限制，或者Solr的安全配置拦截了请求。

2. 调整StatefulSet的滚动更新策略 #

StatefulSet默认的更新顺序可能刚好撞到leader节点，调整策略能降低风险：

• 用partition字段分批更新：先通过Solr API找到当前leader对应的pod序号（比如solr-0是leader），然后设置spec.updateStrategy.rollingUpdate.partition=1，这样K8s会先更新序号≥1的非leader节点，等这些节点更新完成、集群稳定后，再把partition设为0更新leader节点。
• 延长terminationGracePeriodSeconds，比如设为60秒，给preStop钩子、leader转移、客户端状态刷新留出更充足的缓冲时间，避免强制终止导致的连接中断。

3. 增强SolrCloudClient的重试与容错 #

Java的SolrCloudClient默认的容错配置可能没覆盖leader切换的场景：

• 配置针对性的重试策略：开启对LeaderNotFoundException、SolrServerException这类写入相关异常的重试，设置3-5次重试次数，每次间隔1-2秒递增，避免在窗口期直接抛出错误。
• 缩短集群状态刷新间隔：通过代码调整客户端的ZK状态刷新频率，比如：

  solrCloudClient.getZkStateReader().setUpdateIntervalMillis(3000); // 每3秒刷新一次集群状态
  

  让客户端更快感知到leader节点的变化，及时调整路由。
• 在写入业务代码里加异常捕获与延迟重试：针对写入请求，捕获特定异常后先短暂延迟（比如500ms）再重试，绕过leader切换的最混乱窗口期。

4. 提前触发Leader转移，主动避开更新窗口期 #

在执行StatefulSet更新前，手动先把leader移走：

• 写个简单的shell脚本，先调用Solr API查询当前leader节点，然后触发转移命令，等集群状态显示新leader正常运行后，再执行kubectl rollout restart statefulset/your-solr-ss。
• 如果是CI/CD部署，把这个步骤集成到流水线里，作为更新前的前置检查动作，完全避开leader节点在更新时被终止的情况。

5. 改用Solr Operator简化部署管理 #

如果你的集群允许，试试Solr官方的Solr Operator，它内置了针对Solr Cloud的滚动更新优化：

• Operator会自动识别leader节点，优先更新非leader节点；更新leader节点前，会自动触发leader转移，并等待集群状态稳定后再继续更新，完全不用手动写preStop钩子或者调整更新策略。

这些方案可以组合使用，比如先优化preStop钩子和终止等待时间，再增强客户端的重试机制，基本能覆盖大部分场景的写入报错问题。

内容的提问来源于stack exchange，提问作者Bruno René Santos