为什么 NodePort 服务类型必须使用基于 ClusterIP 的负载均衡？答案

【问题标题】：Why NodePort service type has to use ClusterIP based load balancing?为什么 NodePort 服务类型必须使用基于 ClusterIP 的负载均衡？
【发布时间】：2019-05-16 00:56:17
【问题描述】：

在阅读 kubernetes 文档时，我注意到 NodePort 类型的服务总是自动创建一个 ClusterIP，并且以 NodePort 为目标的入口流量将被路由到 ClusterIP。我的问题是，为什么这是必要的？为什么 kubeproxy 不能直接通过转发对这个 NodePort 做负载均衡？ ClusterIP 似乎不是支持 NodePort 所必需的，而且它似乎会引入额外的开销。

【问题讨论】：

标签： kubernetes

【解决方案1】：

即使 NodePort 类型的 Service 不直接联系 Pod，它们仍然会通过 Service 的集群 IP 及其关联的 Pod 选择器规则。对于较新的 kubernetes，我认为您还可以影响流量是循环还是加权分布式，如果 NodePort 直接联系 Pod，这将不起作用

此外，NodePorts 在集群的每个成员上打开，但是——在大多数情况下——你没有在集群的每个成员上运行 Pod集群，因此它仍然必须使用服务 IP 路由到实际节点，在该节点上，服务中的 Pod 可以为该流量提供服务。

将 NodePorts 视为一种将“外部世界”与“集群世界”联系起来的机制，而不是一种绕过 iptables 或 ipvs 的快捷机制

【讨论】：

您所说的“加权分布式流量”是什么意思？ Kubernetes 已经有这个功能了吗？
确实如此，是的，从 1.11 开始：kubernetes.io/blog/2018/07/09/…
感谢您的解释。所以原因确实是我们想统一负载均衡处理。
对于您上面描述的场景，我们还可以让以 NodePort 为目标的入口流量直接通过 kubeproxy 并将其转发到运行在托管目标 pod 的节点上的 kubeproxy。为什么这行不通？如果我们说 NodePort 在设计上是一种桥接两个世界的方式，而我们故意不想为 LB 引入另一条路线，那似乎是一个合理的设计决策。
如果您担心 kube-proxy 并卷入流量路由的杂草中，那么请使用为 Pod 分配“真实”地址的 CNI 提供商，整个对话就会消失。或者您可以在这些 Pod 上设置 hostNetwork: true，并冒着同一个节点上的共同调度 Pod 发生端口冲突的风险