嗨，我尝试将自定义运行状况检查与 GCP 负载均衡器一起使用。
我添加了这样的readinessProbe和livenessProbe：
readinessProbe:
httpGet:
path: /health
port: dash
initialDelaySeconds: 5
periodSeconds: 1
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 10
livenessProbe:
httpGet:
path: /health
port: dash
initialDelaySeconds: 5
periodSeconds: 1
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 10
但是当我创建入口时，我还没有获得自定义运行状况检查
路径磅
我最终确定了一个答案。我试图做的事情是不可能的。我的GCE入口在端口80上使用后端。但是在我的准备中，我告诉他检查端口8080和/health路径。这是不可能的！
入口后端中声明的服务端口必须与readinessProbe中声明的端口相同。只有路径可以不同。如果我们不遵守此模式，则/与运行状况检查 GCP 路径相关联。
从网络的角度来看，这是合乎逻辑的，运行状况检查 GCP 在 Kube 集群中"退出"，如果我们告诉它在端口80上路由，但我们ReadinessProbe在另一个端口上，它如何确保即使与 RereadynessProbe 关联的端口遇到端口80(这是它必须路由流量的端口)也响应。
总之，入口中声明的后端端口必须在同一端口上具有readinessProbe。我们唯一可以自定义的是路径。
我认为您对 GCP 中的资源感到困惑。
您发布的代码与负载均衡器资源无关，因为它是针对 Pod 状态的 kubernetes 运行状况检查。如果您想知道探测器是否正常工作，请检查您的 pod 状态，如果它未运行，请描述您的 pod 并查看日志，应指示探测器存在问题。
我猜你在 kubernetes confch 的某个地方有一个入口资源，它会创建 lb 和围绕它的所有资源，比如健康检查(仍然猜测你发布的图像与此相关)。
如果您使用的是 GKE，您应该保持您部署的 k8s 配置中的 google 自动资源 conf，因为您可能会阻止 google 已经为您维护的一些东西。