你试图创建一个HTTP Liveness探针来检查你的WordPress容器的状态，但是你得到了一个非常奇怪的连接拒绝错误。
你得到的东西是这样的。
Warning Unhealthy 3m46s (x4 over 4m56s) kubelet Liveness probe failed: Get "http://10.28.1.25:80/": dial tcp 10.28.1.25:80: connect: connection refused
Warning Unhealthy 3m46s (x8 over 4m56s) kubelet Readiness probe failed: Get "http://10.28.1.25:80/": dial tcp 10.28.1.25:80: connect: connection refused
Warning BackOff 13s (x10 over 2m57s) kubelet Back-off restarting failed container
它说连接被拒绝，而你真的很困惑，因为你确信WordPress的Apache服务器是在80端口上监听的。
你确实是最正确的。
但实际上，正在发生的事情，是与WordPress正在将有效性探针重定向到规范域（你真正的网站域名）这一事实有关的，因为你在做请求时没有使用规范域。WordPress不喜欢这样，并试图将你重定向到真正的域名。在容器中，很可能重定向会以拒绝连接的方式失败。
修复方法是添加一个X-Forwarded-Host and Host头，以确保Apache服务器不会试图将失效探针重定向到规范域。
下面是有效性HTTP探针的httpGet部分应该是这样的。
livenessProbe:
请注意，这个httpGet的配置也适用于Readiness和Startup探测器。
在你的有效性探针中得到一个超时异常
还有一件事会让你措手不及。如果你的WordPress容器太慢，Kubernetes的有效性探测可能会失败。
你可能会看到这样的错误。
Warning Unhealthy 2m29s kubelet Readiness probe failed: Get "http://10.28.2.11:80/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
默认情况下，有效性探针的timeoutInSeconds设置为1s。这可能没有足够的时间让你的WordPress容器做出反应，kubelet可能最终会多次重启你的WordPress容器。这当然只会使问题恶化，因为越多的容器试图重启，对资源的竞争就越大。而更多的容器也可能因此而失败。
一个明显的解决方案是将timeoutInSeconds的值增加到一个足够高的值，这样你的liveness探针就会随机出现。或者/而且你可以增加failationThreshold，以确保一两个异常值不会因为反应慢而立即重新启动容器。
如果你只关心确保你的WordPress容器在重新部署后可以接收请求，那么你可能想使用一个启动探测。
下面是我为我的wordpress容器创建的一个启动探测器的例子。
startupProbe:
资源。
Kubernetes的准备性、有效性和启动探针文档
kubernetes.io/docs/tasks/…
我在Stackoverflow的帖子中找到了这个解决方案：
stackoverflow.com/questions/5…
