为什么我们需要一个负载均衡器来使用入口公开kubernetes服务？

Question

对于部署在Google kubernetes引擎上的基于微服务的架构示例，我需要帮助来验证我的理解：

1. 我们知道服务应该为pod副本集负载平衡流量。
2. 当我们创建一个nginx入口控制器和入口定义来路由到每个服务时，负载均衡器也会自动设置。
3. 曾在某处读到，创建nginx入口控制器意味着在幕后创建nginx控制器（部署）和负载均衡器类型的服务。我不确定这是否是真的。

负载平衡似乎是由服务来完成的。入口控制器正在执行基于URL的路由。

为什么我们需要负载平衡器？这并不意味着要跨多个实例进行负载平衡。它只会将所有流量转发给创建的nginx反向代理，并根据URL路由请求。

如果我的理解有误，请改正。

Answer 1

负载平衡似乎是由服务来完成的。入口控制器正在执行基于URL的路由。

服务确实平衡了POD之间的流量。但默认情况下，在Google kubernetes引擎中的kubernetes之外无法访问它们（ClusterIP类型）。您可以使用LoadBalancer类型创建服务，但每个服务都将获得自己的IP地址（网络负载平衡器），因此可能会变得昂贵。此外，如果您有一个具有不同服务的应用程序，那么最好使用提供单个入口点的入口对象。创建Ingress对象时，Ingress控制器（例如nginx one）会创建一个Google Cloud HTTP（S）负载平衡器。入口对象又可以与一个或多个服务对象相关联。

然后您可以从入口对象获取分配的负载均衡器IP：

获取入口入口名称

因此，可以在kubernetes集群之外访问pods中的应用程序：

负载平衡器IP/url1-

LoadBalancerIP/url2-

Answer 2

入口控制器（例如nginx）吊舱需要暴露在kubernetes集群之外，作为所有进入kubernetes集群的南北通信量的入口点。一种方法是通过负载平衡器。您也可以使用NodePort，但不建议将其用于生产，或者您可以直接在具有公共ip的主机上的主机网络上html" target="_blank">部署入口控制器。拥有负载平衡器还能够跨入口控制器吊舱的多个副本对流量进行负载平衡。

当您使用入口控制器时，流量从负载平衡器到达入口控制器，然后根据入口资源中定义的规则到达后端POD IP。这绕过了kubernetes服务和kubernetes服务提供的负载平衡（通过第4层的kube代理）。入口控制器在内部发现kubernetes服务endpoint的所有POD IP，并直接将流量路由到POD。

Answer 3

Service类型LoadBalancer和Inete是从外部访问应用程序的方式，尽管它们的工作方式不同。

服务：

在Kubernetes中，服务是一种抽象，它定义了一组逻辑POD和访问POD的策略（有时这种模式被称为微服务）。服务所针对的吊舱集通常由选择器确定（请参见下文了解为什么您可能需要一个没有选择器的服务）。

有一些类型的服务，其中LoadBalancer类型允许您公开您的应用程序，为您的服务分配外部IP。对于每个LoadBalancer服务，都将为其分配一个新的外部IP。负载平衡将由库贝代理处理。

进入：

一个API对象，用于管理对集群中服务的外部访问，通常是HTTP。入口可以提供负载平衡、SSL终止和基于名称的虚拟主机。

当您设置入口（即：nginx ingress）时，将为入口控制器吊舱创建服务类型负载平衡器，并自动在云提供商中创建负载平衡器，并为nginx ingress服务分配公共IP。

此负载平衡器/公共ip将用于所有服务的传入连接，nginx ingress将负责处理传入连接。

例如：

Supose您有10个LoadBalancer类型的服务：这将导致创建10个新的Public ip，您需要为您想要访问的服务使用相应的ip。

但如果使用入口，则只会创建1个IP，入口将负责根据入口配置中定义的路径/URL处理正确服务的传入连接。通过入口，您可以：

• 使用路径中的regex定义要重定向的服务

Ingress中关于Ingress负载平衡的一个重要注意事项：

GCE/AWS负载平衡器不为其目标池提供权重。这不是旧LB kube代理规则的问题，旧LB kube代理规则可以在所有endpoint之间正确平衡。

使用新功能，外部流量在POD之间的负载平衡并不均衡，而是在节点级别上均衡（因为GCE/AWS和其他外部LB实现不具备指定每个节点权重的能力，它们在所有目标节点之间均衡，而不考虑每个节点上的POD数量）。