HTTP2/GRPC场景下Ingress网关的HA与水平扩缩容管理及网关代理自身负载均衡方案咨询

你的理解完全到位——K8s Service确实是L4层基于连接的负载均衡，对于HTTP2/GRPC这种天生用长连接多路复用的场景来说，单条连接里会塞N多请求，这时候L4的负载均衡就会“偏心”：一旦某个连接绑定到了某一个网关Pod，后续所有请求都会走这个Pod，导致其他网关Pod闲得慌，负载严重不均。下面就给你梳理几种解决网关自身请求级负载均衡的靠谱方案，顺便说下HA和扩缩容的配套配置：

一、优先用云厂商的L7原生负载均衡器（最省心） #

如果你的集群跑在公有云上，直接用云厂商提供的L7级负载均衡器就行。这些云原生LB都原生支持HTTP2/GRPC协议，并且能做到请求级的负载均衡——哪怕是同一条长连接里的多个GRPC请求，也能被拆分开分发到不同的网关Pod。

配置起来也简单：

• 要么用云厂商的专属Ingress Controller，直接配置Ingress资源指向你的网关Pod，Controller会自动创建并配置好L7 LB；
• 要么把网关的Service改成NodePort类型，然后让云LB直接挂载集群节点的NodePort，再在LB上启用HTTP2/GRPC协议支持和请求均衡策略。

二、自建集群？用服务网格的网关能力 #

如果你是自建K8s集群，用Istio、Linkerd这类服务网格的话，它们的Ingress Gateway本身就针对HTTP2/GRPC做了优化：

• 网格的控制平面会自动感知网关Pod的扩缩容，实时更新流量分发规则；
• 你可以通过DestinationRule配置请求级的负载均衡策略，比如按LEAST_REQUEST（最少请求优先）或者ROUND_ROBIN轮询，让网关层面把请求均匀打到多个Pod上；
• 另外，还能配置连接池限制，比如给每个网关Pod设置最大并发请求数，当达到阈值时，新请求会自动分流到其他空闲的Pod，避免单个Pod过载。

举个简单的Istio配置示例：

# DestinationRule 配置网关的负载均衡策略
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ingress-gateway-dr
spec:
  host: istio-ingressgateway.istio-system.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      http2:
        maxRequests: 1000  # 每个Pod最大并发请求数

三、用支持L7请求均衡的开源代理补全能力 #

如果你用的是NGINX这类开源Ingress Controller，开源版默认是基于连接的均衡，但可以在网关前面再加一层NGINX Plus（商业版）或者Envoy作为入口代理：

• NGINX Plus支持HTTP2/GRPC的请求级负载均衡，能把同一条长连接里的多个请求拆分，分发到不同的网关Pod；
• Envoy作为L7代理也可以通过配置http_connection_manager和load_balancer来实现请求级均衡，完全适配HTTP2/GRPC场景。

最后补全HA与自动扩缩容的配置 #

除了负载均衡，网关的HA和自动扩缩容也得跟上：

• 反亲和性配置：给网关Pod加PodAntiAffinity，让K8s把Pod调度到不同的节点上，避免单个节点挂了导致全网关故障：

  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - ingress-gateway
        topologyKey: "kubernetes.io/hostname"
  

• HPA自动扩缩容：基于CPU、内存，或者自定义指标（比如GRPC请求QPS、延迟）配置HPA，让K8s根据流量自动增减网关Pod数量：

  apiVersion: autoscaling/v2
  kind: HorizontalPodAutoscaler
  metadata:
    name: ingress-gateway-hpa
  spec:
    scaleTargetRef:
      apiVersion: apps/v1
      kind: Deployment
      name: ingress-gateway
    minReplicas: 2
    maxReplicas: 10
    metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: grpc_requests_per_second
        target:
          type: AverageValue
          averageValue: 1000m
  

备注：内容来源于stack exchange，提问作者Vipin Menon