如何检查Kubernetes集群中运行Sidekiq的Docker镜像健康状态？

我来分享几个在Kubernetes环境里给Sidekiq容器做健康检查的靠谱方案，都是实际项目里验证过的实用技巧：

方案一：用Sidekiq Ruby API编写自定义检查脚本 #

这是最直接的方式，利用Sidekiq本身提供的Ruby API来验证Worker状态，不需要额外的HTTP服务，轻量高效。

1. 编写一个简单的检查脚本（比如check_sidekiq.rb）：

require 'sidekiq'

begin
  # 先验证Redis连接是否正常
  Sidekiq.redis { |conn| conn.ping }

  # 检查是否有活跃的Sidekiq Worker进程
  workers = Sidekiq::Workers.new
  if workers.empty?
    puts "No active Sidekiq workers found"
    exit 1
  end

  # 可选：检查关键队列是否有异常积压（比如超过100条任务）
  queue_size = Sidekiq::Queue.new('default').size
  if queue_size > 100
    puts "Default queue has #{queue_size} pending jobs (threshold exceeded)"
    exit 1
  end

  exit 0
rescue => e
  puts "Sidekiq health check failed: #{e.message}"
  exit 1
end

2. 将脚本添加到你的Docker镜像中（比如放在/app/bin/目录下），或者通过Kubernetes ConfigMap挂载进去。

3. 在Kubernetes的Deployment配置中配置探针：

livenessProbe:
  exec:
    command:
    - ruby
    - /app/bin/check_sidekiq.rb
  initialDelaySeconds: 10  # 给Sidekiq足够的启动时间
  periodSeconds: 30        # 每30秒检查一次
  failureThreshold: 2      # 失败2次后重启容器

readinessProbe:
  exec:
    command:
    - ruby
    - /app/bin/check_sidekiq.rb
  initialDelaySeconds: 5
  periodSeconds: 10

这个方案的优势是能直接验证Worker的活跃状态，还能根据业务需求扩展检查逻辑（比如特定队列的积压情况），完全贴合Sidekiq的运行机制。

方案二：利用Sidekiq Web UI的健康端点 #

如果你已经在使用Sidekiq Web UI（用来监控队列、任务状态），可以直接用它自带的健康检查端点，省去自定义脚本的麻烦。

1. 如果Sidekiq和Rails应用在同一个容器里，只需在Rails路由中挂载Sidekiq Web：

# config/routes.rb
require 'sidekiq/web'
mount Sidekiq::Web => '/sidekiq'

此时访问/sidekiq/health会返回200 OK（如果Sidekiq正常运行）。

2. 如果Sidekiq是单独的容器，可以启动一个轻量的Rack服务来暴露Web UI：

   • 编写一个config.ru文件：

     require 'sidekiq/web'
     run Sidekiq::Web
     

   • 在Dockerfile或Kubernetes命令中启动服务：

     bundle exec rackup -p 3001 config.ru
     

3. 配置Kubernetes的HTTP探针：

livenessProbe:
  httpGet:
    path: /sidekiq/health
    port: 3001  # 对应Rack服务的端口
  initialDelaySeconds: 15
  periodSeconds: 30

readinessProbe:
  httpGet:
    path: /sidekiq/health
    port: 3001
  initialDelaySeconds: 5
  periodSeconds: 10

这个方案的好处是既能做健康检查，又能通过Web UI直观监控Sidekiq状态，但需要额外占用一个端口，适合已经启用Web UI的场景。

方案三：轻量Redis连接+队列检查 #

如果你的场景不需要验证Worker活跃状态，只想确保Sidekiq能正常连接Redis、队列没有异常积压，可以用更简单的exec探针，直接调用redis-cli：

livenessProbe:
  exec:
    command:
    - redis-cli
    - ping  # 验证Redis连通性
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  exec:
    command:
    - sh
    - -c
    # 检查默认队列积压是否超过阈值（比如200条）
    - "redis-cli llen sidekiq:queue:default | awk '{exit ($1 > 200) ? 1 : 0}'"
  initialDelaySeconds: 5
  periodSeconds: 10

这个方案的优势是无需依赖Ruby环境，只要容器里有redis-cli就能用，适合极简场景，但无法直接验证Worker是否在处理任务，只能做基础连通性检查。

几个最佳实践提醒 #

• 区分liveness和readiness探针：liveness探针负责重启故障容器，readiness探针用来确认容器是否准备好处理任务（Sidekiq启动完成后再加入调度）。
• 调整初始延迟时间：根据Sidekiq的启动速度设置initialDelaySeconds，避免启动过程中误判为失败。
• 结合多种检查逻辑：比如在自定义脚本中同时验证Redis连接、Worker活跃状态和队列积压，让检查更全面。

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