K8s中ClusterIP服务请求至Pod的路由机制及调度逻辑咨询

核心转发组件：kube-proxy #

你提到的负责流量分发的组件是kube-proxy，它运行在集群的每个节点上，并非DNS。DNS仅负责将服务名解析为该服务的ClusterIP，真正实现流量转发到后端Pod的是kube-proxy：

• 它会监听Kubernetes API Server，同步Service和Endpoint的变化（比如Pod的创建/销毁）
• 在节点上维护iptables或IPVS规则，将发往ClusterIP的流量转发到健康的后端Pod

目标Pod的选择逻辑（负载均衡策略） #

kube-proxy支持多种流量分发策略，默认及常用的有：

• 轮询（Round Robin）：默认策略，对每个新请求按顺序依次分配给后端Pod，实现基础的负载均衡
• 客户端IP会话保持：如果在Service的spec中配置sessionAffinity: ClientIP，来自同一客户端IP的请求会被转发到同一个Pod，可通过sessionAffinityConfig.clientIP.timeoutSeconds设置会话超时时间（默认10800秒）
• IPVS模式扩展策略：如果集群使用IPVS模式的kube-proxy（AKS可配置），还支持最少连接（Least Connections）、加权轮询等更灵活的策略

DNS的实际角色澄清 #

你之前对DNS的理解有偏差：DNS不会直接将服务名映射到某个Pod的IP，它只会返回服务的ClusterIP。当Ingress控制器这类客户端发起请求时，先通过DNS拿到ClusterIP，再将请求发往该IP，之后由节点上的kube-proxy规则完成到具体Pod的转发。

AKS+Calico环境的补充说明 #

Calico作为CNI插件，仅负责Pod之间的网络连通性、网络策略管控，不参与Service的流量转发和负载均衡逻辑，这部分依然由kube-proxy主导。在AKS中，kube-proxy默认使用iptables模式，若集群规模较大（比如节点数超过50），可切换为IPVS模式以提升性能。

官方文档核心参考要点 #

• Kubernetes官方文档：Service的负载转发由kube-proxy实现，支持iptables/IPVS两种运行模式，默认采用轮询策略，可配置会话保持来绑定客户端到特定Pod
• AKS官方文档：AKS集群默认使用iptables模式的kube-proxy，可根据集群规模调整为IPVS；Calico作为CNI仅负责Pod网络层面的管理，不干预Service的流量分发逻辑

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