K8s外部客户端流量：应走Master还是Worker节点？相关疑问解析

先直接给你理清几个容易混淆的点，避免踩坑：

1. 外部业务流量应该走Worker节点，而非Master节点 #

这是绝对的原则，原因很简单：

• Master节点的核心角色是集群控制平面，它运行着kube-apiserver、etcd、controller-manager这些核心组件，负责集群的调度、状态存储、资源管理等关键工作。如果把业务流量引到Master，会挤占控制平面的CPU、内存和网络资源，轻则导致kubectl命令响应变慢、Pod调度延迟，重则直接引发集群故障。
• Worker节点才是专门为承载业务Pod设计的，它运行着kubelet、kube-proxy和CNI网络插件，天生就是用来处理业务流量转发的，资源也都是为业务负载预留的。

2. 文档里把Master放进LB池，是为了控制平面高可用，不是业务流量 #

你看到的这个场景，其实是控制平面的负载均衡配置，和业务流量完全是两码事：

• kube-apiserver是集群所有组件的通信枢纽（kubelet、kubectl、控制器都要和它交互），为了避免单Master节点故障导致集群不可用，会把多个Master节点放进LB池，实现apiserver的负载均衡和故障转移。这个LB是给集群内部组件用的，不是给外部业务流量用的。
• 真正承载业务流量的LB，应该指向Worker节点——要么是所有Worker，要么是专门用来承接外部流量的Worker节点（后面会说）。

3. 大型集群里，指定少数Worker节点做流量入口更有利 #

在你的例子（2 Master + 4 Worker + 外部LB）里，推荐的做法是把外部LB指向专门的Worker边缘节点（比如从4个Worker里选2个），而不是所有Worker或者Master，原因有这些：

• 资源隔离：边缘节点专门承接外部流量，可以单独配置更高的带宽、CPU资源，避免业务流量挤占其他Worker上的业务Pod资源。
• 统一管控：所有外部流量都从这几个节点进入，方便集中做限流、WAF防护、日志收集、监控等操作，不用在所有Worker上重复配置。
• 运维便利：如果需要升级流量入口组件（比如Ingress Controller），只需要操作这几个边缘节点，不会影响整个集群的业务Pod。

当然，如果是小型集群，把流量分散到所有Worker节点也没问题，但大型集群里，集中化的流量入口管理是更优的方案。

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