ClickHouse Operator 中多分片集群Pod重建卡顿问题分析与解决

ClickHouse Operator 是一个用于在Kubernetes上管理ClickHouse集群的工具。近期在0.23.3版本中发现了一个关键问题：当集群设置超过2个分片和2个副本时（例如4分片2副本），在进行Pod资源变更操作时会出现卡顿现象。

问题现象

在特定设置的ClickHouse集群中，当执行以下操作时会出现异常：

1. 修改Pod资源限制（如CPU/内存）
2. 调整磁盘大小
3. 其他设置变更

操作会部分完成（通常处理4个Pod后），然后进入等待状态，直到达到reconcile.statefulSet.update.timeout设置的超时时间（默认30分钟）才会继续。这种问题在2分片2副本的设置下不会出现。

问题根源

经过深入分析，发现问题的核心原因在于：

1. 端口设置冲突：当用户自定义了非标准端口（如8124替代默认8123）但没有正确设置对应的Service模板时，会导致健康检查失败。

2. 并发处理限制：Operator在处理大规模集群时，默认的并发控制参数可能不足，特别是在reconcile.host.exclude设置为true时，等待主机从集群中排除的过程容易出现阻塞。

3. 健康检查机制：Liveness/Readiness探针依赖于默认端口设置，当端口变更后，健康检查会持续失败，导致Operator误判节点状态。

解决方案

推荐方案

升级到0.23.5版本，该版本已修复此问题。这是最直接有效的解决方法。

临时解决方案

如果暂时无法升级，可采用以下两种方法：

1. 手动干预：当Operator卡顿时，手动删除处于WAIT状态的Pod，触发Operator继续处理。

2. 设置调整：修改Operator设置，将reconcile.host.exclude设为false。但需要注意：

   • 这会跳过等待主机从集群排除的步骤
   • 可能影响集群数据一致性
   • 不建议在生产环境长期使用

正确设置建议

对于需要自定义端口的场景，必须同时设置Service模板：

templates:
  serviceTemplates:
    - name: svc-template
      spec:
        type: ClusterIP
        ports: 
          - name: http
            port: 8124
          - name: tcp
            port: 9001
          - name: interserver
            port: 9010
defaults:
  templates:
    replicaServiceTemplate: svc-template

最佳实践

1. 保持版本更新：及时升级到最新稳定版Operator
2. 谨慎修改默认端口：除非必要，否则建议使用默认端口设置
3. 完整设置：修改端口时确保Service、Pod模板同步更新
4. 监控超时设置：根据集群规模适当调整reconcile.statefulSet.update.timeout

总结

ClickHouse Operator在多分片集群中的卡顿问题主要源于健康检查机制和并发控制的不足。通过版本升级或合理设置可以解决此问题。对于生产环境，建议在变更前充分测试，并考虑集群规模对Operator性能的影响。

对于大规模ClickHouse集群管理，理解Operator的工作原理和设置细节至关重要，这能帮助运维人员快速定位和解决类似问题。