我正在運行一個跨團隊共享的集群，我想保證每個團隊擁有最少量的資源，尤其是記憶體。
繼指示我嘗試在其名稱空間上使用以下內容：
apiVersion: v1
kind: ResourceQuota
metadata:
name: mem-quota
spec:
hard:
requests.memory: 8Gb
然而，透過閱讀更多文檔，我們發現這並不能保證他們的 pod 擁有 8Gb 記憶體。這只是意味著它們的 pod 值總和requests.memory不能超過 8Gb。他們可能會像上面那樣設定 8Gb，只使用 4Gb，並且如果叢集在其他地方已達到最大容量且無法調度新 Pod，則無法建立新 Pod。
又例如，我可以在總記憶體只有 8Gi 的叢集上建立一個值為 16Gi 的叢集ResourceQuota。requests.memory
是否有辦法保證團隊有固定數量的記憶體僅供他們使用？
答案1
這只是意味著它們的 pod 請求總和。
是的，這就是ResourceQuota 的邏輯。從了解資源配額：
資源配額的工作原理如下：
使用者將運算資源請求放在他們的 Pod 上。同一命名空間中所有 Pod 的所有資源請求總和不得超過該命名空間的任何資源配額文件中的任何硬資源限制。請注意，我們過去透過取得 pod 的資源限制總和來驗證資源配額，但這已更改為使用資源請求。保留了先前建立的那些 pod 的向後相容性，因為僅指定資源限制的 pod 的資源請求預設符合其定義的限制。使用者只需為他們在資源配額中請求的資源及其限制付費，因為請求是叢集在調度期間保證的最小資源量。有關過度提交的更多信息，請參閱計算資源。
如果建立 Pod 會導致命名空間超出該命名空間的資源配額中指定的任何限制，則請求將失敗，並顯示 HTTP 狀態碼 403 FORBIDDEN。
如果在命名空間中啟用了配額，且使用者未在 pod 上為啟用了配額的每個資源指定請求，則 pod 的 POST 將失敗，並顯示 HTTP 狀態代碼 403 FORBIDDEN。提示：在檢查配額之前，使用 LimitRange 准入控制器強制限制預設值（那麼預設情況下資源請求將等於限制，請參閱准入控制器）以避免此問題。
然而，文章擴展了一些情況，您需要單獨劃分資源。這不是已經實施的事情..
配額和叢集容量： 有時可能需要更複雜的策略，例如：
- 按比例將叢集總資源分配給多個團隊。
- 允許每個租戶根據需要增加資源使用量，但有一個慷慨的限制以防止意外資源耗盡。
- 偵測來自一個命名空間的需求、新增節點並增加配額。
此類策略可以使用 ResourceQuota 作為建置區塊來實現，透過編寫一個「控制器」來監視配額使用情況並根據其他訊號調整每個命名空間的配額硬限制。
我希望您需要在自己的控制器中編寫自訂邏輯。