Kubernetes服务加权路由：主从服务负载均衡方案咨询

首先，先戳中你遇到的核心痛点：ClusterIP服务是四层（TCP/UDP）负载均衡，默认采用「基于连接的轮询」策略。当master和某个slave Pod建立TCP连接后（HTTP/1.1默认会复用连接），如果这个连接上跑了一个长耗时请求，后续的短耗时请求也会复用这个连接发送到同一个Pod——本质是四层LB看不到HTTP请求层面的状态，只能死盯着连接做分发，才会出现「明明有空闲Pod，短请求却要等长请求」的尴尬情况。

接下来帮你把外部和内部HTTP负载均衡器的差异讲透，再结合你的场景给出明确推荐：

外部 vs 内部HTTP负载均衡器的核心差异 #

外部HTTP(S)负载均衡器 #

• 用途：专门用来把集群内的服务暴露给集群/VPC外部的用户或服务，比如互联网用户访问你的公开API
• 流量路径：外部客户端 → 云厂商的外部LB节点 → 集群节点 → Ingress控制器 → 后端服务
• 适用场景：对外提供服务的API、前端网站等需要跨VPC/互联网访问的场景

内部HTTP(S)负载均衡器 #

• 用途：仅在集群内部或同VPC内分发流量，完全隔离外部访问
• 流量路径：集群内服务（比如你的master） → 云厂商的内部LB节点 → Ingress控制器 → 后端slave服务
• 适用场景：集群内部服务间的通信、VPC内其他非K8s服务调用集群内服务

针对你场景的最优选择：内部HTTP负载均衡器 #

你的master和slave都是集群内部服务，完全不需要暴露到外部，内部HTTP LB完美适配你的需求，而且能直接解决当前的负载均衡问题：

1. 七层HTTP层面的智能分发：它能感知每个HTTP请求的状态，而不是只看TCP连接。即使master和某个slave Pod保持着长连接，新的请求会被分发到空闲的Pod，不会因为一个长耗时请求占住连接就把后续请求都塞到同一个Pod。
2. 更灵活的负载均衡策略：你可以配置基于请求数、Pod负载（比如CPU/内存使用率）的分发规则，替代固定轮询，进一步优化资源利用率。
3. 精细化流量控制：如果你的长短耗时请求有明确的路径区分（比如/api/long-task和/api/short-task），还能通过Ingress规则把它们分流到不同的slave Deployment组，让长短任务完全隔离，互不干扰。

具体落地建议（基于GKE，适配你使用Google PubSub的环境） #

1. 创建内部Ingress资源：
   在Ingress的yaml里添加注解，指定使用内部LB：

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: slave-internal-ingress
     annotations:
       kubernetes.io/ingress.class: "gce-internal"
       networking.gke.io/lb-scheme: "internal"
   spec:
     rules:
     - http:
         paths:
         - path: /api/*
           pathType: Prefix
           backend:
             service:
               name: slave-service
               port:
                 number: 80
   

2. 配置后端优化策略：
   通过BackendConfig资源给slave服务设置连接池、超时等，避免单个Pod被过多长请求占满：

   apiVersion: cloud.google.com/v1
   kind: BackendConfig
   metadata:
     name: slave-backend-config
   spec:
     connectionDraining:
       drainingTimeoutSec: 300
     sessionAffinity:
       affinityType: "NONE" # 禁用会话亲和性，让请求尽可能分发到空闲Pod
     timeoutSec: 3600 # 给长耗时请求设置足够长的超时
   

   然后把这个BackendConfig关联到你的slave Service：

   apiVersion: v1
   kind: Service
   metadata:
     name: slave-service
     annotations:
       cloud.google.com/backend-config: '{"default": "slave-backend-config"}'
   spec:
     type: ClusterIP
     ports:
     - port: 80
       targetPort: 8080
     selector:
       app: slave
   

3. 可选进阶：分流长短耗时请求：
   如果长短请求有明确的路径，拆分两个Deployment（比如slave-long和slave-short），然后在Ingress里配置不同路径指向不同服务，彻底隔离两类请求的负载。

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