Kubernetes集群是否应配置两类负载均衡器而非一类？

你提到的这两个负载均衡器服务于完全不同的流量场景，是生产级Kubernetes集群中缺一不可的独立组件，下面分别说明：

1. ApiServer主节点负载均衡器 #

• 核心作用：给集群内部组件（kubelet、kube-controller-manager、kube-scheduler等）以及外部kubectl客户端提供一个稳定的ApiServer入口，实现多主节点间的流量分发和故障转移。
• 必要性：生产集群通常会部署3台及以上主节点来保证高可用，如果没有这个LB，一旦当前连接的主节点故障，kubectl和集群组件会直接失去连接，导致集群不可控；有了LB后，流量会自动切换到健康的主节点，避免单点故障。
• 部署特点：这个LB一般是内部或半公开的，不需要暴露到公网（除非有跨网络的kubectl管理需求，此时要配合身份认证和白名单做安全限制），可以用云厂商的内部负载均衡器，或者自建HAProxy、Nginx来实现。

2. Ingress Controller外部负载均衡器 #

• 核心作用：作为用户业务流量的入口，承接来自集群外部的HTTP/HTTPS流量，转发到运行中的Ingress Pod，再由Ingress规则路由到后端业务服务。
• 必要性：Ingress Pod是运行在集群节点上的普通Pod，自身没有固定的公网入口；如果用NodePort或HostPort替代LB，一旦承载Ingress Pod的节点故障，流量会直接中断。LB能自动识别健康的Ingress Pod所在节点，保证业务流量的连续性。
• 部署特点：这个LB是面向公网或特定外部业务网络的，需要配置公网IP、端口转发规则和安全组，确保合法业务流量能正常接入，同时拦截恶意请求。

为什么教程里只提Ingress的LB？ #

很多入门教程为了降低学习门槛，会采用单主节点的简化集群架构，或者省略ApiServer LB的配置（让kubectl直接连接单个主节点），但这种方式完全不符合生产环境的高可用要求，只能用于测试或学习场景。

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