設(shè)置 Kubernetes 負(fù)載均衡器服務(wù)的入門指南。

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

(相關(guān)資料圖)

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

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

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

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

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

Kubernetes 服務(wù)概覽

ClusterIP——這是一種默認(rèn)類型的 K8s 服務(wù)，僅在內(nèi)部公開一組 pod。下面是 ClusterIP 服務(wù)的 YAML 定義示例：

apiVersion: v1kind: Servicemetadata:name: my-internal-servicespec:selector:app: my-apptype: ClusterIPports:- name: httpport: 80targetPort: 80protocol: TCP

ClusterIP 用于內(nèi)部應(yīng)用程序通信，在集群外部不可用。

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

YAML 定義示例：

apiVersion: v1kind: Servicemetadata:name: my-nodeport-servicespec:selector:app: my-apptype: NodePortports:- name: httpport: 80targetPort: 80nodePort: 30000protocol: TCP

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

每個端口只能有一項(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)（對于 EKS，您可以使用 NLB、ALB 等）

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

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

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

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

YAML 定義示例：

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: minimal-ingressannotations:nginx.ingress.kubernetes.io/rewrite-target: /spec:ingressClassName: nginx-examplerules:- http:paths:- path: /testpathpathType: Prefixbackend:service:name: testport:number: 80

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

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

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

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

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

循環(huán)法

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

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

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

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

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

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

L4 kube-proxy 和 IPVS

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

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

環(huán)哈希

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

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

磁懸浮

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

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

最少連接

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

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

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

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

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

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

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

啟用就緒探測器

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

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

啟用 Liveness Probe

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

這個探針是用來幫助 K8s 確定負(fù)載均衡是否工作正常或者它的某些組件是否需要支持。即使您的應(yīng)用程序包含錯誤，Liveness 探測器也能提高可用性。

應(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)存請求

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

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

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

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

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

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

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

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

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

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

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

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

關(guān)鍵詞： 應(yīng)用程序 提供服務(wù) 可擴(kuò)展性