关于AKS中ClusterIP Service内部负载均衡及Ingress场景的技术问询

好问题！我来一步步给你把这个事儿说清楚：

1. ClusterIP Service本身就会对关联Pod做负载均衡 #

ClusterIP类型的Service是Kubernetes里最基础的服务暴露方式，它的核心职责之一就是在关联的后端Pod之间做流量负载均衡——不管有没有Ingress，这个能力都是内置的。只要你的Service正确关联了多个同标签的Pod，流量到Service之后就会被分发到这些Pod上。

2. 即使通过Ingress转发，Service依然会执行负载均衡 #

针对你说的场景：Ingress Controller把/svcA的请求转发到Service A，/svcB转发到Service B，这时候Service的负载均衡逻辑完全不受影响。因为Ingress Controller本质上也是集群内的一个Pod，它向Service发起请求的过程，和集群里其他Pod调用Service的逻辑是一样的。

3. 负载均衡的执行者是kube-proxy #

当Service A的Pod1处于繁忙状态（只要Pod1还在Service的端点列表里，也就是状态健康），请求会被分发到Pod2或Pod3，这个分发动作是由kube-proxy组件完成的：

• kube-proxy在AKS集群的每个节点上都有运行，它会监听Kubernetes API里的Service和Endpoint变化，然后在节点上通过iptables或者IPVS（AKS默认会根据集群规模选择合适的机制）来配置路由规则。
• 默认情况下，kube-proxy会用轮询算法来分发流量，你也可以通过Service的sessionAffinity字段配置会话保持，或者修改算法（比如IPVS支持更多算法）。
• 另外，如果某个Pod因为故障或者资源耗尽被标记为不健康，kube-proxy会自动把它从Service的端点列表中移除，不会再把流量发过去。

举个实际流程的例子：

1. 用户请求打到Ingress Controller的外部IP，路径是/svcA；
2. Ingress Controller根据规则，把请求转发到Service A的ClusterIP；
3. 节点上的kube-proxy识别到这个ClusterIP的流量，按照负载均衡规则，把请求转发到Pod1、Pod2、Pod3中的一个（比如轮询到Pod2，如果Pod1繁忙但还健康，下次可能轮到Pod3）；
4. 目标Pod处理请求后，把响应原路返回。

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