nginx入口控制器和云负载平衡器之间的关系是什么？

我将

nginx入口控制器部署到集群。这在我的云提供商（假设AWS或GCE）中提供了一个负载平衡器。但是，集群内的所有流量都由控制器根据我的入口规则和注释进行路由

那么，让云中的负载平衡器坐在这个控制器前面的目的是什么？看起来控制器正在进行实际的负载平衡

我想了解如何使用它，以便云负载平衡器实际上将流量路由到集群内的机器，同时仍然遵循我所有的
nginx
配置/注释，或者即使这是可能的/有意义的。
您可能拥有一个具有多个主服务器的高可用性（HA）集群，负载平衡器是“进入”Kubernetes集群的一种简单实用的方法，因为您的应用程序应该可以被您的用户使用（这些用户与您的集群位于不同的网络上）。
因此，您需要有一个K8S群集的入口点

LB是一个易于配置的入口点

以这张图片为例：

您的API服务器是负载平衡的。来自集群外部的调用将通过LB，并由API服务器管理。只有一个主机（所选主机）负责在etcd数据库中保留集群的状态

当您拥有
ingress controller
和
ingress rules
时，我认为在K8S中配置和管理它们会更容易，而不是将它们写入LB配置文件（并在每次修改时重新加载配置）

我建议你看一下并在里面做练习。这是理解流程的好方法。
在ingress controller中是一个“控制器”，用kubernetes的术语来说，它是一个软件循环，用于侦听声明性配置（ingress资源）和相关“集群状态”的更改，比较两者，然后“协调”群集的状态为声明性配置

在这种情况下，“集群状态”是以下各项的组合：


由控制器生成的nginx配置文件，由运行nginx的集群中的pod使用
云提供程序的配置，指示提供者的边缘流量基础结构向集群中的nginx pod提供符合某些标准的特定外部交付流量

因此，当您更新入口资源时，控制器会注意到更改，创建新的nginx配置文件，更新并重新启动运行nginx的pod

就物理体系结构而言，将事物可视化为“集群内部”与“集群外部”或“集群”与“云”并不准确。客户看到的一切都是抽象的

在GCP中，在客户可见的虚拟机、负载平衡器和托管集群下面有多个数据包和流量管理层

要进入的外部流量在到达“您的”集群之前，会通过Google基础设施中的几个逻辑控制点，您无法了解这些控制点的详细信息