dubbo 协议的 K8s pod 存活探针配置

背景

某项目采用微服务架构，dubbo 框架，K8s 方式部署。

其中 HTTP 协议由网关应用统一处理，大部分应用仅提供 dubbo 协议。

 

目标

应用某个实例(pod)状态异常时，尝试自动重启恢复。

 

解决

K8s 提供了3种存活探针(livenessProbe)，以实现 pod 状态异常时重启。

HTTPGetAction 首先排除了，因为上文我们说了，HTTP 访问由网关统一处理，应用本身没有 HTTP 协议。

然后是 TCPSocketAction，该探针仅能确认 dubbo 端口是否为监听状态，无法实现应用状态的的拨测。

最后是 ExecAction，该探针执行命令返回0判断 pod 存活，非0则根据pod定义的重启策略进行后续操作。

 

dubbo 框架从2.0.5 版本开始，支持通过 telnet 命令交互，我们可以使用 status 命令获取应用本身即应用依赖的底层服务(注册中心、数据库等)的拨测结果。

我们只需要编写一个简单的 shell 脚本，抓取 dubbo 的 status 命令结果，如果是 OK 或 WARN 则返回0，否则返回1，就可以使用 ExecAction 了。

#!/bin/bash

outputfile=/tmp/dubbo_health_check
dubbo_port=$1

(echo 'status -l'; sleep 1) | nc -w 3 127.0.0.1 ${dubbo_port} -o ${outputfile} > /dev/null

result=`grep summary ${outputfile}| awk '{print $4}' `

if [[ "${result}" == "OK" ]] || [[ "${result}" == "WARN" ]]
then
    exit 0
else
    exit 1
fi

 

pod yaml文件中关于存活探针的部分如下所示

#(略)
        livenessProbe:
          exec:
            command:
            - /bin/bash
            - /opt/dubbo_health_check.sh
            - '20800'
          initialDelaySeconds: 600
          timeoutSeconds: 5
          periodSeconds: 60
          failureThreshold: 3
#（略）

 

注意点

1. 按 dubbo 官方文档的说法，telnet 中执行 status 返回的结果应该和 status -l 中 summary 的结果一致，实际测试并非如此，建议使用 status -l 
2. 频繁执行 status -l 可能会有性能上的隐患，参考 https://www.jianshu.com/p/f6376c148f2c

  

总结

dubbo 官方提供了与 pod 探针对齐的方法(参见下文)，但是在我们这个应用中因为网关和其他一些原因限制了 HTTP 协议，因此使用了上文这种替代方案。

每个项目/团队都会有一些自己的特殊需求，本文只是提供一种思路，如果有更好的解决方案，欢迎在评论区提出讨论(●ˇ∀ˇ●)

  

参考

容器探针
https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

Dubbo 与 pod 探针对齐
https://dubbo.apache.org/zh/docs/references/lifecycle/brief/

Dubbo Telnet 命令
https://dubbo.apache.org/zh/docs/v3.0/references/telnet/#status