K8S中HTTP(L7)严格轮询负载均衡实现方案咨询

方案一：用NGINX Ingress Controller替换K8S Service的负载均衡层 #

直接在K8S集群里部署NGINX Ingress Controller，把它配置成请求级的严格轮询，同时调整流量路径，砍掉冗余层级：

• 新的流量路径变成：Route53 => ALB => NGINX Ingress Controller（NodePort或LoadBalancer类型的Service） => Pod
• 配置的时候，在Ingress资源的annotations里加这俩参数：
  • nginx.ingress.kubernetes.io/load-balance: "round_robin" —— 启用NGINX的请求级轮询策略
  • nginx.ingress.kubernetes.io/affinity: "none" —— 关闭会话保持，确保每个请求都按轮询分配
• 核心优势：
  • 干掉了原来路径里K8S Service那个连接级的负载均衡，直接由NGINX Ingress做请求级轮询，完全符合“不受TCP连接影响”的要求
  • 不用额外加独立的Nginx层，Ingress Controller本身就是K8S的标准组件，整合性好，网络跳点比你最初设想的方案少很多
  • NGINX的round_robin天生就是按请求轮的，哪怕同一个TCP连接里的多个请求，也会挨个分配到不同Pod，完美匹配你的取模逻辑

方案二：IPVS模式的K8S Service（不推荐，满足不了需求） #

K8S Service默认是iptables模式，按连接分配；换成IPVS模式的话，IPVS支持rr轮询策略，但它本质还是连接级的——同一个TCP连接里的所有请求都会到同一个Pod，根本满足不了“不管连接是否相同都严格轮询”的要求，所以这个方案直接pass，仅作参考。

方案三：自定义轻量代理（适合特殊场景） #

要是你不想用Ingress Controller，也可以自己写个简单的HTTP代理（比如用Go写几行代码），部署在集群入口处，或者给每个Pod加Sidecar——这个代理维护一个Pod列表的计数器，每个请求来的时候就按计数器取模分配到对应Pod。

• 好处是逻辑完全自己说了算，灵活；但坏处是得自己开发维护，不如成熟的Ingress Controller靠谱，除非你有特殊需求，否则不推荐。

总结 #

优先选方案一，理由很实在：

1. 用的是成熟开源组件，稳定靠谱，不用自己造轮子
2. 完美整合到K8S生态里，部署维护都方便
3. 砍掉了原架构里冗余的Service负载均衡层，网络路径更短，性能损失可以忽略
4. 配置简单，加俩annotations就搞定，不用复杂的定制开发

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