要完全掌握 Kubernetes，您需要了解擴展叢集資源的不同方法： ，這是 Kubernetes 的主要任務之一。 我們提供了水平和垂直自動擴展以及叢集大小調整機制的高級概述，以及有關如何有效使用它們的建議。
文章 由實現自動縮放的團隊翻譯 .
為什麼考慮擴充很重要
- 資源管理和編排工具。 當然，修補部署、監控和管理 Pod（Pod 是響應請求而啟動的一組容器）等酷炫功能是件好事。
但是，您還應該考慮以下問題：
- 如何擴展模組和應用程式？
- 如何保持容器的運作和高效？
- 如何應對使用者不斷變化的程式碼和工作負載？
配置 Kubernetes 叢集以平衡資源和效能可能具有挑戰性，並且需要了解 Kubernetes 內部工作原理的專業知識。 應用程式或服務的工作負載可能會在一天甚至一個小時內波動，因此最好將平衡視為一個持續的過程。
Kubernetes 自動縮放級別
有效的自動縮放需要兩個層級之間的協調：
- Pod 級別，包括水平（Horizontal Pod Autoscaler，HPA）和垂直自動縮放器（Vertical Pod Autoscaler，VPA）。 這會擴展容器的可用資源。
- 叢集級別，由叢集自動縮放器 (CA) 管理，可增加或減少叢集內的節點數量。
水平自動縮放器 (HPA) 模組
顧名思義，HPA 可擴展 pod 副本的數量。 大多數 DevOps 使用 CPU 和記憶體負載作為更改副本數量的觸發器。 但是，可以根據以下情況擴展系統： ， 他們的 甚至 .
進階HPA操作圖：
- HPA 以預設的 30 秒間隔持續檢查安裝過程中指定的指標值。
- 如果達到指定閾值，HPA 會嘗試增加模組數量。
- HPA 更新部署/複製控制器內的副本數量。
- 然後部署/複製控制器部署任何必要的附加模組。
當達到指標閾值時，HPA 啟動模組部署流程
使用 HPA 時，請考慮以下事項：
- 預設HPA檢查間隔為30秒。 它是由標誌設置的 水平 Pod 自動縮放器同步週期 在控制器管理員中。
- 預設相對誤差為 10%。
- 在上次增加模組數量後，HPA 預計指標將在三分鐘內穩定下來。 此間隔由標誌設置 水平 Pod 自動縮放器放大延遲.
- 最後一次減少模組數量後，HPA 等待五分鐘穩定下來。 此間隔由標誌設置 水平 Pod 自動縮放器縮減延遲.
- HPA 最適合部署物件而不是複製控制器。 水平自動縮放與滾動更新不相容，滾動更新直接操作複製控制器。 對於部署，副本的數量直接取決於部署物件。
Pod 的垂直自動縮放
垂直自動擴展 (VPA) 為現有 Pod 分配更多（或更少）CPU 時間或記憶體。 適用於有狀態或無狀態 Pod，但主要用於有狀態服務。 但是，如果需要自動調整初始分配的資源量，您也可以將 VPA 用於無狀態模組。
VPA 也回應 OOM（記憶體不足）事件。 更改 CPU 時間和記憶體需要重新啟動 Pod。 重新啟動時，VPA 會考慮分配預算（）以確保所需的最小模組數量。
您可以設定每個模組的最小和最大資源。 因此，您可以將分配的最大記憶體量限制為 8 GB。 如果當前節點絕對無法為每個容器分配超過 8 GB 的內存，則這非常有用。 詳細規格和操作機制描述於 .
另外，VPA還有一個有趣的推薦功能（VPA Recommender）。 它監視所有模組的資源使用情況和 OOM 事件，並根據歷史指標的智慧演算法建議新的記憶體和 CPU 時間值。 還有一個 API，它採用 pod 句柄並傳回建議的資源值。
值得注意的是，VPA Recommender 不追蹤資源「限制」。 這可能會導致模組獨佔節點內的資源。 最好在命名空間層級設定限制，以避免大量記憶體或 CPU 消耗。
高階VPA運行方案：
- VPA 以 10 秒的預設間隔連續檢查安裝過程中指定的指標值。
- 如果達到指定的閾值，VPA 會嘗試變更分配的資源量。
- VPA 更新部署/複製控制器內的資源數量。
- 當模組重新啟動時，所有新資源都會套用於建立的實例。
VPA 增加所需的資源量
使用VPA時請記住以下幾點：
- 擴充需要強制重啟 pod。 這是為了避免更改後運行不穩定所必需的。 為了可靠性，模組根據新分配的資源重新啟動並分佈在節點上。
- VPA 和 HPA 尚不相容，無法在同一 Pod 上運作。 如果您在同一叢集中使用兩種擴展機制，請確保您的設定防止它們在同一物件上啟動。
- VPA 僅根據過去和目前的使用情況調整容器對資源的請求。 它不設定資源使用限制。 應用程式可能會出現無法正常運作並開始佔用越來越多資源的問題，這將導致 Kubernetes 關閉此 pod。
- VPA 仍處於開發的早期階段。 請做好準備，系統可能在不久的將來發生一些變化。 您可以閱讀有關 и 。 因此，計劃實現VPA和HPA的聯合運營，以及模組的部署以及針對它們的垂直自動擴展策略（例如，特殊標籤「需要VPA」）。
自動縮放 Kubernetes 集群
Cluster Autoscaler (CA) 根據等待 Pod 的數量來變更節點數量。 系統定期檢查掛起的模組 - 如果需要更多資源且叢集不超過既定限制，則增加叢集大小。 CA 與雲端服務供應商通信，向雲端服務提供者請求額外的節點，或釋放空閒的節點。 CA 的第一個通用版本是在 Kubernetes 1.8 中引入的。
SA操作的高層方案：
- CA 以 10 秒的預設間隔檢查掛起的模組。
- 如果一個或多個 Pod 由於叢集沒有足夠的可用資源來分配而處於備用狀態，它會嘗試配置一個或多個附加節點。
- 當雲端服務供應商分配所需的節點時，它就會加入叢集並準備好為 Pod 提供服務。
- Kubernetes 調度程式將掛起的 pod 分發到新節點。 如果此後某些模組仍處於等待狀態，則重複該程序並將新節點新增至叢集。
在雲端自動配置叢集節點
使用 CA 時請考慮以下事項：
- CA 確保叢集中的所有 Pod 都有運作空間，無論 CPU 負載為何。 它還嘗試確保叢集中沒有不必要的節點。
- CA 在大約 30 秒後註冊需要擴展。
- 一旦不再需要某個節點，CA 預設等待 10 分鐘後再進行系統擴充。
- 自動縮放系統具有擴展器的概念。 這些是選擇將新增節點的一組節點的不同策略。
- 負責任地使用該選項 cluster-autoscaler.kubernetes.io/safe-to-evict (true)。 如果您安裝了許多 Pod，或者其中許多 Pod 分散在所有節點上，那麼您將在很大程度上喪失擴展叢集的能力。
- 使用 以防止 Pod 被刪除，這可能會導致應用程式的某些部分完全損壞。
Kubernetes 自動縮放器如何相互交互
為了完美協調，應在 Pod 層級 (HPA/VPA) 和叢集層級套用自動縮放。 它們之間的交互作用相對簡單：
- HPA 或 VPA 更新 Pod 副本或指派給現有 Pod 的資源。
- 如果沒有足夠的節點用於計劃的擴展，CA 會注意到存在等待狀態的 Pod。
- CA分配新節點。
- 模組被分發到新節點。
協作 Kubernetes 橫向擴充系統
Kubernetes 自動縮放中的常見錯誤
DevOps 在嘗試實現自動縮放時會遇到幾個常見問題。
HPA 和 VPA 取決於指標和一些歷史資料。 如果分配的資源不足，模組將被最小化並且無法產生指標。 在這種情況下，自動縮放將永遠不會發生。
縮放操作本身對時間敏感。 我們希望模組和叢集能夠在用戶注意到任何問題或故障之前快速擴展。 因此，應考慮 Pod 和叢集的平均擴展時間。
理想場景 - 4 分鐘：
- 30秒。 更新目標指標：30−60 秒。
- 30秒。 HPA 檢查指標值：30 秒。
- 不到2秒。 Pod 已建立並進入等待狀態：1 秒。
- 不到2秒。 CA 發現等待模組並向供應節點發送呼叫：1 秒。
- 3分鐘。 雲端提供者分配節點。 K8s 等待直到準備好：最多 10 分鐘（取決於幾個因素）。
最壞的情況（更現實） - 12 分鐘：
- 30秒。 更新目標指標。
- 30秒。 HPA 檢查指標值。
- 不到2秒。 Pod 建立完成並進入 Standby 狀態。
- 不到2秒。 CA 看到等待的模組並發出呼叫來配置節點。
- 10分鐘。 雲端提供者分配節點。 K8s 等待直到它們準備好。 等待時間取決於多種因素，例如供應商延遲、作業系統延遲和支援工具。
不要將雲端提供者的擴展機制與我們的 CA 混淆。 後者在 Kubernetes 叢集內部運行，而雲端提供者引擎則在節點分佈的基礎上運行。 它不知道您的 Pod 或應用程式發生了什麼。 這些系統並行運作。
如何管理 Kubernetes 中的擴展
- Kubernetes 是一種資源管理和編排工具。 管理 Pod 和叢集資源的操作是掌握 Kubernetes 的一個關鍵里程碑。
- 了解 Pod 可擴展性的邏輯，同時考慮 HPA 和 VPA。
- 僅當您充分了解 Pod 和容器的需求時才應使用 CA。
- 為了以最佳方式配置集群，您需要了解不同的擴展系統如何協同工作。
- 在估計擴展時間時，請記住最壞情況和最好情況。
來源： www.habr.com