“Kubernetes 負(fù)載均衡器”是一個(gè)非常寬泛的術(shù)語(yǔ)，可以指代多種事物。在本文中，我們將研究?jī)煞N類型的負(fù)載均衡器：一種用于將 Kubernetes 服務(wù)暴露給外部世界，另一種被工程師用來(lái)平衡這些服務(wù)的網(wǎng)絡(luò)流量負(fù)載。

繼續(xù)閱讀以獲取經(jīng)過(guò)驗(yàn)證的處理 Kubernetes 負(fù)載均衡器的最佳實(shí)踐。

什么是 Kubernetes 負(fù)載均衡器？

在 Kubernetes 中，容器被分組為具有共享存儲(chǔ)和網(wǎng)絡(luò)資源的 pod，以及如何運(yùn)行這些容器的規(guī)范。一組相關(guān)的 Pod 可以構(gòu)成一個(gè) Kubernetes 服務(wù)。

由于 pod 不是持久的——Kubernetes 自動(dòng)創(chuàng)建和銷毀它們——它們的 IP 地址也不是持久的。要公開 Pod，您需要使用名為 Service 的 Kubernetes 資源。

Kubernetes 服務(wù)允許您將一組 pod 公開給外部或內(nèi)部使用。您可以從幾種類型的服務(wù)中進(jìn)行選擇，因此這里有一個(gè)快速概覽以幫助您入門。

Kubernetes 服務(wù)概覽

ClusterIP——這是一種默認(rèn)類型的 K8s 服務(wù)，僅在內(nèi)部公開一組 pod。下面是 ClusterIP 服務(wù)的 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 用于內(nèi)部應(yīng)用程序通信，在集群外部不可用。

NodePort——該服務(wù)在集群中的每個(gè)節(jié)點(diǎn) IP 上公開一個(gè)給定的端口。

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

請(qǐng)注意，NodePort 服務(wù)有很多缺點(diǎn)：

• 每個(gè)端口只能有一項(xiàng)服務(wù)
• 您只能使用端口 30000–32767，
• 如果您的節(jié)點(diǎn)/虛擬機(jī) IP 地址發(fā)生變化，您需要進(jìn)行處理。

這就是為什么不建議將其用于生產(chǎn)用例。

LoadBalancer – 此服務(wù)使用外部負(fù)載均衡器公開一組 pod。所有托管的 Kubernetes 產(chǎn)品都有自己的實(shí)現(xiàn)（對(duì)于 EKS，您可以使用 NLB、ALB 等）

在大多數(shù)情況下，它們是由云提供商創(chuàng)建的。但也有一些項(xiàng)目旨在將其暴露在裸機(jī)集群上——metallb就是一個(gè)很好的例子（我在本文末尾分享了更多例子）。

但這還沒(méi)有結(jié)束。

Kubernetes 還有一個(gè)名為Ingress的 API 對(duì)象。Ingress 建立在 Kubernetes Service 之上（要暴露 Ingress，你需要使用 Kubernetes Service）。Ingress 的主要職責(zé)是根據(jù)預(yù)先確定的路由規(guī)則或算法將網(wǎng)絡(luò)流量分配給服務(wù)。

它還將 pod 暴露給外部流量，通常是通過(guò) HTTP。根據(jù)您的業(yè)務(wù)目標(biāo)和環(huán)境細(xì)節(jié)，您可以使用不同的負(fù)載分配策略。

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

負(fù)載均衡器流量分配策略

在多個(gè)后端服務(wù)之間有效分配網(wǎng)絡(luò)流量是最大化可擴(kuò)展性和可用性的關(guān)鍵。

在將外部流量負(fù)載平衡到 pod 方面，您有很大的自由度，但每種策略都有其優(yōu)勢(shì)和權(quán)衡。這完全取決于您的負(fù)載、要求和偏好。

