如何实现 Kubernetes 负载均衡器-nacos怎么实现负载均衡

设置 Kubernetes 负载均衡器服务的入门指南。

“Kubernetes 负载均衡器”是一个非常宽泛的术语，可以指代多种事物。在本文中，我们将研究两种类型的负载均衡器：一种用于将 Kubernetes 服务暴露给外部世界，另一种被工程师用来平衡这些服务的网络流量负载。

继续阅读以获取经过验证的处理 Kubernetes 负载均衡器的最佳实践。

什么是 Kubernetes 负载均衡器？

在 Kubernetes 中，容器被分组为具有共享存储和网络资源的 pod，以及如何运行这些容器的规范。一组相关的 Pod 可以构成一个 Kubernetes 服务。

由于 pod 不是持久的——Kubernetes 自动创建和销毁它们——它们的 IP 地址也不是持久的。要公开 Pod，您需要使用名为 Service 的 Kubernetes 资源。

Kubernetes 服务允许您将一组 pod 公开给外部或内部使用。您可以从几种类型的服务中进行选择，因此这里有一个快速概览以帮助您入门。

Kubernetes 服务概览

ClusterIP——这是一种默认类型的 K8s 服务，仅在内部公开一组 pod。下面是 ClusterIP 服务的 YAML 定义示例：

apiVersion: v1
kind: Service
metadata:
name: my-internal-service
spec:
selector:
app: my-app
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP

ClusterIP 用于内部应用程序通信，在集群外部不可用。

NodePort——该服务在集群中的每个节点 IP 上公开一个给定的端口。

YAML 定义示例：

apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
spec:
selector:
app: my-app
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30000
protocol: TCP

请注意，NodePort 服务有很多缺点：

每个端口只能有一项服务
您只能使用端口 30000–32767，
如果您的节点/虚拟机 IP 地址发生变化，您需要进行处理。

这就是为什么不建议将其用于生产用例。

LoadBalancer – 此服务使用外部负载均衡器公开一组 pod。所有托管的 Kubernetes 产品都有自己的实现（对于 EKS，您可以使用 NLB、ALB 等）

在大多数情况下，它们是由云提供商创建的。但也有一些项目旨在将其暴露在裸机集群上——metallb就是一个很好的例子（我在本文末尾分享了更多例子）。

但这还没有结束。

Kubernetes 还有一个名为Ingress的 API 对象。Ingress 建立在 Kubernetes Service 之上（要暴露 Ingress，你需要使用 Kubernetes Service）。Ingress 的主要职责是根据预先确定的路由规则或算法将网络流量分配给服务。

它还将 pod 暴露给外部流量，通常是通过 HTTP。根据您的业务目标和环境细节，您可以使用不同的负载分配策略。

YAML 定义示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx-example
rules:
- http:
paths:
- path: /testpath
pathType: Prefix
backend:
service:
name: test
port:
number: 80

负载均衡器流量分配策略

在多个后端服务之间有效分配网络流量是最大化可扩展性和可用性的关键。

在将外部流量负载平衡到 pod 方面，您有很大的自由度，但每种策略都有其优势和权衡。这完全取决于您的负载、要求和偏好。

负载平衡算法的选择是你应该谨慎选择的——否则，你最终会得到一个不平衡的负载分配或者一个单一的 web 服务器运行过热。

以下是您应该考虑的一些负载平衡算法。

循环法

使用此调度算法，您可以跟踪一系列获得新连接的合格服务器。请注意，此解决方案是静态的——它并没有真正考虑这些单独服务器之间的速度或性能差异。它只是确保请求按顺序到达服务器。

循环法无法区分慢速和快速服务器，因此它为每个服务器分配相同数量的连接。如果您期望高性能生产流量，它可能不是最佳选择。

L4 循环负载均衡器

Kubernetes 中的基本负载均衡策略之一。它列出发送到服务的所有请求并路由它们。kube-proxy 在 iptables 规则的帮助下为服务实现虚拟 IP，增加了过程的复杂性。它还为每个请求增加了额外的延迟，如果服务数量不断增长，这可能会堆积成一个问题。

L7 循环负载均衡

L7 代理通过 API 网关绕过 kube-proxy 并管理对可用 pod 的请求，从而将流量定向到 Kubernetes pod。负载均衡器还跟踪 Kubernetes Endpoints API 提供的 pod。当它收到对给定 Kubernetes 服务的请求时，它会在相关 pod 之间循环请求以找到可用的 pod。

L4 kube-proxy 和 IPVS

默认情况下，kube-proxy 使用 iptables 进行路由，但它也可以使用 IP 虚拟服务器 (IPVS)。IPVS 的优点是可扩展性：在 O(1) 时间内运行而不受所需路由规则数量的影响。这个数字与服务的数量成正比。

如果你正在运行一个拥有数千个服务的巨大 Kubernetes 集群，IPVS 是一个不错的选择。不过，IPVS 是 L4 级路由，因此它受到一些限制。

环哈希

此调度算法基于散列，散列源自指定的密钥。散列允许跨服务器分布新连接。环哈希是大量服务器和动态内容的一个很好的解决方案，因为它结合了负载平衡和持久性。许多需要每个客户端状态的电子商务应用程序或服务都使用它。

