TL;DR 是最后一段,但如果还不够清楚,其余部分可作为上下文。
我有一个运行 PHP 应用程序的 K8s pod。它分为 FPM 容器和 Nginx 容器。设置活性和就绪检查来检查容器进程。因此,对于 Nginx 来说,这仅仅意味着“端口 443 正在应答”,而对于 FPM 来说,这意味着“TCP 9000 正在应答吗?”。
我们已经在 PHP 应用程序中的
/readiness
和 /liveness
端点准备了更多智能探测器,但这些探测器适合在哪里使用?
当 pod 在单个容器中同时运行 Nginx 和 FPM 时,这一点是显而易见的,因为由于活性探针故障而重新启动单个容器是有意义的。对于 FPM 容器,我认为将其探针类型从
httpGet
更改为 command
可能是正确的做法,因为您可以运行命令来检查应用程序的状态。但感觉有些不对劲(主要是你不再检查主流程)。
我也许可以弄清楚您在哪里检查服务通过 FPM,但我想问的是:
当您的 Pod 带有 FPM 容器时,就绪性和活性探针的正确用法是什么?我应该询问应用程序本身是否感觉良好,还是应该从 FPM 获取所有信息来做出决定?
您需要询问 FPM 和申请。这些探针不适用于 Pod,它们是为每个容器独立配置的。 (虽然单个容器的就绪性探测失败会使整个 Pod 停止流量,但就绪性探测无论如何仍然适用于每个容器)
我很长一段时间都在试图为自己找出同样的事情。互联网上的很多帖子,甚至那些直接提到 Nginx + PHP-FPM 的帖子,对我来说都没有意义,所以我继续研究。
最后我想出了这个:
活性探针
正在使用
exec
和 cgi-fcgi
(来自 Ubuntu 上的 libfcgi-bin
软件包),看起来像这样
exec:
command:
- sh
- -c
- env --ignore-environment SCRIPT_NAME=/php-fpm-status SCRIPT_FILENAME=/php-fpm-status REQUEST_METHOD=GET cgi-fcgi -bind -connect localhost:9009
这里
env
用于避免向 PHP-FPM 传递任何意外的内容,/php-fpm-status
在池配置中使用 pm.status_path
和 pm.status_listen = 127.0.0.1:9009
进行配置。
来自PHP-FPM文档:
接受 FastCGI 状态请求的地址。这将创建一个新的不可见池,可以独立处理请求。如果主池忙于处理长时间运行的请求,这非常有用,因为在完成长时间运行的请求之前仍然可以获取 FPM 状态页面。
这使我们能够检查 PHP-FPM 和池是否处于活动状态,即使它真的很忙。
就绪探针
未定义。
严格来说 PHP-FPM 不直接接受网络连接,只能通过 Nginx 接受。所以我们将使用 Nginx 来检查准备情况。
活性探针
Liveness 探针是通过
httpGet
在 Nginx location
配置中使用这个特殊的 server
来实现的:
location = /probe-live {
allow 10.0.0.0/8;
allow 127.0.0.0/8;
allow 172.16.0.0/12;
allow 192.168.0.0/16;
deny all;
return 200 'alive';
}
就绪探针
Readiness 探针依赖于 PHP-FPM,在 Nginx 配置中看起来像这样:
# Readiness probe.
# Most of the time the application is ready to serve HTTP requests only when
# PHP-FPM is ready, so we are relying on PHP-FPM readiness probe here.
location = /probe-ready {
allow 10.0.0.0/8;
allow 127.0.0.0/8;
allow 172.16.0.0/12;
allow 192.168.0.0/16;
deny all;
fastcgi_param SCRIPT_NAME /probe-ready;
fastcgi_param SCRIPT_FILENAME /probe-ready;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_pass unix:/run/php-fpm.socket;
}
要使其正常工作,您的 PHP-FPM 池必须具有
ping.path = /probe-ready
。
探头本身是 httpGet
到 /probe-ready
。
我认为询问应用程序的感受不适合 Kubernetes 探针,因为这会给 Kubernetes 带来错误信号。这也是
kube-score
方法推荐的。请参阅https://github.com/zegl/kube-score/blob/master/README_PROBES.md#readinessprobe
您的应用程序应该能够处理它所依赖的服务的问题并将这些问题报告给请求者