跳至主要内容

資源配額

ResourceQuota 用於限制命名空間內的資源使用量。它幫助管理員控制和限制叢集資源的分配，以確保命名空間之間資源分配的公平性和可控性。

在 Harvester 中，ResourceQuota 可以定義以下資源的使用限制：

  • CPU： 限制運算資源的使用量，包括 CPU 核心數和 CPU 時間。
  • 記憶體： 限制記憶體資源的使用量，以位元組或其他可識別的記憶體單位表示。
  • 儲存： 限制儲存資源的使用量。

透過 Rancher 設定 ResourceQuota​

在 Rancher UI 中，管理員可以透過以下步驟為命名空間設定資源配額：

  1. 點擊漢堡選單並選擇 Virtualization Management 標籤頁。

  2. 選擇其中一個叢集，然後前往 Projects/Namespaces > Create Project。

  3. 指定所需的專案 Name。接下來，前往 Resource Quotas 標籤頁並選擇 Add Resource 選項。在 Resource Type 欄位中，選擇 CPU Limit 或 Memory Limit，並定義 Project Limit 和 Namespace Default Limit 的值。

備註

VM Default Resource Limit 用於為命名空間內執行的 pod 設定運算資源的預設請求/限制，使用 Kubernetes LimitRange API。資源的 reservation 和 limit 值對應於命名空間 LimitRange 設定的 defaultRequest 和 default 限制。這些設定僅適用於 pod 工作負載。

這些設定將在未來移除。請參閱 issue https://github.com/harvester/harvester/issues/5652。

您可以按照以下方式設定 Namespace 限制：

  1. 找到新建立的專案，然後選擇 Create Namespace。

  2. 指定所需的命名空間 Name，並調整限制。

  3. 選擇 Create 完成流程。

備註

當達到資源配額時，嘗試為客體叢集佈建 VM 會被阻擋。Rancher 會透過在迴圈中建立新 VM 來回應，每次建立 VM 失敗後會立即進行另一次建立嘗試。這會導致叢集出現暫時性錯誤狀態，但由於 VM 正在重新建立，該錯誤不會被記錄。

important
  • 由於虛擬機器的額外記憶體開銷，每個 VM 需要一些額外的記憶體才能運作。設定 Memory Limit 時應考慮到這一點。例如，當專案的 Memory Limit 為 24 Gi 時，無法執行 3 個各有 8 Gi 記憶體的 VM。此連結包含一個表格，顯示 VM 的最終記憶體是如何計算的。
  • 當您計劃將 Harvester 設定 additional-guest-memory-overhead-ratio 變更為更大的值時，請記得檢視 ResourceQuota 值並相應地更新它們。您需要調整這兩個參數，以確保 ResourceQuota 可以容納具有新額外記憶體開銷的原始 VM 數量。

虛擬機器的額外記憶體開銷​

建立虛擬機器（VM）時，VM 控制器會無縫地將額外資源整合到 VM 的設定中。這些額外資源旨在保證 VM 的一致且不間斷的運作。需要注意的是，設定記憶體限制需要更高的記憶體保留，因為包含了這些額外資源。

例如，考慮使用以下設定建立一個新 VM：

  • CPU：8 核心
  • 記憶體：16Gi
備註

作業系統（無論是 Linux 還是 Windows）不會影響額外開銷的計算。

記憶體開銷在以下部分計算：

  • 記憶體頁表開銷： 這為每 512b RAM 大小計算一個位元。例如，16Gi 的記憶體需要 32Mi 的開銷。
  • VM 固定開銷： 這由多個組件組成：
    • VirtLauncherMonitorOverhead：25Mi（virt-launcher-monitor 的 ps RSS）
    • VirtLauncherOverhead：100Mi（virt-launcher 程序的 ps RSS）
    • VirtlogdOverhead：20Mi（virtlogd 的 ps RSS）
    • VirtqemudOverhead：35Mi（virtqemud 的 ps RSS）
    • QemuOverhead：30Mi（qemu 的 ps RSS，減去其（壓力測試）客體的 RAM，減去虛擬頁表）
  • 每個 CPU（vCPU）8Mi 開銷： 此外，每個 vCPU 增加 8Mi 的開銷，以及為 IOThread 增加固定的 8Mi 開銷。
  • 額外增加的開銷： 這包含各種因素，如視訊 RAM 開銷和架構開銷。更多詳細資訊請參閱 Additional Overhead。
  • additional-guest-memory-overhead-ratio 使用者可以透過 Harvester 設定 additional-guest-memory-overhead-ratio 進一步調整 Memory Overhead，預設值為 "1.5"。此設定對於 VM 消除發生 OOM（記憶體不足）的機會非常重要。

此計算顯示 VM 執行個體需要大約 380Mi 的額外記憶體開銷。

更多資訊請參閱 Memory Overhead。

有關 Kubevirt 中如何計算記憶體開銷的更多資訊，請參閱原始碼 GetMemoryOverhead。

備註

Overhead Memory 在不同的 Harvester 版本（具有不同的 Kubevirt 版本）之間會有所不同，因為所有這些支援元件都在不斷新增新功能和修復錯誤，它們需要更多記憶體。

遷移期間自動調整 ResourceQuota​

當由 ResourceQuota 物件控制的已分配資源配額達到限制時，遷移 VM 變得不可行。遷移程序會自動建立一個與來源 VM 資源需求相同的新 pod。如果這些 pod 建立的先決條件超過了定義的配額，遷移操作將無法進行。

自 v1.2.0 起可用

在 Harvester 中，ResourceQuota 值會在遷移前動態擴展，以容納目標虛擬機器的資源需求。遷移後，ResourceQuota 將恢復為先前的設定。

請注意 ResourceQuota 自動調整大小的以下限制：

  • 在 VM 遷移期間無法變更 ResourceQuota。

  • 當提高 ResourceQuota 值時，如果您建立、啟動或還原其他 VM，Harvester 將根據原始 ResourceQuota 驗證資源是否足夠。如果條件不符合，系統將警告遷移程序不可行。

  • 擴展 ResourceQuota 後，非 VM pod 和 VM pod 之間可能會發生潛在的資源競爭，導致遷移失敗。因此，不建議將自訂容器工作負載和 VM 部署到同一命名空間。

  • 由於 webhook 驗證器的並發限制，VM 控制器將執行二次驗證以確認資源是否足夠。如果資源不足，它將自動將 VM 的 RunStrategy 設定為 Halted，並在 VM 物件中新增一個新的 annotation harvesterhci.io/insufficient-resource-quota，通知您 VM 因資源不足而被關閉。

停用遷移期間自動調整 ResourceQuota​

自 v1.4.2 起可用

當 ResourceQuota 物件具有 annotation harvesterhci.io/skipResourceQuotaAutoScaling: "true" 時，Harvester 不會自動調整該物件的值。此功能對於除錯、故障排除和其他任務非常有用。

important

您必須在遷移開始前設定 annotation。如果在值已經被調整時才設定 annotation，Harvester 將無法自動恢復先前的設定。