負(fù)載平衡算法的選擇是你應(yīng)該謹(jǐn)慎選擇的——否則，你最終會(huì)得到一個(gè)不平衡的負(fù)載分配或者一個(gè)單一的 web 服務(wù)器運(yùn)行過(guò)熱。

以下是您應(yīng)該考慮的一些負(fù)載平衡算法。

循環(huán)法

使用此調(diào)度算法，您可以跟蹤一系列獲得新連接的合格服務(wù)器。請(qǐng)注意，此解決方案是靜態(tài)的——它并沒(méi)有真正考慮這些單獨(dú)服務(wù)器之間的速度或性能差異。它只是確保請(qǐng)求按順序到達(dá)服務(wù)器。

循環(huán)法無(wú)法區(qū)分慢速和快速服務(wù)器，因此它為每個(gè)服務(wù)器分配相同數(shù)量的連接。如果您期望高性能生產(chǎn)流量，它可能不是最佳選擇。

L4 循環(huán)負(fù)載均衡器

Kubernetes 中的基本負(fù)載均衡策略之一。它列出發(fā)送到服務(wù)的所有請(qǐng)求并路由它們。kube-proxy 在 iptables 規(guī)則的幫助下為服務(wù)實(shí)現(xiàn)虛擬 IP，增加了過(guò)程的復(fù)雜性。它還為每個(gè)請(qǐng)求增加了額外的延遲，如果服務(wù)數(shù)量不斷增長(zhǎng)，這可能會(huì)堆積成一個(gè)問(wèn)題。

L7 循環(huán)負(fù)載均衡

L7 代理通過(guò) API 網(wǎng)關(guān)繞過(guò) kube-proxy 并管理對(duì)可用 pod 的請(qǐng)求，從而將流量定向到 Kubernetes pod。負(fù)載均衡器還跟蹤 Kubernetes Endpoints API 提供的 pod。當(dāng)它收到對(duì)給定 Kubernetes 服務(wù)的請(qǐng)求時(shí)，它會(huì)在相關(guān) pod 之間循環(huán)請(qǐng)求以找到可用的 pod。

L4 kube-proxy 和 IPVS

默認(rèn)情況下，kube-proxy 使用 iptables 進(jìn)行路由，但它也可以使用 IP 虛擬服務(wù)器 (IPVS)。IPVS 的優(yōu)點(diǎn)是可擴(kuò)展性：在 O(1) 時(shí)間內(nèi)運(yùn)行而不受所需路由規(guī)則數(shù)量的影響。這個(gè)數(shù)字與服務(wù)的數(shù)量成正比。

如果你正在運(yùn)行一個(gè)擁有數(shù)千個(gè)服務(wù)的巨大 Kubernetes 集群，IPVS 是一個(gè)不錯(cuò)的選擇。不過(guò)，IPVS 是 L4 級(jí)路由，因此它受到一些限制。

環(huán)哈希

此調(diào)度算法基于散列，散列源自指定的密鑰。散列允許跨服務(wù)器分布新連接。環(huán)哈希是大量服務(wù)器和動(dòng)態(tài)內(nèi)容的一個(gè)很好的解決方案，因?yàn)樗Y(jié)合了負(fù)載平衡和持久性。許多需要每個(gè)客戶端狀態(tài)的電子商務(wù)應(yīng)用程序或服務(wù)都使用它。

當(dāng)需要添加或移除服務(wù)器時(shí)，一致性哈希不必重新計(jì)算整個(gè)哈希表。因此，它不會(huì)影響其他連接。請(qǐng)注意，環(huán)哈希在大規(guī)模運(yùn)行時(shí)可能會(huì)增加一些請(qǐng)求延遲。此外，該算法生成的查找表可能不適合您的 CPU 處理器緩存。

磁懸浮

與環(huán)哈希類似，Maglev 是一種最初由谷歌開發(fā)的一致性哈希算法。它背后的想法是在哈希表查找上提高環(huán)哈希的速度。它的創(chuàng)建者的另一個(gè)目標(biāo)是最小化算法的內(nèi)存占用。

