“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 支持。

我們希望本文能幫助您深入了解 Kubernetes 負載均衡選項，并且您已準備好在下一個項目中使用所有負載均衡器。