gke上的kubernetes/为什么强制使用负载平衡器？

通过GKE进入kubernetes，目前正在裸机上通过kubeadm进行试验

在以后的环境中，不需要任何特定的负载平衡器；使用nginx入口和入口，可以为www提供服务

相反，在gke上，使用相同的nginx入口，或者使用l7提供的gke，您最终总会得到一个计费负载平衡器

这似乎不是最终需要的，原因是什么呢

通常，当一个人从外部世界接收流量时，该流量被发送到一个或多个非ACLd公共IP地址

如果你在裸金属上运行k8s，这些BMs可以有公共IP，你可以在一个或多个IP上运行入口

但是，出于安全原因，托管k8s环境不允许节点具有公共IP

---

相反，托管负载平衡器允许具有公共IP。它们被配置为知道集群入口所在的私有节点IP，并相应地引导流量

Kubernetes服务有几种类型，每种类型都建立在前一种服务的基础上：ClusterIP、NodePort和LoadBalancer。只有最后一个将在云环境中配置LoadBalancer，因此您可以在GKE上避免它，而无需模糊。问题是，然后呢？因为，在最好的情况下，您最终会得到一个入口（我假设我们像您的问题中那样公开入口），该入口在易失性IP（节点可以随时滚动，新节点将获得新IP）和NodePort服务提供的高端口上可用。这意味着您不仅没有固定的IP可供使用，而且还需要打开类似http://:31978的东西，这显然是废话。因此，在云中，您有一个简单的解决方案，即使用LoadBalancer服务类型将云负载平衡器放在它前面。此LB将接收端口80/443上的流量，并将其转发到正确的备份服务/POD。

您好，您似乎对第3层、第4层和第7层的负载平衡感到困惑。下面的文章可能会让你对Humm有更深入的了解…我的技能足以使用所有东西，但坦率地说，我的脑细胞没有组织起来，无法理解这些网络主题的基础。我读过这篇文章；我可以理解使用L7的好处，但不能理解为什么在gkeIn general上强制执行这种“附加组件”，当接收来自外部世界的流量时，该流量将发送到一个或多个非ACLd公共IP地址。如果你在裸金属上运行k8s，这些BMs可以有公共IP，你可以在一个或多个IP上运行入口。但是，出于安全原因，托管k8s环境不允许节点具有公共IP。相反，托管负载平衡器允许具有公共IP。这些被配置为知道为您的集群托管入口的私有节点IP，并将相应地引导流量。Hello@Jonah B，您的评论作为完整答案发布似乎很棒。请这样做。有一种方法可以完全跳过负载平衡器，请参阅不推荐用于严重的生产用途。对于穷人的解决方案很好。thx可以让事情变得更清楚@Suresh Vishnoi在上面评论了这个链接；听起来像是L7提高了性能（与裸机设置相比），但我仍然不确定这一点；不使用云提供商是否有任何缺点？取决于您所说的“使用云提供商”的含义。如果您指的是kubernetes内部的云，那么您应该始终为您使用的云启用云提供程序。在大多数情况下，资源调配系统将为您执行此操作。它不仅为您提供自动LB服务支持，还提供卷资源调配等功能。在裸机上，您通常需要自己提供一些解决方案，或者限制常规kube功能集（即完全不支持LB服务，只通过预定义的入口控制器公开所有内容）。不，我的意思是，当向“外部世界”提供站点/服务时。例如，在gke上时；他们的顶级负载平衡器（所以不是kube）是否提供了网络改进之类的功能。。或者这些考虑因素是否仍然存在于nginx中（尽管您使用的是nginx入口项目）？更简单一点；在裸机上，正如你所说，我通过一个预定义的入口来进行限制。尽管如此，我的网站/服务仍然提供相同的服务。但听起来有区别，这是我不完全理解的；因为最终的结果是“一样的”。我得到了安全部分；但是还有其他附加值吗？