为何K8s集群内NodePort比Service Name通信速度更快？

• Service代理转发的额外开销：Service默认依赖kube-proxy通过iptables或IPVS实现流量转发，数据包会经过一层NAT/代理处理。如果两个Pod在同一节点，用NodePort访问时可直接走节点本地网络栈，跳过Service的代理环节，少了一层转发开销，速度自然更快。
• DNS解析的累积耗时：使用Service Name通信时，需要先通过CoreDNS解析出Service的ClusterIP，这个过程虽短，但大文件传输场景下，若涉及多次解析或解析延迟累积，会增加总耗时。而NodePort直接用节点IP+端口访问，无需DNS解析步骤，省掉了这部分时间。
• Service负载均衡的调度开销：Service的iptables模式基于连接匹配规则做负载均衡，规则量大会导致匹配耗时增加；IPVS模式虽更高效，但仍存在负载均衡调度的额外开销。而NodePort若直接访问所在节点的端口，相当于绕过了Service的负载均衡逻辑，直接与Pod通信，无这部分调度成本。
• 网络路径长度差异：同一节点内的Pod用NodePort通信时，路径是「源Pod → 节点本地网络 → 目标Pod」；而Service Name通信的路径是「源Pod → 节点网络 → Service代理（iptables/IPVS） → 目标Pod」，多了代理转发的步骤，路径更长，耗时更多。
• kube-proxy的性能瓶颈：若kube-proxy采用iptables模式，当集群内Service和Pod数量较多时，iptables规则会变得极为庞大，规则匹配的延迟会显著增加。NodePort的规则相对简单，或直接走本地转发，不存在这类性能瓶颈。

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