摘要：在這種情況下，以防干擾其他集群租戶，調(diào)度器可能會考慮將作為驅(qū)逐的候選對象。其結(jié)果是負(fù)載均衡和調(diào)度之間交互作用。

每當(dāng)談及Kubernetes，我們經(jīng)常聽到諸如資源管理、調(diào)度和負(fù)載均衡等術(shù)語。雖然Kubernetes提供了許多功能，但更關(guān)鍵的還是要了解這些概念，只有這樣才能更好地理解如何放置、管理并恢復(fù)工作負(fù)載。在這篇文章中，我提供了每個功能的概述，并解釋了它們是如何在Kubernetes中實現(xiàn)的，以及它們?nèi)绾蜗嗷プ饔茫蕴峁└咝У娜萜鞴ぷ髫?fù)載管理。

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

資源以它所描述的資源類型的單位來表示。例如，內(nèi)存的字節(jié)數(shù)或計算容量的毫秒級。Kubernetes為定義資源及其各種屬性提供了明確的規(guī)范。

雖然，當(dāng)今使用的主要資源類型是CPU和內(nèi)存，但資源模型是可擴(kuò)展的，允許多種系統(tǒng)以及由用戶自定義的資源類型。其他類型包括網(wǎng)絡(luò)帶寬、網(wǎng)絡(luò)操作和存儲空間。

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

ResourceRequest指的是為容器或Pod請求的一組資源。例如，對于每個Pod實例，一個Pod可以請求1.5個CPU和600MB內(nèi)存。ResourceRequest可以視為描述應(yīng)用服務(wù)對資源的“需求”。

ResourceLimit是指容器或pod可以消耗的組合資源的上限。例如，如果一個pod在運行時使用了超過2.5個CPU或1.2GB的內(nèi)存，我們可能會認(rèn)為它由于內(nèi)存泄漏或其他問題而變得“流氓”了。在這種情況下，以防干擾其他集群租戶，調(diào)度器可能會考慮將pod作為驅(qū)逐的候選對象。

ResourceCapacity規(guī)范描述了集群節(jié)點上可用的資源量。例如，一個物理集群主機可能具有48個內(nèi)核和64GB或RAM。集群可以由具有不同資源容量的節(jié)點組成。容量規(guī)范可以被視為描述資源“供應(yīng)”。

在Kubernetes中，調(diào)度是將pod （由調(diào)度器管理的基本實體）與可用資源相匹配的過程。調(diào)度器考慮資源需求、資源可用性以及其他用戶提供的約束和策略指令，如服務(wù)質(zhì)量、親和性/反親和性需求、數(shù)據(jù)局部性等等。本質(zhì)上，調(diào)度器的作用是將資源“供應(yīng)”匹配到工作負(fù)載“需求”，如下所示:

一些調(diào)度約束（簡稱FitPredicates）是強制性的。例如，如果pod需要具有四個CPU內(nèi)核和2GB內(nèi)存的集群節(jié)點，則該pod將保持在一個暫掛狀態(tài)，直到找到滿足此要求的集群主機為止。

在其他情況下，可能有多個主機滿足強制性標(biāo)準(zhǔn)。在這種情況下，PriorityFunctions被視為反映調(diào)度首選項。基本上，調(diào)度器采用滿足強制性FitPredicates的主機列表，根據(jù)用戶可配置的優(yōu)先級功能的結(jié)果對每個主機打分，并找到滿足最大調(diào)度優(yōu)先級數(shù)量的最佳優(yōu)化配置方案。

在Kubernetes中，工作負(fù)載可以由數(shù)量不定的pod組成，每個pod都具有特定的資源需求。此外，工作負(fù)載和集群都是動態(tài)的，并具有伸縮性和自動擴(kuò)展功能，因此，由于需要調(diào)度程序不斷地重新評估位置決策，pod的數(shù)量可能會發(fā)生變化。另外，由于Kubernetes的功能類似于cron作業(yè)，調(diào)度器需要考慮的不僅是當(dāng)前的供應(yīng)、需求和集群狀態(tài)，還需要考慮未來工作負(fù)載的預(yù)留容量。

