Kubernetes容器編排的三大支柱
資源管理、調度和負載均衡作為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 （由調度器管理的基本實體）與可用資源相匹配的過程。調度器考慮資源需求、資源可用性以及其他用戶提供的約束和策略指令，如服務質量、親和性/反親和性需求、數據局部性等等。本質上，調度器的作用是將資源“供應”匹配到工作負載“需求”，如下所示:
Kubernetes容器編排的三大支柱
一些調度約束（簡稱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之所以成為容器化的工作負載領域廣受歡迎的編排解決方案。就在于它能夠高效、透明和可靠地執行這些操作，以便應用程序正常運行。
