第 25 章 设置限制范围
25.1. 限制范围的目的
一个限制范围，由 LimitRange 对象定义，在 pod、容器、镜像、镜像流和持久性卷声明一级的一个 项目中枚举的计算资源约束，并指定 pod、容器、镜像、镜像流和持久性卷声明一级可以消耗的资源数量。
要创建和修改资源的所有请求都会针对项目中的每个 LimitRange 对象进行评估。如果资源违反了任何限制，则会拒绝该资源。如果资源没有设置显式值，如果约束支持默认值，则默认值将应用到资源。
对于 CPU 和内存限值，如果您指定一个最大值，但没有指定最小限制，资源会消耗超过最大值的 CPU 和内存资源。
您可以使用临时存储技术预览功能指定临时存储的限值和请求。此功能默认为禁用。要启用此功能，请参阅为临时存储配置。
核心限制范围对象定义
apiVersion: "v1" kind: "LimitRange" metadata: name: "core-resource-limits" 1 spec: limits: - type: "Pod" max: cpu: "2" 2 memory: "1Gi" 3 min: cpu: "200m" 4 memory: "6Mi" 5 - type: "Container" max: cpu: "2" 6 memory: "1Gi" 7 min: cpu: "100m" 8 memory: "4Mi" 9 default: cpu: "300m" 10 memory: "200Mi" 11 defaultRequest: cpu: "200m" 12 memory: "100Mi" 13 maxLimitRequestRatio: cpu: "10" 14
- 1
- 限制范围对象的名称。
- 2
- pod 可在所有容器间请求的最大 CPU 量。
- 3
- pod 可在所有容器间请求的最大内存量。
- 4
- pod 可在所有容器间请求的最小 CPU 量。如果没有设置
min值，或者将min设置为0，则结果为没有限制，pod 消耗的消耗可能会超过maxCPU 值。 - 5
- pod 可在所有容器间请求的最小内存量。如果没有设置
min值，或者将min设置为0，则结果为没有限制，pod 消耗的消耗可能会超过max内存的值。 - 6
- pod 中单个容器可以请求的最大 CPU 量。
- 7
- pod 中单个容器可以请求的最大内存量。
- 8
- pod 中单个容器可以请求的最小 CPU 量。如果没有设置
min值，或者将min设置为0，则结果为没有限制，pod 消耗的消耗可能会超过maxCPU 值。 - 9
- pod 中单个容器可以请求的最小内存量。如果没有设置
min值，或者将min设置为0，则结果为没有限制，pod 消耗的消耗可能会超过max内存的值。 - 10
- 如果没有在 pod 规格中指定限制，则容器的默认 CPU 限值。
- 11
- 如果没有在 pod 规格中指定限制，则容器的默认内存限值。
- 12
- 如果您没有在 pod 规格中指定请求，则容器的默认 CPU 请求。
- 13
- 如果您没有在 pod 规格中指定请求，则容器的默认内存请求。
- 14
- 容器最大的限制与请求的比率。
如需有关如何测量 CPU 和内存的更多信息，请参阅 Compute Resources。
OpenShift Container Platform 限制范围对象定义
apiVersion: "v1"
kind: "LimitRange"
metadata:
name: "openshift-resource-limits"
spec:
limits:
- type: openshift.io/Image
max:
storage: 1Gi 1
- type: openshift.io/ImageStream
max:
openshift.io/image-tags: 20 2
openshift.io/images: 30 3
- type: "Pod"
max:
cpu: "2" 4
memory: "1Gi" 5
ephemeral-storage: "1Gi" 6
max:
cpu: "1" 7
memory: "1Gi" 8
- 1
- 可以推送到内部 registry 的最大镜像大小。
- 2
- 镜像流规格中定义的唯一镜像标签的最大数量。
- 3
- 镜像流状态规格中定义的唯一镜像引用的最大数量。
- 4
- pod 可在所有容器间请求的最大 CPU 量。
- 5
- pod 可在所有容器间请求的最大内存量。
- 6
- 如果启用了临时存储，则 pod 可在所有容器间请求节点的最大临时存储量。
- 7
- pod 可在所有容器间请求的最小 CPU 量。如果确实设置了
min值，或者将min设置为0，则结果为 no limit，pod 可以消耗超过maxCPU 的值。 - 8
- pod 可在所有容器间请求的最小内存量。如果没有设置
min值，或者将min设置为0，则结果为没有限制，pod 消耗的消耗可能会超过max内存的值。
您可以在一个限制范围对象中指定 core 和 OpenShift Container Platform 资源。它们在两个示例中单独显示。
25.1.1. 容器限制
支持的资源：
- CPU
- 内存
支持的限制：
根据容器，如果指定，则必须满足以下条件：
| 约束 | 行为 |
|---|---|
|
|
如果配置定义了 |
|
|
如果配置定义了 |
|
|
如果限制范围定义了
例如，如果容器有 |
支持的默认值：
Default[resource]-
如果无，则默认为
container.resources.limit[resource]作为指定的值。 默认请求[资源]-
如果无，则默认为
container.resources.requests[resource]作为指定的值。
25.1.2. Pod 限制
支持的资源：
- CPU
- 内存
支持的限制：
在 pod 中的所有容器中，需要满足以下条件：
| 约束 | 强制行为 |
|---|---|
|
|
|
|
|
|
|
|
|
25.1.3. 镜像限制
支持的资源：
- 存储
资源类型名称：
-
openshift.io/Image
对于每个镜像，如果指定，则必须满足以下条件：
| 约束 | 行为 |
|---|---|
|
|
|
要防止超过限制的 Blob 上传到 registry，则必须将 registry 配置为强制实施配额。REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA 环境变量必须设置为 true。默认情况下，新部署的环境变量设为 true。
在上传的镜像清单中，镜像大小并非始终可用。这对使用 Docker 1.10 或更高版本构建并推送到 v2 registry 的镜像来说尤为如此。如果这样的镜像使用旧的 Docker 守护进程拉取，镜像清单将由 registry 转换为 schema v1，且不包含所有大小信息。镜像未设置存储限制将阻止镜像被上传。
这个问题正在被决。
25.1.4. 镜像流限值
支持的资源：
-
openshift.io/image-tags -
openshift.io/images
资源类型名称：
-
openshift.io/ImageStream
对于每个镜像流，如果指定，则必须满足以下条件：
| 约束 | 行为 |
|---|---|
|
|
|
|
|
|
25.1.4.1. 镜像参考的计数
openshift.io/image-tags 资源代表唯一镜像引用。可能的引用是 ImageStreamTag、ImageStreamImage 或 DockerImage。可以使用 oc tag 和 oc import-image 命令或使用标签跟踪来创建标签。内部和外部引用之间没有区别。但是，镜像流规格中标记的每个唯一引用仅计算一次。它不以任何方式限制推送到内部容器镜像 registry，但对标签限制很有用。
openshift.io/images 资源代表镜像流状态中记录的唯一镜像名称。它允许对可以推送到内部 registry 的大量镜像进行限制。内部和外部引用无法区分。
25.1.5. PersistentVolumeClaim Limits
支持的资源：
- 存储
支持的限制：
在一个项目中的所有持久性卷声明中，必须满足以下条件：
| 约束 | 强制行为 |
|---|---|
|
| Min[resource] <= claim.spec.resources.requests[resource] (required) |
|
| claim.spec.resources.requests[resource] (required) <= Max[resource] |
限制范围对象定义
{
"apiVersion": "v1",
"kind": "LimitRange",
"metadata": {
"name": "pvcs" 1
},
"spec": {
"limits": [{
"type": "PersistentVolumeClaim",
"min": {
"storage": "2Gi" 2
},
"max": {
"storage": "50Gi" 3
}
}
]
}
}