把調(diào)度挑戰(zhàn)想象成俄羅斯方塊游戲，理解起來就不會那么難了。我們的目標(biāo)是盡可能緊密地打包所有部分（有效利用資源）。但是，它們是多維的（需要特定的內(nèi)存、CPU、標(biāo)簽選擇器等等），而不是二維的游戲片段（pod）。無法匹配游戲的部分類似于無法運行的應(yīng)用程序。游戲板不是靜態(tài)的，它隨著主機進(jìn)出服務(wù)和服務(wù)規(guī)模的變化而變化。這就是Kubernetes調(diào)度的挑戰(zhàn)。

負(fù)載均衡最終涉及將應(yīng)用負(fù)載均勻地擴(kuò)展到可變數(shù)量的集群節(jié)點上，以便有效利用資源。應(yīng)用程序服務(wù)需是可伸縮的，即使關(guān)閉單個節(jié)點或組件出現(xiàn)故障仍可訪問。負(fù)載均衡與調(diào)度相比是另一個不同的挑戰(zhàn)，但這兩個概念具有關(guān)聯(lián)性。

Kubernetes依靠pod的概念來實現(xiàn)水平伸縮。提示：pod是與在同一主機上運行的應(yīng)用程序功能相關(guān)的容器集合。要實現(xiàn)可伸縮，共享一個公共標(biāo)簽的多個pod將跨多個集群主機運行。復(fù)制控制器負(fù)責(zé)確保應(yīng)用程序中目標(biāo)數(shù)量的pod正在運行，并根據(jù)需要創(chuàng)建或銷毀pod，以滿足此目標(biāo)。每個pod都將在集群上擁有自己的虛擬IP地址，并可以隨時間而變，這就是服務(wù)的切入點。

Kubernetes的服務(wù)抽象出一組pod，提供了一個網(wǎng)絡(luò)端點。因為服務(wù)IP地址（如pod）具有僅在群集內(nèi)可路由的IP，所以服務(wù)通常與入口資源耦合，提供了將外部IP地址和端口代理到服務(wù)端點的方法。這就使應(yīng)用程序可用于外部世界。盡管在Kubernetes（包括使用云提供商提供的負(fù)載均衡器）中實現(xiàn)負(fù)載均衡有多種方式，但最通常使用的方式是上文介紹的涉及入站和服務(wù)的方式。

這一切與調(diào)度有什么關(guān)系？如上所述，通過pod的自動可伸縮功能，通過觀察到的CPU使用率動態(tài)，Kubernetes可以據(jù)此調(diào)整由復(fù)制控制器管理的pod數(shù)量。控制器定期查詢資源指標(biāo)API以獲取每個pod的利用率，將其與創(chuàng)建自動伸縮控制器時指定的目標(biāo)CPU利用率進(jìn)行比較，并根據(jù)結(jié)果指示復(fù)制控制器來調(diào)整pod副本的目標(biāo)數(shù)量。

其結(jié)果是負(fù)載均衡和調(diào)度之間交互作用。當(dāng)外部客戶端創(chuàng)建負(fù)載時，通過入口訪問應(yīng)用程序服務(wù)，pod所使用的CPU將會增加或下降。超出某些閾值，自動伸縮控制器將與復(fù)制控制器和調(diào)度程序進(jìn)行交互，根據(jù)負(fù)載調(diào)整pod數(shù)量。該服務(wù)將會提供修改后的pod數(shù)及其位置，因此，pod數(shù)可能已經(jīng)改變的事實對內(nèi)網(wǎng)客戶和外部客戶來說是透明的。

平衡資源需求與應(yīng)用需求的微妙之處就在于自動伸縮控制器、復(fù)制控制器和Kubernetes調(diào)度程序在資源需求、供應(yīng)、約束和優(yōu)先級方面的持續(xù)性的互相協(xié)調(diào)。所有這些都是在客戶端應(yīng)用程序意識不到的情況下進(jìn)行的。Kubernetes之所以成為容器化的工作負(fù)載領(lǐng)域廣受歡迎的編排解決方案。就在于它能夠高效、透明和可靠地執(zhí)行這些操作，以便應(yīng)用程序正常運行。

了解更多關(guān)于Kubernetes的信息，以及如何在Rancher上實現(xiàn)Kubernetes，可下載電子書《Deploying and Scaling Kubernetes with Rancher》