如果您決定將 Maglev 用于微服務(wù)，則預(yù)計(jì)在節(jié)點(diǎn)出現(xiàn)故障時(shí)生成查找表會(huì)產(chǎn)生高昂的成本。由于 K8s pod 本質(zhì)上是相對(duì)短暫的，使用 Maglev 可能不是最好的主意。

最少連接

這種動(dòng)態(tài)負(fù)載平衡算法將客戶端請(qǐng)求分配到活動(dòng)連接數(shù)最少且連接負(fù)載最小的 pod。由于這一點(diǎn)，它可以適應(yīng)速度較慢或不健康的服務(wù)器。但是，當(dāng)所有 Pod 都同樣健康時(shí)，負(fù)載將平均分配。

處理 Kubernetes 負(fù)載均衡器的最佳實(shí)踐

在實(shí)施 Kubernetes 負(fù)載均衡器時(shí)，采取一些配置步驟以確保您的 K8s 部署充分利用您選擇的負(fù)載均衡器。

以下是在 Kubernetes 中使用負(fù)載均衡器的一些最佳實(shí)踐。

檢查負(fù)載均衡器是否開啟

這一步似乎太明顯了，無(wú)法包含在此列表中，但這是關(guān)鍵的一步。您需要在 K8s 系統(tǒng)中啟用服務(wù)負(fù)載均衡器。您的負(fù)載均衡器需要支持封閉環(huán)境和服務(wù)發(fā)現(xiàn)。此外，您的應(yīng)用程序應(yīng)設(shè)計(jì)為容器化。

每個(gè)云服務(wù)提供商都有自己的負(fù)載均衡器實(shí)現(xiàn)——其中大多數(shù)允許使用服務(wù)注釋進(jìn)行微調(diào)

啟用就緒探測(cè)器

就緒探測(cè)器通知 K8s 應(yīng)用程序是否準(zhǔn)備好為流量提供服務(wù)。當(dāng)它們將流量傳遞到 pod 時(shí)，您需要啟用就緒探測(cè)器。為此，您需要在任何 K8s 部署中定義它。

如果您沒(méi)有適當(dāng)?shù)奶綔y(cè)，用戶將到達(dá) pod，但不會(huì)獲得正常的服務(wù)器響應(yīng)。那是因?yàn)榫途w探測(cè)器的工作是向 Kubernetes 發(fā)出信號(hào)，告知 Kubernetes 何時(shí)將 pod 置于負(fù)載均衡器之后，將服務(wù)置于代理之后。

啟用 Liveness Probe

您應(yīng)該啟用的另一個(gè)關(guān)鍵探測(cè)器是 liveness 探測(cè)器。它讓 Kubernetes 知道 pod 是否足夠健康可以繼續(xù)工作，或者重啟它是否是一個(gè)更好的主意。它基于 bash 命令執(zhí)行簡(jiǎn)單或復(fù)雜的檢查。

這個(gè)探針是用來(lái)幫助 K8s 確定負(fù)載均衡是否工作正?；蛘咚哪承┙M件是否需要支持。即使您的應(yīng)用程序包含錯(cuò)誤，Liveness 探測(cè)器也能提高可用性。

應(yīng)用網(wǎng)絡(luò)策略

為了保護(hù)您的 K8s 部署，負(fù)載均衡器必須能夠?qū)踩M策略應(yīng)用于虛擬機(jī)或工作節(jié)點(diǎn)。

在理想情況下，您應(yīng)該將入站和出站流量限制在最低要求。設(shè)置這樣的限制有什么好處？它可以幫助您防止意外將不需要的服務(wù)暴露給出站流量。

Kubernetes 附帶網(wǎng)絡(luò)安全策略功能，能夠?yàn)椴渴鹬械乃匈Y源提供服務(wù)。您還需要確保您的 Kubernetes 集群配備了支持網(wǎng)絡(luò)策略的網(wǎng)絡(luò)插件。

