資源管理、排程和負載均衡作為K8s的三大支柱，它們是如何在K8s中實現的？它們又是如何相互作用，以提供高效的容器工作負載管理的？

每當談及Kubernetes，我們經常聽到諸如資源管理、排程和負載均衡等術語。雖然Kubernetes提供了許多功能，但更關鍵的還是要了解這些概念，只有這樣才能更好地理解如何放置、管理並恢復工作負載。在這篇文章中，我提供了每個功能的概述，並解釋了它們是如何在Kubernetes中實現的，以及它們如何相互作用，以提供高效的容器工作負載管理。

資源管理

資源管理是對基礎設施資源的有效配置。在Kubernetes中，資源可以通過容器或pod來請求、分配或消耗。擁有一個通用的資源管理模型是非常必要的，因為在Kubernetes中，包括排程器、負載均衡器、工作池管理器甚至應用程式本身的許多元件，都需要有資源意識。如果資源利用不足，這就意味著浪費，意味著成本效益低下。如果資源被過度訂購，可能會導致應用程式故障、停機或錯誤的SLA等。

資源以它所描述的資源型別的單位來表示。例如，記憶體的位元組數或計算容量的毫秒級。Kubernetes為定義資源及其各種屬性提供了明確的規範。

雖然，當今使用的主要資源型別是CPU和記憶體，但資源模型是可擴充套件的，允許多種系統以及由使用者自定義的資源型別。其他型別包括網路頻寬、網路操作和儲存空間。

資源規格在不同的環境下具有不同的含義。在Kubernetes中指定資源的三種主要方式如下：

• ResourceRequest指的是為容器或Pod請求的一組資源。例如，對於每個Pod例項，一個Pod可以請求1.5個CPU和600MB記憶體。ResourceRequest可以視為描述應用服務對資源的“需求”。
• ResourceLimit是指容器或pod可以消耗的組合資源的上限。例如，如果一個pod在執行時使用了超過2.5個CPU或1.2GB的記憶體，我們可能會認為它由於記憶體洩漏或其他問題而變得“流氓”了。在這種情況下，以防干擾其他叢集租戶，排程器可能會考慮將pod作為驅逐的候選物件。
• ResourceCapacity規範描述了叢集節點上可用的資源量。例如，一個物理叢集主機可能具有48個核心和64GB或RAM。叢集可以由具有不同資源容量的節點組成。容量規範可以被視為描述資源“供應”。

排程

在Kubernetes中，排程是將pod （由排程器管理的基本實體）與可用資源相匹配的過程。排程器考慮資源需求、資源可用性以及其他使用者提供的約束和策略指令，如服務質量、親和性/反親和性需求、資料區域性性等等。本質上，排程器的作用是將資源“供應”匹配到工作負載“需求”，如下所示:

一些排程約束（簡稱FitPredicates）是強制性的。例如，如果pod需要具有四個CPU核心和2GB記憶體的叢集節點，則該pod將保持在一個暫掛狀態，直到找到滿足此要求的叢集主機為止。

在其他情況下，可能有多個主機滿足強制性標準。在這種情況下，PriorityFunctions被視為反映排程首選項。基本上，排程器採用滿足強制性FitPredicates的主機列表，根據使用者可配置的優先順序功能的結果對每個主機打分，並找到滿足最大排程優先順序數量的最佳優化配置方案。

在Kubernetes中，工作負載可以由數量不定的pod組成，每個pod都具有特定的資源需求。此外，工作負載和叢集都是動態的，並具有伸縮性和自動擴充套件功能，因此，由於需要排程程式不斷地重新評估位置決策，pod的數量可能會發生變化。另外，由於Kubernetes的功能類似於cron作業，排程器需要考慮的不僅是當前的供應、需求和叢集狀態，還需要考慮未來工作負載的預留容量。

把排程挑戰想象成俄羅斯方塊遊戲，理解起來就不會那麼難了。我們的目標是儘可能緊密地打包所有部分（有效利用資源）。但是，它們是多維的（需要特定的記憶體、CPU、標籤選擇器等等），而不是二維的遊戲片段（pod）。無法匹配遊戲的部分類似於無法執行的應用程式。遊戲板不是靜態的，它隨著主機進出服務和服務規模的變化而變化。這就是Kubernetes排程的挑戰。

負載均衡

負載均衡最終涉及將應用負載均勻地擴充套件到可變數量的叢集節點上，以便有效利用資源。應用程式服務需是可伸縮的，即使關閉單個節點或元件出現故障仍可訪問。負載均衡與排程相比是另一個不同的挑戰，但這兩個概念具有關聯性。

Kubernetes依靠pod的概念來實現水平伸縮。提示：pod是與在同一主機上執行的應用程式功能相關的容器集合。要實現可伸縮，共享一個公共標籤的多個pod將跨多個叢集主機執行。複製控制器負責確保應用程式中目標數量的pod正在執行，並根據需要建立或銷燬pod，以滿足此目標。每個pod都將在叢集上擁有自己的虛擬IP地址，並可以隨時間而變，這就是服務的切入點。

Kubernetes的服務抽象出一組pod，提供了一個網路端點。因為服務IP地址（如pod）具有僅在群集內可路由的IP，所以服務通常與入口資源耦合，提供了將外部IP地址和埠代理到服務端點的方法。這就使應用程式可用於外部世界。儘管在Kubernetes（包括使用雲提供商提供的負載均衡器）中實現負載均衡有多種方式，但最通常使用的方式是上文介紹的涉及入站和服務的方式。

總結

這一切與排程有什麼關係？如上所述，通過pod的自動可伸縮功能，通過觀察到的CPU使用率動態，Kubernetes可以據此調整由複製控制器管理的pod數量。控制器定期查詢資源指標API以獲取每個pod的利用率，將其與建立自動伸縮控制器時指定的目標CPU利用率進行比較，並根據結果指示覆制控制器來調整pod副本的目標數量。

其結果是負載均衡和排程之間互動作用。當外部客戶端建立負載時，通過入口訪問應用程式服務，pod所使用的CPU將會增加或下降。超出某些閾值，自動伸縮控制器將與複製控制器和排程程式進行互動，根據負載調整pod數量。該服務將會提供修改後的pod數及其位置，因此，pod數可能已經改變的事實對內網客戶和外部客戶來說是透明的。

平衡資源需求與應用需求的微妙之處就在於自動伸縮控制器、複製控制器和Kubernetes排程程式在資源需求、供應、約束和優先順序方面的持續性的互相協調。所有這些都是在客戶端應用程式意識不到的情況下進行的。Kubernetes之所以成為容器化的工作負載領域廣受歡迎的編排解決方案。就在於它能夠高效、透明和可靠地執行這些操作，以便應用程式正常執行。