GKE 内部 TCP 负载均衡器的自定义运行状况检查配置
我需要通过内部负载均衡器公开 GKE 中的服务（服务可以自行终止 TLS）。
有明确指南如何操作那，除了一件事之外，一切都按预期进行。自动创建的 LB 在硬编码路径 /healthz 处配置了 HTTP 运行状况检查，但该服务在不同路径实现其运行状况检查。因此，负载均衡器永远不会“看到”支持实例组是健康的。
有没有办法向 GKE 中的内部 TCP 负载均衡器提供自定义运行状况检查配置？
仅用于上下文：我尝试遵循 配置入口功能（通过创建后端配置并相应地注释服务），但不幸的是这不适用于 TCP 负载平衡器（但如果我尝试使用入口资源部署 HTTP 负载平衡器，则可以）。
I need to expose a service in GKE via internal load-balancer (service can terminate TLS on its own).
There is a clear guideline how to do that, all works as expected except for one thing. The LB that gets automatically created is configured with HTTP health-check at hard-coded path /healthz, however the service implements its health-check at a different path. As a result the load-balancer never "sees" the backing instance-groups as healthy.
Is there a way to provide a custom health-check config to an internal TCP load-balancer in GKE?
Just for the context: I tried to follow the approach described in another guide on configuring ingress features (by creating a backend-config and annotating the service accordingly), but unfortunately that does not work for TCP load-balancer (while it does if I try to deploy HTTP load-balancer with an ingress resource).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，您可以修改现有的运行状况检查或定义新的运行状况检查。您可以使用 Cloud Console、Google Cloud CLI 或 REST API 创建运行状况检查。请参阅此文档，了解有关创建健康状况的详细信息检查TCP协议。
与代理负载均衡器不同，内部 TCP/UDP 负载均衡器不会终止来自客户端的连接，然后打开到后端的新连接。相反，内部 TCP/UDP 负载均衡器将连接直接从客户端路由到健康的后端，而不会造成任何中断。
健康的后端虚拟机。
不通过负载均衡器返回。 TCP 响应使用直接服务器
返回。
运行状况检查的协议不必与负载均衡器的协议匹配，无论您创建哪种运行状况检查类型，Google Cloud 都会将运行状况检查探测发送到内部 TCP/UDP 负载均衡器转发规则的 IP 地址，负载均衡器后端服务选择的 VPC 中的网络接口。
注意：内部 TCP/UDP 负载均衡器使用 健康检查状态以确定如何路由新连接，如流量分配。
内部 TCP/UDP 负载均衡器分配新连接的方式取决于您是否配置了故障转移：
至少在以下情况下将新连接分配到其健康的后端虚拟机
一台后端虚拟机运行状况良好。当所有后端虚拟机均不健康时，
负载均衡器在所有后端之间分配新连接
最后的手段。在这种情况下，负载均衡器会路由每个新的
连接到不健康的后端虚拟机。
根据活动池中的虚拟机之间分配新连接
您配置的故障转移策略。当所有后端虚拟机都已启动时
不健康，您可以选择以下行为之一
Yes, you can edit an existing health check or define a new one.You can create a health check using the Cloud Console, the Google Cloud CLI, or the REST APIs. Refer this documentation for more information on creating a health check with TCP protocol.
Unlike a proxy load balancer, an internal TCP/UDP load balancer doesn't terminate connections from clients and then open new connections to backends. Instead, an internal TCP/UDP load balancer routes connections directly from clients to the healthy backends, without any interruption.
healthy backend VMs.
not back through the load balancer. TCP responses use direct server
return.
The protocol of the health check does not have to match the protocol of the load balancer, Regardless of the type of health check that you create, Google Cloud sends health check probes to the IP address of the internal TCP/UDP load balancer's forwarding rule, to the network interface in the VPC selected by the load balancer's backend service.
Note : The internal TCP/UDP load balancers use health check status to determine how to route new connections, as described in Traffic distribution.
The way that an internal TCP/UDP load balancer distributes new connections depends on whether you have configured failover:
distributes new connections to its healthy backend VMs if at least
one backend VM is healthy. When all backend VMs are unhealthy, the
load balancer distributes new connections among all backends as a
last resort. In this situation, the load balancer routes each new
connection to an unhealthy backend VM.
distributes new connections among VMs in its active pool, according
to a failover policy that you configure. When all backend VMs are
unhealthy, you can choose from one of the following behaviors
我遇到了同样的问题，但我在官方 GKE 文档 负载均衡器健康检查
我希望您会发现它有帮助。
I have bumped into the same issue, but I found the answer in the official GKE documentation Load balancer health checks
I hope you will find it helpful.