啟用 CPU/內(nèi)存請(qǐng)求

這樣，容器將能夠自動(dòng)請(qǐng)求資源。這有助于釋放系統(tǒng)所需的 CPU 和內(nèi)存資源。此外，啟用這些請(qǐng)求可以讓您定義這些資源，這樣 Pod 就不會(huì)在內(nèi)存不足的情況下運(yùn)行。最重要的是，您消除了 CPU 或內(nèi)存接管節(jié)點(diǎn)上的所有資源并導(dǎo)致錯(cuò)誤或故障的風(fēng)險(xiǎn)。

超越負(fù)載均衡器優(yōu)化 Kubernetes

在處理需要高可用性的工作負(fù)載時(shí)，將 pod 分布在不同的可用性區(qū)域 (AZ) 之間非常重要。這就是您如何確保即使其中一個(gè) AZ 出現(xiàn)故障也可以訪問(wèn)應(yīng)用程序。CAST AI 支持這種類似于 K8s 調(diào)度器 的 pod 調(diào)度。

將 pod 分布在不同的可用性區(qū)域意味著使用 LoadBalancer，它支持在不同區(qū)域之間分配流量。在大多數(shù)情況下，它應(yīng)該開箱即用，因?yàn)榇蠖鄶?shù)云都有一個(gè)支持在區(qū)域之間分配流量的負(fù)載均衡器。盡管如此，還是值得仔細(xì)檢查一下。

此外，除了利用不同的可用區(qū)外，CAST AI 還允許您將工作負(fù)載平均分配給不同的子網(wǎng)，以便充分利用所有子網(wǎng)。您可以在此處找到有關(guān)子網(wǎng)使用計(jì)算的更多信息。

獎(jiǎng)勵(lì)：家庭實(shí)驗(yàn)室中的負(fù)載平衡

部署生產(chǎn)級(jí) Kubernetes 集群并使用適當(dāng)?shù)呢?fù)載均衡器是一個(gè)挑戰(zhàn)——但是如果您想了解更多關(guān)于設(shè)置 K8s 集群的知識(shí)怎么辦？Homelab 可以回答這個(gè)問(wèn)題。

僅僅為了好玩而創(chuàng)建 K8s 集群可能具有挑戰(zhàn)性，但也會(huì)帶來(lái)回報(bào)。在家庭網(wǎng)絡(luò)中設(shè)置適當(dāng)?shù)?LB 也很困難，因?yàn)槟惶赡茉诩抑袚碛衅髽I(yè)級(jí)網(wǎng)絡(luò)設(shè)備。

因此，從家庭集群公開您的寵物項(xiàng)目的最簡(jiǎn)單方法可能是使用NodePort類型的 K8s 服務(wù)。動(dòng)態(tài) IP 不會(huì)有問(wèn)題，因?yàn)槟鷷?huì)有具有靜態(tài) IP 的節(jié)點(diǎn)。

但是，如果我們想更進(jìn)一步呢？并想使用更類似于生產(chǎn)級(jí)集群的東西？為此，您可以使用名為 Metallb 的項(xiàng)目。該項(xiàng)目處于測(cè)試階段，但在家庭實(shí)驗(yàn)室中應(yīng)該可以正常工作。Metallb 有兩種 L2 工作模式，家用路由器就足夠了。簡(jiǎn)而言之，這意味著機(jī)器只是有多個(gè) IP 地址。

或者您可以使用稱為 BGP 的更高級(jí)模式。在那里你有跨多個(gè)節(jié)點(diǎn)的真正負(fù)載平衡，但路由器需要有 BGP 支持。

我們希望本文能幫助您深入了解 Kubernetes 負(fù)載均衡選項(xiàng)，并且您已準(zhǔn)備好在下一個(gè)項(xiàng)目中使用所有負(fù)載均衡器。