Kubernetes容器編排的三大支柱
資源管理、調(diào)度和負(fù)載均衡作為K8s的三大支柱，它們是如何在K8s中實(shí)現(xiàn)的？它們又是如何相互作用，以提供高效的容器工作負(fù)載管理的？
每當(dāng)談及Kubernetes，我們經(jīng)常聽到諸如資源管理、調(diào)度和負(fù)載均衡等術(shù)語。雖然Kubernetes提供了許多功能，但更關(guān)鍵的還是要了解這些概念，只有這樣才能更好地理解如何放置、管理并恢復(fù)工作負(fù)載。在這篇文章中，我提供了每個(gè)功能的概述，并解釋了它們是如何在Kubernetes中實(shí)現(xiàn)的，以及它們?nèi)绾蜗嗷プ饔?，以提供高效的容器工作?fù)載管理。
資源管理
資源管理是對基礎(chǔ)設(shè)施資源的有效配置。在Kubernetes中，資源可以通過容器或pod來請求、分配或消耗。擁有一個(gè)通用的資源管理模型是非常必要的，因?yàn)樵贙ubernetes中，包括調(diào)度器、負(fù)載均衡器、工作池管理器甚至應(yīng)用程序本身的許多組件，都需要有資源意識。如果資源利用不足，這就意味著浪費(fèi)，意味著成本效益低下。如果資源被過度訂購，可能會導(dǎo)致應(yīng)用程序故障、停機(jī)或錯誤的SLA等。
資源以它所描述的資源類型的單位來表示。例如，內(nèi)存的字節(jié)數(shù)或計(jì)算容量的毫秒級。Kubernetes為定義資源及其各種屬性提供了明確的規(guī)范。
雖然，當(dāng)今使用的主要資源類型是CPU和內(nèi)存，但資源模型是可擴(kuò)展的，允許多種系統(tǒng)以及由用戶自定義的資源類型。其他類型包括網(wǎng)絡(luò)帶寬、網(wǎng)絡(luò)操作和存儲空間。
資源規(guī)格在不同的環(huán)境下具有不同的含義。在Kubernetes中指定資源的三種主要方式如下：
ResourceRequest指的是為容器或Pod請求的一組資源。例如，對于每個(gè)Pod實(shí)例，一個(gè)Pod可以請求1.5個(gè)CPU和600MB內(nèi)存。ResourceRequest可以視為描述應(yīng)用服務(wù)對資源的“需求”。
ResourceLimit是指容器或pod可以消耗的組合資源的上限。例如，如果一個(gè)pod在運(yùn)行時(shí)使用了超過2.5個(gè)CPU或1.2GB的內(nèi)存，我們可能會認(rèn)為它由于內(nèi)存泄漏或其他問題而變得“流氓”了。在這種情況下，以防干擾其他集群租戶，調(diào)度器可能會考慮將pod作為驅(qū)逐的候選對象。
ResourceCapacity規(guī)范描述了集群節(jié)點(diǎn)上可用的資源量。例如，一個(gè)物理集群主機(jī)可能具有48個(gè)內(nèi)核和64GB或RAM。集群可以由具有不同資源容量的節(jié)點(diǎn)組成。容量規(guī)范可以被視為描述資源“供應(yīng)”。
調(diào)度
在Kubernetes中，調(diào)度是將pod （由調(diào)度器管理的基本實(shí)體）與可用資源相匹配的過程。調(diào)度器考慮資源需求、資源可用性以及其他用戶提供的約束和策略指令，如服務(wù)質(zhì)量、親和性/反親和性需求、數(shù)據(jù)局部性等等。本質(zhì)上，調(diào)度器的作用是將資源“供應(yīng)”匹配到工作負(fù)載“需求”，如下所示:
Kubernetes容器編排的三大支柱
一些調(diào)度約束（簡稱FitPredicates）是強(qiáng)制性的。例如，如果pod需要具有四個(gè)CPU內(nèi)核和2GB內(nèi)存的集群節(jié)點(diǎn)，則該pod將保持在一個(gè)暫掛狀態(tài)，直到找到滿足此要求的集群主機(jī)為止。
在其他情況下，可能有多個(gè)主機(jī)滿足強(qiáng)制性標(biāo)準(zhǔn)。在這種情況下，PriorityFunctions被視為反映調(diào)度***項(xiàng)?；旧?，調(diào)度器采用滿足強(qiáng)制性FitPredicates的主機(jī)列表，根據(jù)用戶可配置的優(yōu)先級功能的結(jié)果對每個(gè)主機(jī)打分，并找到滿足***調(diào)度優(yōu)先級數(shù)量的***優(yōu)化配置方案。
在Kubernetes中，工作負(fù)載可以由數(shù)量不定的pod組成，每個(gè)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ùn)行的應(yīng)用程序。游戲板不是靜態(tài)的，它隨著主機(jī)進(jìn)出服務(wù)和服務(wù)規(guī)模的變化而變化。這就是Kubernetes調(diào)度的挑戰(zhàn)。
負(fù)載均衡
負(fù)載均衡最終涉及將應(yīng)用負(fù)載均勻地?cái)U(kuò)展到可變數(shù)量的集群節(jié)點(diǎn)上，以便有效利用資源。應(yīng)用程序服務(wù)需是可伸縮的，即使關(guān)閉單個(gè)節(jié)點(diǎn)或組件出現(xiàn)故障仍可訪問。負(fù)載均衡與調(diào)度相比是另一個(gè)不同的挑戰(zhàn)，但這兩個(gè)概念具有關(guān)聯(lián)性。
Kubernetes依靠pod的概念來實(shí)現(xiàn)水平伸縮。提示：pod是與在同一主機(jī)上運(yùn)行的應(yīng)用程序功能相關(guān)的容器集合。要實(shí)現(xiàn)可伸縮，共享一個(gè)公共標(biāo)簽的多個(gè)pod將跨多個(gè)集群主機(jī)運(yùn)行。復(fù)制控制器負(fù)責(zé)確保應(yīng)用程序中目標(biāo)數(shù)量的pod正在運(yùn)行，并根據(jù)需要創(chuàng)建或銷毀pod，以滿足此目標(biāo)。每個(gè)pod都將在集群上擁有自己的虛擬IP地址，并可以隨時(shí)間而變，這就是服務(wù)的切入點(diǎn)。
Kubernetes的服務(wù)抽象出一組pod，提供了一個(gè)網(wǎng)絡(luò)端點(diǎn)。因?yàn)榉?wù)IP地址（如pod）具有僅在群集內(nèi)可路由的IP，所以服務(wù)通常與入口資源耦合，提供了將外部IP地址和端口代理到服務(wù)端點(diǎn)的方法。這就使應(yīng)用程序可用于外部世界。盡管在Kubernetes（包括使用云提供商提供的負(fù)載均衡器）中實(shí)現(xiàn)負(fù)載均衡有多種方式，但最通常使用的方式是上文介紹的涉及入站和服務(wù)的方式。
總結(jié)
這一切與調(diào)度有什么關(guān)系？如上所述，通過pod的自動可伸縮功能，通過觀察到的CPU使用率動態(tài)，Kubernetes可以據(jù)此調(diào)整由復(fù)制控制器管理的pod數(shù)量。控制器定期查詢資源指標(biāo)API以獲取每個(gè)pod的利用率，將其與創(chuàng)建自動伸縮控制器時(shí)指定的目標(biāo)CPU利用率進(jìn)行比較，并根據(jù)結(jié)果指示復(fù)制控制器來調(diào)整pod副本的目標(biāo)數(shù)量。
其結(jié)果是負(fù)載均衡和調(diào)度之間交互作用。當(dāng)外部客戶端創(chuàng)建負(fù)載時(shí)，通過入口訪問應(yīng)用程序服務(wù)，pod所使用的CPU將會增加或下降。超出某些閾值，自動伸縮控制器將與復(fù)制控制器和調(diào)度程序進(jìn)行交互，根據(jù)負(fù)載調(diào)整pod數(shù)量。該服務(wù)將會提供修改后的pod數(shù)及其位置，因此，pod數(shù)可能已經(jīng)改變的事實(shí)對內(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)用程序正常運(yùn)行。
