时间戳

首页 > 解决方案 > 问：高效的 Kubernetes 负载均衡

kubernetes - 问：高效的 Kubernetes 负载均衡

问题描述

我一直在研究 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。我看到几个选项：

  1. 使用 SoundCloud 设置。基础设施几乎可以保持不变，HAProxy 服务器仍然可以像现在这样运行。

  2. 我可以在 kubernetes 集群中的每个节点上使用入口控制器，并在节点之间进行防火墙负载平衡。我相信可以将流量从入口控制器转发到集群外的服务器，例如交换。

  3. 一些我不知道的神奇负载均衡器是 pod 感知的，并且能够在 kubernetes 集群之外运行。

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

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

标签： kubernetesload-balancingkubernetes-ingress

解决方案

流量如何流向 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 部署在这些工作节点上，以便客户端通过节点的众所周知的端口和 EIP 访问 IngressController。这些工作节点通常不接受其他工作负载（例如 OpenShift 中的基础设施节点），因此需要在 Pod 网络上再进行一次转发。您还可以在所有工作节点以及其他工作负载上部署 IngressController，因此如果 IngressControllertopology-aware service routing现在可以支持，流量可以转发到更近的 Pod。

希望能帮助到你！

推荐阅读