@@ -103,13 +103,15 @@ Neither contention nor changes to quota will affect already created resources.
103
103
## Enabling Resource Quota
104
104
105
105
Resource Quota support is enabled by default for many Kubernetes distributions. It is
106
- enabled when the API server `--enable-admission-plugins=` flag has `ResourceQuota` as
106
+ enabled when the {{< glossary_tooltip text=" API server" term_id="kube-apiserver" >}} `--enable-admission-plugins=` flag has `ResourceQuota` as
107
107
one of its arguments.
108
108
-->
109
109
## 启用资源配额
110
110
111
- 资源配额的支持在很多 Kubernetes 版本中是默认开启的。当 API 服务器的 ` --enable-admission-plugins= `
112
- 参数中包含 ` ResourceQuota ` 时,资源配额会被启用。
111
+ 资源配额的支持在很多 Kubernetes 版本中是默认启用的。
112
+ 当 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}
113
+ 的命令行标志 ` --enable-admission-plugins= ` 中包含 ` ResourceQuota ` 时,
114
+ 资源配额会被启用。
113
115
114
116
<!--
115
117
A resource quota is enforced in a particular namespace when there is a
@@ -245,6 +247,16 @@ In release 1.8, quota support for local ephemeral storage is added as an alpha f
245
247
| ` limits.ephemeral-storage ` | 在命名空间的所有 Pod 中,本地临时存储限制值的总和不能超过此值。 |
246
248
| ` ephemeral-storage ` | 与 ` requests.ephemeral-storage ` 相同。 |
247
249
250
+ {{< note >}}
251
+ <!--
252
+ When using a CRI container runtime, container logs will count against the ephemeral storage quota. This can result in the unexpected eviction of pods that have exhausted their storage quotas. Refer to [Logging Architecture](/docs/concepts/cluster-administration/logging/) for details.
253
+ -->
254
+ 如果所使用的是 CRI 容器运行时,容器日志会被计入临时存储配额。
255
+ 这可能会导致存储配额耗尽的 Pods 被意外地驱逐出节点。
256
+ 参考[ 日志架构] ( /zh/docs/concepts/cluster-administration/logging/ )
257
+ 了解详细信息。
258
+ {{< /note >}}
259
+
248
260
<!--
249
261
## Object Count Quota
250
262
@@ -371,6 +383,7 @@ Resources specified on the quota outside of the allowed set results in a validat
371
383
| `BestEffort` | Match pods that have best effort quality of service. |
372
384
| `NotBestEffort` | Match pods that do not have best effort quality of service. |
373
385
| `PriorityClass` | Match pods that references the specified [priority class](/docs/concepts/configuration/pod-priority-preemption). |
386
+ | `CrossNamespacePodAffinity` | Match pods that have cross-namespace pod [(anti)affinity terms](/docs/concepts/scheduling-eviction/assign-pod-node). |
374
387
-->
375
388
| 作用域 | 描述 |
376
389
| ----- | ----------- |
@@ -379,6 +392,7 @@ Resources specified on the quota outside of the allowed set results in a validat
379
392
| ` BestEffort ` | 匹配所有 Qos 是 BestEffort 的 Pod。 |
380
393
| ` NotBestEffort ` | 匹配所有 Qos 不是 BestEffort 的 Pod。 |
381
394
| ` PriorityClass ` | 匹配所有引用了所指定的[ 优先级类] ( /zh/docs/concepts/configuration/pod-priority-preemption ) 的 Pods。 |
395
+ | ` CrossNamespacePodAffinity ` | 匹配那些设置了跨名字空间 [ (反)亲和性条件] ( /zh/docs/concepts/scheduling-eviction/assign-pod-node ) 的 Pod。 |
382
396
383
397
<!--
384
398
The `BestEffort` scope restricts a quota to tracking the following resource:
@@ -684,12 +698,105 @@ pods 0 10
684
698
```
685
699
686
700
<!--
687
- ## Requests vs Limits
701
+ ### Cross-namespace Pod Affinity Quota
702
+ -->
703
+ ### 跨名字空间的 Pod 亲和性配额 {#cross-namespace-pod-affinity-quota}
704
+
705
+ {{< feature-state for_k8s_version="v1.21" state="alpha" >}}
706
+
707
+ <!--
708
+ Operators can use `CrossNamespacePodAffinity` quota scope to limit which namespaces are allowed to
709
+ have pods with affinity terms that cross namespaces. Specifically, it controls which pods are allowed
710
+ to set `namespaces` or `namespaceSelector` fields in pod affinity terms.
711
+ -->
712
+ 集群运维人员可以使用 `CrossNamespacePodAffinity` 配额作用域来
713
+ 限制哪个名字空间中可以存在包含跨名字空间亲和性规则的 Pod。
714
+ 更为具体一点,此作用域用来配置哪些 Pod 可以在其 Pod 亲和性规则
715
+ 中设置 `namespaces` 或 `namespaceSelector` 字段。
716
+
717
+ <!--
718
+ Preventing users from using cross-namespace affinity terms might be desired since a pod
719
+ with anti-affinity constraints can block pods from all other namespaces
720
+ from getting scheduled in a failure domain.
721
+ -->
722
+ 禁止用户使用跨名字空间的亲和性规则可能是一种被需要的能力,因为带有
723
+ 反亲和性约束的 Pod 可能会阻止所有其他名字空间的 Pod 被调度到某失效域中。
724
+
725
+ <!--
726
+ Using this scope operators can prevent certain namespaces (`foo-ns` in the example below)
727
+ from having pods that use cross-namespace pod affinity by creating a resource quota object in
728
+ that namespace with `CrossNamespaceAffinity` scope and hard limit of 0:
729
+ -->
730
+ 使用此作用域操作符可以避免某些名字空间(例如下面例子中的 `foo-ns`)运行
731
+ 特别的 Pod,这类 Pod 使用跨名字空间的 Pod 亲和性约束,在该名字空间中创建
732
+ 了作用域为 `CrossNamespaceAffinity` 的、硬性约束为 0 的资源配额对象。
733
+
734
+ ```yaml
735
+ apiVersion: v1
736
+ kind: ResourceQuota
737
+ metadata:
738
+ name: disable-cross-namespace-affinity
739
+ namespace: foo-ns
740
+ spec:
741
+ hard:
742
+ pods: "0"
743
+ scopeSelector:
744
+ matchExpressions:
745
+ - scopeName: CrossNamespaceAffinity
746
+ ```
747
+
748
+ <!--
749
+ If operators want to disallow using `namespaces` and `namespaceSelector` by default, and
750
+ only allow it for specific namespaces, they could configure `CrossNamespaceAffinity`
751
+ as a limited resource by setting the kube-apiserver flag -admission-control-config-file
752
+ to the path of the following configuration file:
753
+ -->
754
+ 如果集群运维人员希望默认禁止使用 ` namespaces ` 和 ` namespaceSelector ` ,而
755
+ 仅仅允许在特定名字空间中这样做,他们可以将 ` CrossNamespaceAffinity ` 作为一个
756
+ 被约束的资源。方法是为 ` kube-apiserver ` 设置标志
757
+ ` --admission-control-config-file ` ,使之指向如下的配置文件:
758
+
759
+ ``` yaml
760
+ apiVersion : apiserver.config.k8s.io/v1
761
+ kind : AdmissionConfiguration
762
+ plugins :
763
+ - name : " ResourceQuota"
764
+ configuration :
765
+ apiVersion : apiserver.config.k8s.io/v1
766
+ kind : ResourceQuotaConfiguration
767
+ limitedResources :
768
+ - resource : pods
769
+ matchScopes :
770
+ - scopeName : CrossNamespaceAffinity
771
+ ` ` `
772
+
773
+ <!--
774
+ With the above configuration, pods can use ` namespaces` and `namespaceSelector` in pod affinity only
775
+ if the namespace where they are created have a resource quota object with
776
+ ` CrossNamespaceAffinity` scope and a hard limit greater than or equal to the number of pods using those fields.
777
+ -->
778
+ 基于上面的配置,只有名字空间中包含作用域为 `CrossNamespaceAffinity` 且
779
+ 硬性约束大于或等于使用 `namespaces` 和 `namespaceSelector` 字段的 Pods
780
+ 个数时,才可以在该名字空间中继续创建在其 Pod 亲和性规则中设置 `namespaces`
781
+ 或 `namespaceSelector` 的新 Pod。
782
+
783
+ <!--
784
+ This feature is alpha and disabled by default. You can enable it by setting the
785
+ [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
786
+ ` PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler.
787
+ -->
788
+ 此功能特性处于 Alpha 阶段,默认被禁用。你可以通过为 kube-apiserver 和
789
+ kube-scheduler 设置
790
+ [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
791
+ ` PodAffinityNamespaceSelector` 来启用此特性。
792
+
793
+ <!--
794
+ # # Requests compared to Limits {#requests-vs-limits}
688
795
689
796
When allocating compute resources, each container may specify a request and a limit value for either CPU or memory.
690
797
The quota can be configured to quota either value.
691
798
-->
692
- ## 请求与限制 {#requests-vs-limits}
799
+ # # 请求与限制的比较 {#requests-vs-limits}
693
800
694
801
分配计算资源时,每个容器可以为 CPU 或内存指定请求和约束。
695
802
配额可以针对二者之一进行设置。
@@ -917,22 +1024,42 @@ plugins:
917
1024
` ` `
918
1025
919
1026
<!--
920
- Now, "cluster-services" pods will be allowed in only those namespaces where a quota object with a matching ` scopeSelector` is present.
921
-
922
- For example :
1027
+ Then, create a resource quota object in the ` kube-system` namespace:
923
1028
-->
924
- 现在,仅当命名空间中存在匹配的 `scopeSelector` 的配额对象时,才允许使用 "cluster-services" Pod。
1029
+ 现在在 `kube-system` 名字空间中创建一个资源配额对象:
925
1030
926
- 示例:
1031
+ {{< codenew file="policy/priority-class-resourcequota.yaml" >}}
927
1032
928
- ` ` ` yaml
929
- scopeSelector:
930
- matchExpressions:
931
- - scopeName: PriorityClass
932
- operator: In
933
- values: [" cluster-services"]
1033
+ ` ` ` shell
1034
+ kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system
1035
+ ` ` `
1036
+
1037
+ ```
1038
+ resourcequota/pods- cluster-services created
934
1039
```
935
1040
1041
+ <!--
1042
+ In this case, a pod creation will be allowed if:
1043
+
1044
+ 1. the Pod's `priorityClassName` is not specified.
1045
+ 1. the Pod's `priorityClassName` is specified to a value other than `cluster-services`.
1046
+ 1. the Pod's `priorityClassName` is set to `cluster-services`, it is to be created
1047
+ in the `kube-system` namespace, and it has passed the resource quota check.
1048
+ -->
1049
+ 在这里,当以下条件满足时可以创建 Pod:
1050
+
1051
+ 1. Pod 未设置 `priorityClassName`
1052
+ 1. Pod 的 `priorityClassName` 设置值不是 `cluster-services`
1053
+ 1. Pod 的 `priorityClassName` 设置值为 `cluster-services`,它将被创建于
1054
+ `kube-system` 名字空间中,并且它已经通过了资源配额检查。
1055
+
1056
+ <!--
1057
+ A Pod creation request is rejected if its `priorityClassName` is set to `cluster-services`
1058
+ and it is to be created in a namespace other than `kube-system`.
1059
+ -->
1060
+ 如果 Pod 的 `priorityClassName` 设置为 `cluster-services`,但要被创建到
1061
+ `kube-system` 之外的别的名字空间,则 Pod 创建请求也被拒绝。
1062
+
936
1063
## {{% heading "whatsnext" %}}
937
1064
938
1065
<!--
0 commit comments