限制範圍
預設情況下,容器在 Kubernetes 叢集上執行,其計算資源不受限制。透過使用 Kubernetes 資源配額,管理員(也稱為_叢集操作員_)可以限制在特定名稱空間內叢集資源的消耗和建立(例如 CPU 時間、記憶體和持久儲存)。在一個名稱空間內,Pod 可以消耗該名稱空間適用的資源配額所允許的任意多的 CPU 和記憶體。作為叢集操作員或名稱空間級管理員,你可能還會關注確保單個物件不會獨佔名稱空間內的所有可用資源。
LimitRange 是一種策略,用於限制你在名稱空間中為每個適用的物件型別(例如 Pod 或PersistentVolumeClaim)指定的資源分配(限制和請求)。
_LimitRange_ 提供了以下限制:
- 在名稱空間中強制執行每個 Pod 或容器的最小和最大計算資源使用量。
- 在名稱空間中強制執行每個PersistentVolumeClaim 的最小和最大儲存請求。
- 在名稱空間中強制執行資源的請求與限制之間的比率。
- 為名稱空間中的計算資源設定預設請求/限制,並在執行時自動將其注入容器。
只要名稱空間中至少存在一個 LimitRange 物件,Kubernetes 就會限制該特定名稱空間中 Pod 的資源分配。
LimitRange 物件的名稱必須是有效的DNS 子域名。
資源限制和請求的約束
- 管理員在名稱空間中建立 LimitRange。
- 使用者在該名稱空間中建立(或嘗試建立)物件,例如 Pod 或 PersistentVolumeClaim。
- 首先,LimitRange Admission Controller 會為所有未設定計算資源要求的 Pod(及其容器)應用預設的請求和限制值。
- 其次,LimitRange 會跟蹤使用情況,以確保它不超過名稱空間中存在的任何 LimitRange 中定義的資源最小值、最大值和比率。
- 如果你嘗試建立或更新違反 LimitRange 約束的物件(Pod 或 PersistentVolumeClaim),則對 API 伺服器的請求將失敗,並返回 HTTP 狀態碼
403 Forbidden
以及一條解釋所違反約束的訊息。 - 如果你在名稱空間中新增適用於計算相關資源(例如
cpu
和memory
)的 LimitRange,則必須為這些值指定請求或限制。否則,系統可能會拒絕 Pod 的建立。 - LimitRange 驗證僅發生在 Pod 准入階段,而不是對正在執行的 Pod 進行驗證。如果你新增或修改 LimitRange,該名稱空間中已存在的 Pod 將保持不變。
- 如果名稱空間中存在兩個或更多 LimitRange 物件,則應用的預設值是不確定的。
LimitRange 和 Pod 的准入檢查
LimitRange 不檢查其應用的預設值的一致性。這意味著 LimitRange 設定的_限制_預設值可能小於客戶端提交到 API 伺服器的 spec 中為容器指定的_請求_值。如果發生這種情況,最終的 Pod 將無法排程。
例如,你使用以下清單定義一個 LimitRange:
注意
由於未定義名稱空間引數且 LimitRange 範圍僅限於名稱空間級別,因此以下示例將在叢集的預設名稱空間中執行。這意味著這些示例中的任何引用或操作都將與叢集預設名稱空間中的元素進行互動。你可以透過配置metadata.namespace
欄位中的名稱空間來覆蓋操作名稱空間。apiVersion: v1
kind: LimitRange
metadata:
name: cpu-resource-constraint
spec:
limits:
- default: # this section defines default limits
cpu: 500m
defaultRequest: # this section defines default requests
cpu: 500m
max: # max and min define the limit range
cpu: "1"
min:
cpu: 100m
type: Container
以及一個宣告 CPU 資源請求為 700m
但未設定限制的 Pod
apiVersion: v1
kind: Pod
metadata:
name: example-conflict-with-limitrange-cpu
spec:
containers:
- name: demo
image: registry.k8s.io/pause:3.8
resources:
requests:
cpu: 700m
那麼該 Pod 將無法排程,並出現類似於以下的錯誤:
Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit
如果你同時設定了 request
和 limit
,即使存在相同的 LimitRange,新的 Pod 也會成功排程。
apiVersion: v1
kind: Pod
metadata:
name: example-no-conflict-with-limitrange-cpu
spec:
containers:
- name: demo
image: registry.k8s.io/pause:3.8
resources:
requests:
cpu: 700m
limits:
cpu: 700m
資源約束示例
可以使用 LimitRange 建立的策略示例包括:
- 在一個容量為 8 GiB RAM 和 16 核的 2 節點叢集中,限制名稱空間中的 Pod 請求 100m CPU,最大限制為 500m CPU;請求 200Mi 記憶體,最大限制為 600Mi 記憶體。
- 對於在其 spec 中未設定 CPU 和記憶體請求的容器,將預設 CPU 限制和請求定義為 150m,將記憶體預設請求定義為 300Mi。
如果名稱空間的總限制小於 Pod/容器的限制之和,則可能會出現資源爭用。在這種情況下,容器或 Pod 將不會被建立。
資源爭用或對 LimitRange 的更改都不會影響已建立的資源。
下一步
有關使用限制的示例,請參閱:
- 如何配置每個名稱空間的最小和最大 CPU 約束.
- 如何配置每個名稱空間的最小和最大記憶體約束.
- 如何配置每個名稱空間的預設 CPU 請求和限制.
- 如何配置每個名稱空間的預設記憶體請求和限制.
- 如何配置每個名稱空間的最小和最大儲存消耗.
- 有關配置每個名稱空間配額的詳細示例。
請參閱LimitRanger 設計文件以獲取背景和歷史資訊。