GKE HTTPS负载均衡器健康检查使用哪个端口？

核心端口匹配规则 #

GKE健康检查使用的端口默认不直接取Service YAML中声明的service port字段，实际匹配逻辑分两类场景：

• 对LoadBalancer类型Service、Ingress转发对接的后端Service（即谷歌云外部/内部负载均衡关联的后端）：
  • 无自定义配置时，默认匹配Service中targetPort字段指向的Pod实际监听端口；如果targetPort配置的是命名端口，会自动匹配Pod定义中对应名称的containerPort
  • 注意service port是集群内访问Service的虚拟端口，仅用于集群内Service路由，不会作为负载均衡层健康检查的探测目标
• 对ClusterIP类型Service的集群内连通性检查：这类检查由kube-proxy在节点侧完成，不会直接探测业务容器的端口，和负载均衡层健康检查逻辑完全独立。

自定义配置的优先级 #

如果你通过GKE的BackendConfig资源、Service/Ingress上的健康检查注解显式指定了健康检查参数，配置中声明的端口优先级最高，会完全覆盖默认匹配规则，典型配置示例如下：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: svc-health-config
spec:
  healthCheck:
    checkIntervalSec: 10
    port: 8080 # 健康检查将直接探测该端口
    type: HTTP
    requestPath: /api/health

多端口Service场景下默认匹配逻辑很容易出错，建议这类场景始终显式指定健康检查端口，不要依赖默认规则。

后端不健康的常见排查点 #

• 先确认实际生效的健康检查配置：在云平台负载均衡的后端实例组详情页，查看对应后端绑定的健康检查规则，核对探测端口、协议、路径是否和后端服务实际提供的探测接口一致
• 检查访问控制规则：确认VPC防火墙、节点安全规则、Pod侧网络策略、业务自身的访问限制都放通了健康检查源地址的访问，没有拦截探测请求
• 核对Pod运行状态：查看Pod事件和运行日志，确认业务进程正常启动、指定端口已经处于监听状态；如果业务启动慢，可以适当调大健康检查的初始延迟参数，避免启动阶段的探测误判
• 核对Service端口映射：确认Service的targetPort和Pod的containerPort配置一致，没有出现端口映射写错导致流量和探测都打不到业务端口的问题

常见踩坑点：如果服务只支持HTTPS协议但健康检查配置成HTTP探测、健康检查路径默认用/但业务没有对根路径做200响应、容器监听在127.0.0.1而不是0.0.0.0，这三类问题占了健康检查失败场景的80%以上，可以优先核对。

内容的提问来源于stack exchange，提问作者Rabi