问：高效的 Kubernetes 负载均衡答案

【问题标题】：Q: Efficient Kubernetes load balancing问：高效的 Kubernetes 负载均衡
【发布时间】：2020-03-31 11:13:04
【问题描述】：

我一直在研究 Kubernetes 网络，更具体地说，是如何最高效地为 HTTPS 用户提供服务。

我正在观看这个演讲：https://www.youtube.com/watch?v=0Omvgd7Hg1I，从 22:18 开始，他解释了不支持 pod 的负载均衡器的问题所在。现在，他们在 kubernetes 中解决这个问题的方法是让节点也充当“路由器”，并让节点将请求传递给另一个节点。（解释于 22:46）。这似乎不是很有效，但是当环顾 SoundCloud (https://developers.soundcloud.com/blog/how-soundcloud-uses-haproxy-with-kubernetes-for-user-facing-traffic) 时，实际上似乎做了与此类似的事情，但使用的是 NodePorts。他们说开销成本低于创建更好的负载平衡器。

从我读到的一个选项可能是使用入口控制器。确保每个节点不超过一个入口控制器，并将流量路由到具有入口控制器的特定节点。这样就不需要任何流量重新路由。但是，这确实增加了另一层路由。

这些信息都是 2017 年的，所以我的问题是：是否有任何 pod 感知负载均衡器，或者是否有其他方法不涉及通过网络两次发送 http 请求和响应？

提前谢谢你，亨德里克

编辑：

关于我的用例的更多信息：

kubernetes 有一个裸机设置。防火墙负载平衡两个 HAProxy 实例之间的传入数据。这些 HAProxy 实例执行 ssl 终止并将流量转发到几个站点。这包括一个交换设置、一些内部 IIS 站点和一个用于静态 Web 应用程序的 nginx 服务器。这个想法是将应用服务器转换为 kubernetes。

现在我的主要问题是如何将请求从 HAProxy 获取到 kubernetes。我看到了几个选项：

使用 SoundCloud 设置。基础设施几乎保持不变，HAProxy 服务器仍然可以像现在这样运行。
我可以在 kubernetes 集群的每个节点上使用入口控制器，并在节点之间进行防火墙负载平衡。我相信可以将流量从入口控制器转发到集群外的服务器，例如交换。
我不知道的一些神奇的负载均衡器可以识别 pod，并且能够在 kubernetes 集群之外运行。

选项 1 和 2 相对简单，并且在工作方式上非常接近，但它们确实会带来性能损失。当请求被防火墙转发到的节点没有运行所需的 Pod，或者另一个 Pod 的工作量较少时，就会出现这种情况。该请求将被转发到另一个节点，因此会使用网络两次。

这只是你在使用 Kubernetes 时付出的代价，还是我缺少什么？

【问题讨论】：

您能告诉我们更多关于您的特定用例的信息吗？实际上，您对使用不知道Pod 的 loadbalancer 最大的担忧是什么？在大多数情况下，即使使用 externalTrafficPolicy: Local（当前使用它代替演示文稿中讨论的注释），负载分布也会相当接近。
@mario 我更新了我的问题

标签： kubernetes load-balancing kubernetes-ingress

【解决方案1】：

流量如何流向 pod 取决于是否使用托管集群。

几乎所有云提供商都可以在其托管的 K8s 集群中以云原生方式转发流量。首先，您可以使用一些特殊的网络设置来管理集群（例如 GKE 的 vpc-native 集群）。然后，您唯一需要做的就是创建一个LoadBalancer 类型的服务来公开您的工作负载。您还可以为您的 L7 工作负载创建 Ingress，它们将由提供的 IngressController（例如 AWS 的 ALB）处理。

在没有任何云提供商（OpenStack 或 vSphere）的本地集群中，公开工作负载的唯一方法是 NodePort 类型化服务。这并不意味着你不能改进它。

如果您的集群使用反向代理（SoundCloud 案例），将externalTrafficPolicy: Local 设置为服务可能会中断工作节点之间的流量转发。当通过 NodePorts 接收到流量时，它们会被转发到本地 Pod，如果 Pod 驻留在其他节点上，它们会被丢弃。保留代理将在后端健康检查中将这些 NodePort 标记为不健康，并拒绝向它们转发流量。另一种选择是使用topology-aware service routing。在这种情况下，本地 Pod 具有优先级，当没有本地 Pod 匹配时，流量仍然在节点之间转发。

对于本地集群中的 IngressController，它有点不同。您可能有一些具有 EIP 或公共 IP 的工作节点。为了暴露 HTTP(S) 服务，IngressController 通常通过 DaemeaSet 和 HostNetwork 部署在这些工作节点上，以便客户端通过 well-known 端口和节点的 EIP 访问 IngressController。这些工作节点通常不接受其他工作负载（例如 OpenShift 中的基础设施节点），因此需要在 Pod 网络上再进行一个转发。您还可以在所有工作节点以及其他工作负载上部署 IngressController，因此如果 IngressController 支持 topology-aware service routing，则流量可以转发到更近的 Pod，尽管现在可以。

希望对你有帮助！

【讨论】：