外部 LB 应该指向 k8s 工作节点还是控制平面(主)节点?

外部 LB 应该指向 k8s 工作节点还是控制平面(主)节点?

我计划在我的裸机服务器上建立集群,并正在研究 HA 集群中的 k8s 网络选项。

到目前为止,我得到的信息很混乱。一篇文章清楚地表明外部 LB 应该指向主节点,而另一篇文章则表明它需要落在工作节点上。

我认为这两种选择都有其优缺点。有人能给我指明正确的方向吗?

答案1

这通常不是一个“意见”的问题——而是一个试图实现高可用性的工作负载的问题,以及对哪些受众实现高可用性的问题

人们希望为控制平面节点配备一个负载均衡器,以便在控制平面节点停止服务时不必更新宇宙中的所有 kubeconfig,并为对等控制平面节点提供统一的相互联系方式。如果您不希望集群外的任何人访问 kubernetes API,那么它的传入 CIDR 可能会受到严格限制,尽管这会使kubectl使用变得尴尬

人们希望拥有一个负载均衡器 - 或者甚至是几个,这取决于访问模式的需求 - 指向工作节点以便消耗Servicestype: NodePort因为你是裸机,没有一些附加装置你将无法使用,type: LoadBalancer因为这需要与外部实体协调来配置这些负载均衡器)。

虽然 Kubernetes 集群将要在控制平面节点上打开 NodePort,不建议通过控制平面实例发送工作负载流量,因为它们已经忙于集群核算和管理任务。可能是你提到的“观点”部分——是否让控制平面实例参与集群的任何工作肯定是一个哲学上的差异,也是风险管理的一部分

相关内容