對於每個 Kubernetes 資源，您可以設定兩種類型的要求 - 請求和限制。 第一個描述了運行容器或 Pod 所需的可用節點資源的最低要求，第二個嚴格限制容器可用的資源。
當 Kubernetes 調度 pod 時，容器有足夠的資源來正常運作非常重要。 如果您打算在資源受限的節點上部署大型應用程序，則該應用程式可能無法執行，因為該節點記憶體不足或 CPU 資源耗盡。 在本文中，我們將了解如何使用資源請求和限制來解決運算能力短缺問題。
請求和限制是 Kubernetes 用於管理 CPU 和記憶體等資源的機制。 請求確保容器接收到所請求的資源。 如果容器請求資源，Kubernetes 只會將其調度到可以提供該資源的節點上。 Limits控制容器請求的資源永遠不會超過某個值。
容器只能將運算能力提高到一定限度，超過限度後運算能力就會受到限制。 讓我們看看它是如何工作的。 因此，有兩種類型的資源：處理器和記憶體。 Kubernetes 排程器使用有關這些資源的資料來決定在哪裡執行 Pod。 Pod 的典型資源規格如下所示。
Pod 中的每個容器都可以設定自己的查詢和限制，這些都是附加的。 處理器資源以毫核為單位定義。 如果您的容器需要兩個完整核心來運行，則將該值設為 2000m。 如果容器只需要1/4核心的功率，則該值為250m。 請記住，如果您指派的 CPU 資源值大於最大節點的核心數，則您的 pod 根本不會被安排啟動。 如果您有一個需要四個核心的 Pod，而 Kubernetes 叢集僅由兩個主虛擬機器組成，也會出現類似的情況。
除非您的應用程式是專門為利用多核心而設計的（例如複雜的科學計算和資料庫操作之類的程式），否則最佳實踐是將CPU 請求設為1 或更低，然後運行更多副本以實現可擴展性。 該解決方案將賦予系統更大的靈活性和可靠性。
當談到 CPU 限制時，事情變得更有趣，因為它被認為是可壓縮資源。 如果您的應用程式開始接近處理器功率限制，Kubernetes 將開始使用 CPU 限制來減慢您的容器 - 降低處理器頻率。 這意味著 CPU 將被人為限制，從而使應用程式的效能可能更差，但進程不會被終止或取出。
記憶體資源以位元組為單位定義。 通常設定中的值以兆位元組 Mib 為單位，但您可以設定從位元組到拍位元組的任何值。 此處的情況與 CPU 相同 - 如果您發出的記憶體量請求大於節點上的記憶體量，則不會安排該 pod 執行。 但與 CPU 資源不同的是，記憶體不會被壓縮，因為無法限制其使用。 因此，一旦超出分配給它的內存，容器的執行就會停止。
請務必記住，您配置的請求不能超出節點可以提供的資源。 GKE 虛擬機器的共享資源規格可以在此影片下面的連結中找到。
在理想情況下，容器的預設設定足以保持工作流程順利運作。 但現實世界並非如此，人們很容易忘記配置資源的使用，或者駭客會設定超出基礎設施實際能力的請求和限制。 為了防止這種情況發生，您可以設定ResourceQuota和LimitRange資源配額。
建立命名空間後，可以使用配額來阻止它。 例如，如果您有 prod 和 dev 命名空間，則模式是根本沒有生產配額，並且有非常嚴格的開發配額。 這使得 prod 在流量急劇激增的情況下可以接管整個可用資源，完全阻塞 dev。
資源配額可能如下所示。 在此範例中，有 4 個部分 - 這些是最後 4 行程式碼。
讓我們逐一看看。 Requests.cpu 是來自命名空間中所有容器的最大組合 CPU 請求數。 在此範例中，您可以有 50 個具有 10m 請求的容器、100 個具有 500m 請求的容器，或只有 500 個具有 XNUMXm 請求的容器。 只要給定命名空間的requests.cpu總數小於XNUMXm，就一切正常。
記憶體請求 requests.memory 是命名空間中所有容器可以擁有的最大組合記憶體請求量。 與前面的情況一樣，只要命名空間中請求的記憶體總量小於 50 MB，您就可以擁有 2 個 20 mib 容器、五個 100 mib 容器或一個 100 mib 容器。
Limits.cpu 是命名空間中所有容器可以使用的最大 CPU 功率組合。 我們可以認為這是處理器功率請求的限制。
最後，limits.memory 是命名空間中所有容器可以使用的最大共享記憶體量。 這是對總記憶體請求的限制。
因此，預設情況下，Kubernetes 叢集中的容器以無限的運算資源運作。 透過資源配額，叢集管理員可以基於命名空間限制資源消耗和資源建立。 在命名空間中，Pod 或容器可以消耗由命名空間資源配額決定的盡可能多的 CPU 功率和記憶體。 然而，人們擔心一個 Pod 或容器可能會壟斷所有可用資源。 為了防止這種情況，使用了限制範圍——一種限制命名空間中資源分配（針對 Pod 或容器）的策略。
限制範圍提供的限制可以：
- 確保命名空間中每個模組或容器計算資源的最小和最大使用量；
- 對命名空間中的每個 PersistentVolumeClaim 強制執行最小和最大 Starage Request 儲存請求；
- 強制命名空間中資源的請求與限制之間的關係；
- 為命名空間中的計算資源設定預設請求/限制，並在運行時自動將它們注入到容器中。
這樣您就可以在命名空間中建立限制範圍。 與適用於整個命名空間的配額不同，限制範圍適用於單一容器。 這可以防止使用者在命名空間內創建非常小的或相反的巨大容器。 極限範圍可能如下所示。
與前面的情況一樣，這裡可以區分出 4 個部分。 讓我們逐一看看。
default 部分設定 pod 中容器的預設限制。 如果將這些值設為極限範圍，則任何尚未明確設定這些值的容器都將遵循預設值。
預設請求部分defaultRequest配置Pod中容器的預設請求。 同樣，如果將這些值設為極限範圍，則任何未明確設定這些選項的容器都會預設為這些值。
max 部分指定可以為 pod 中的容器設定的最大限制。 預設部分和容器限制中的值不能設定超過此限制。 需要注意的是，如果該值設為 max 並且沒有預設部分，則最大值將成為預設值。
min 部分指定可以為 pod 中的容器設定的最小請求。 但是，容器的預設部分和查詢中的值不能設定低於此限制。
再次需要注意的是，如果設定了該值，而預設值未設置，則最小值將成為預設提示。
這些資源請求最終由 Kubernetes 調度程式用來執行您的工作負載。 為了正確配置容器，了解其工作原理非常重要。 假設您想在叢集中執行多個 Pod。 假設 Pod 規範有效，Kubernetes 調度將使用循環平衡來選擇一個節點來運行工作負載。
Kubernetes 將檢查節點 1 是否有足夠的資源來滿足 pod 容器的請求，如果沒有，它將轉移到下一個節點。 如果系統中沒有一個節點能夠滿足要求，Pod 將進入 Pending 狀態。 使用 Google Kubernetes 引擎功能（例如節點自動縮放），GKE 可以自動偵測等待狀態並建立更多節點。
如果您隨後耗盡了節點容量，自動擴展將減少節點數量以節省金錢。 這就是 Kubernetes 根據請求來調度 pod 的原因。 然而，限制可能高於請求，在某些情況下，節點實際上可能會耗盡資源。 我們稱這種狀態為過度承諾狀態。
正如我所說，當涉及到 CPU 時，Kubernetes 將開始限制 Pod。 每個 pod 將接收其請求的數量，但如果未達到限制，將開始套用限制。
當涉及記憶體資源時，Kubernetes 被迫決定刪除哪些 pod，保留哪些 pod，直到釋放系統資源，否則整個系統將崩潰。
讓我們想像一個場景，如果您的機器記憶體不足 - Kubernetes 將如何處理？
Kubernetes 將尋找使用的資源多於其請求的 pod。 因此，如果您的容器根本沒有請求，這意味著它們預設使用超出其要求的數量，只是因為它們根本沒有要求任何東西！ 此類容器成為關閉的主要候選者。 下一個候選者是已滿足所有請求但仍低於最大限制的容器。
因此，如果 Kubernetes 發現多個 pod 超出了其請求參數，它會按優先順序對它們進行排序，然後刪除優先順序最低的 pod。 如果所有 pod 都有相同的優先權，那麼 Kubernetes 將終止那些比其他 pod 超出其請求次數更多的 pod。
在極少數情況下，Kubernetes 可能會中止仍在其請求範圍內的 pod。 當關鍵系統元件（例如 Kubelet 代理程式或 Docker）開始消耗比為其保留的資源更多的資源時，就會發生這種情況。
所以，在小公司的早期階段，Kubernetes 叢集可以在不設定資源請求和限制的情況下正常運作，但隨著你的團隊和專案開始規模成長，你就有在這方面遇到問題的風險。 為模組和命名空間添加查詢和約束只需很少的額外工作，並且可以節省很多麻煩。
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com