我不确定负载平衡如何与 Ingress 配合使用。
如果我理解正确，实际上发生的事情是这样的：
我看不到负载平衡是如何执行的。
我绘制的上述方案有什么问题？
你能帮我改正吗？
注意事项：
- 以下答案告诉我 Ingress 控制器本身属于“负载平衡器”类型：Ingress service type
- 我使用 kind ClusterIP，因为我不想将负载均衡器暴露给外界。以下文章不支持这种说法，其中负载均衡器将由服务提供：
【问题讨论】：
标签： kubernetes
ClusterIP 服务本身执行负载平衡。命名可能会令人困惑，因为 LoadBalancer 服务并不是唯一涉及负载平衡的服务 - LoadBalancer 实际上意味着更像“云提供商请创建一个外部负载平衡器并将其指向此服务”。 kubernetes ClusterIP 服务也 load-balance across Pods in different Nodes using the kube-proxy。如果您不想让 kubernetes 进行负载均衡，那么您必须通过 creating a headless service 专门禁用它。
【讨论】：
看来你画的第一个方案是正确的。但我认为你对术语感到困惑。特别是ingress 和ingress-controller 之间的区别。
Ingress是k8s中的一种资源（如Service、Deployment、ReplicaSet等）。如果我们想通过绑定到某个路径和主机（即 myapp.com/api -> my-api-service）向外部世界公开一些服务，我们会使用入口。
ingress-controller 的工作是处理入口资源的创建/更新/删除，并实现入口所需的所有功能。在引擎盖下，入口控制器是一个简单的部署，公开为 LoadBalancer 或 NodePort 服务，具体取决于 k8s 的部署位置。并且图像控制器将收到的请求进一步转发到与某些已部署入口资源中的主机和路径匹配的服务 pod 之一。
【讨论】：
我很好奇并想：如果 Ingress 唯一要做的事情就是将流量转发到在第 4 层实现负载平衡的 Service，我为什么需要一个 Ingress 来在第 7 层进行负载平衡？
我查找的大多数 Ingress 控制器实现都与 Kubernetes API 服务器通信以跟踪与服务关联的所有 Pod。它们不是将流量转发到服务，而是跳过中介并直接转发到 Pod。由于入口控制器在第 7 层上运行，因此可以实现更面向应用的负载平衡。
【讨论】：