当需要添加或移除服务器时，一致性哈希不必重新计算整个哈希表。因此，它不会影响其他连接。请注意，环哈希在大规模运行时可能会增加一些请求延迟。此外，该算法生成的查找表可能不适合您的 CPU 处理器缓存。

磁悬浮

与环哈希类似，Maglev 是一种最初由谷歌开发的一致性哈希算法。它背后的想法是在哈希表查找上提高环哈希的速度。它的创建者的另一个目标是最小化算法的内存占用。

如果您决定将 Maglev 用于微服务，则预计在节点出现故障时生成查找表会产生高昂的成本。由于 K8s pod 本质上是相对短暂的，使用 Maglev 可能不是最好的主意。

最少连接

这种动态负载平衡算法将客户端请求分配到活动连接数最少且连接负载最小的 pod。由于这一点，它可以适应速度较慢或不健康的服务器。但是，当所有 Pod 都同样健康时，负载将平均分配。

处理 Kubernetes 负载均衡器的最佳实践

在实施 Kubernetes 负载均衡器时，采取一些配置步骤以确保您的 K8s 部署充分利用您选择的负载均衡器。

以下是在 Kubernetes 中使用负载均衡器的一些最佳实践。

检查负载均衡器是否开启

这一步似乎太明显了，无法包含在此列表中，但这是关键的一步。您需要在 K8s 系统中启用服务负载均衡器。您的负载均衡器需要支持封闭环境和服务发现。此外，您的应用程序应设计为容器化。

每个云服务提供商都有自己的负载均衡器实现——其中大多数允许使用服务注释进行微调

启用就绪探测器

就绪探测器通知 K8s 应用程序是否准备好为流量提供服务。当它们将流量传递到 pod 时，您需要启用就绪探测器。为此，您需要在任何 K8s 部署中定义它。

如果您没有适当的探测，用户将到达 pod，但不会获得正常的服务器响应。那是因为就绪探测器的工作是向 Kubernetes 发出信号，告知 Kubernetes 何时将 pod 置于负载均衡器之后，将服务置于代理之后。

启用 Liveness Probe

您应该启用的另一个关键探测器是 liveness 探测器。它让 Kubernetes 知道 pod 是否足够健康可以继续工作，或者重启它是否是一个更好的主意。它基于 bash 命令执行简单或复杂的检查。

这个探针是用来帮助 K8s 确定负载均衡是否工作正常或者它的某些组件是否需要支持。即使您的应用程序包含错误，Liveness 探测器也能提高可用性。

应用网络策略

为了保护您的 K8s 部署，负载均衡器必须能够将安全组策略应用于虚拟机或工作节点。

在理想情况下，您应该将入站和出站流量限制在最低要求。设置这样的限制有什么好处？它可以帮助您防止意外将不需要的服务暴露给出站流量。

Kubernetes 附带网络安全策略功能，能够为部署中的所有资源提供服务。您还需要确保您的 Kubernetes 集群配备了支持网络策略的网络插件。

启用 CPU/内存请求

这样，容器将能够自动请求资源。这有助于释放系统所需的 CPU 和内存资源。此外，启用这些请求可以让您定义这些资源，这样 Pod 就不会在内存不足的情况下运行。最重要的是，您消除了 CPU 或内存接管节点上的所有资源并导致错误或故障的风险。

超越负载均衡器优化 Kubernetes

在处理需要高可用性的工作负载时，将 pod 分布在不同的可用性区域 (AZ) 之间非常重要。这就是您如何确保即使其中一个 AZ 出现故障也可以访问应用程序。CAST AI 支持这种类似于 K8s 调度器的 pod 调度。

将 pod 分布在不同的可用性区域意味着使用 LoadBalancer，它支持在不同区域之间分配流量。在大多数情况下，它应该开箱即用，因为大多数云都有一个支持在区域之间分配流量的负载均衡器。尽管如此，还是值得仔细检查一下。

此外，除了利用不同的可用区外，CAST AI 还允许您将工作负载平均分配给不同的子网，以便充分利用所有子网。您可以在此处找到有关子网使用计算的更多信息。

奖励：家庭实验室中的负载平衡

部署生产级 Kubernetes 集群并使用适当的负载均衡器是一个挑战——但是如果您想了解更多关于设置 K8s 集群的知识怎么办？Homelab 可以回答这个问题。

仅仅为了好玩而创建 K8s 集群可能具有挑战性，但也会带来回报。在家庭网络中设置适当的 LB 也很困难，因为您不太可能在家中拥有企业级网络设备。

因此，从家庭集群公开您的宠物项目的最简单方法可能是使用NodePort类型的 K8s 服务。动态 IP 不会有问题，因为您会有具有静态 IP 的节点。

但是，如果我们想更进一步呢？并想使用更类似于生产级集群的东西？为此，您可以使用名为 Metallb 的项目。该项目处于测试阶段，但在家庭实验室中应该可以正常工作。Metallb 有两种 L2 工作模式，家用路由器就足够了。简而言之，这意味着机器只是有多个 IP 地址。

或者您可以使用称为 BGP 的更高级模式。在那里你有跨多个节点的真正负载平衡，但路由器需要有 BGP 支持。