Jumpserver 4.2.0 Celery 探针故障排查与解决方案

问题背景

在使用 Helm 安装 Jumpserver 4.2.0 社区版时，Celery 组件在运行一段时间后出现无法启动的情况。通过 Kubernetes 日志分析发现，问题根源在于 Celery 的探针检查失败，具体表现为 /tmp/worker_ready_celery 文件不存在或为空。

故障现象

1. Celery 容器持续重启，Kubernetes 事件显示 Readiness probe 失败
2. 检查探针文件 /tmp/worker_ready_celery 发现文件为空
3. 核心服务日志缺失，仅能观察到探针失败的信息

根本原因分析

经过深入排查，发现该问题实际上是由 Calico 网络组件异常导致的。Calico 作为 Kubernetes 的网络插件，负责集群内的网络通信。当 Calico 出现问题时，会导致以下连锁反应：

1. Celery 组件无法与 Redis 或数据库建立正常连接
2. 健康检查脚本无法正常执行
3. 探针文件无法生成或内容为空
4. Kubernetes 认为服务不健康，触发重启循环

解决方案

1. 检查 Calico 网络状态：

   • 确认 Calico 相关 Pod 是否正常运行
   • 检查节点间的网络连通性
   • 验证网络策略是否影响服务通信

2. 临时解决方案：

   • 重启 Calico 相关组件
   • 重启 Jumpserver 所有服务

3. 长期解决方案：

   • 监控 Calico 组件健康状态
   • 设置合理的网络资源限制
   • 定期检查网络插件日志

预防措施

1. 在部署 Jumpserver 前，确保 Kubernetes 网络插件运行正常
2. 为关键组件设置合理的资源请求和限制
3. 实现网络组件的监控告警机制
4. 定期检查集群网络性能指标

技术要点

1. Kubernetes 探针机制：

   • Readiness probe 用于确定容器是否准备好接收流量
   • 探针失败会导致服务从 Service 的 Endpoints 中移除

2. Celery 健康检查原理：

   • Jumpserver 使用 /tmp/worker_ready_celery 文件作为健康状态标识
   • 该文件由 Celery worker 在正常启动后创建

3. 网络问题的影响：

   • 网络异常会导致分布式组件间通信中断
   • 微服务架构对网络稳定性要求较高

总结

Jumpserver 作为开源堡垒机系统，其分布式架构依赖于稳定的网络环境。当出现组件异常时，应从底层基础设施开始排查，逐步向上分析。本例中看似是 Celery 的问题，实则根源在于网络组件异常。这种系统性的故障排查思路对于维护复杂的分布式系统至关重要。