whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'main' into kubeconfig

Browse Source
This commit is contained in:
Michael
2022-07-17 19:38:19 +08:00
parent 0fbcd47759 36d2e110a4
commit 747a4026a6
20 changed files with 2042 additions and 250 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh-cn/docs/concepts/architecture/nodes.md
+2 -3
View File
@@ -1170,14 +1170,13 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
<!--
* Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node.
* Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
* Read the [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node)
section of the architecture design document.
* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
-->
* 进一步了解节点[组件](/zh-cn/docs/concepts/overview/components/#node-components)。
* 阅读 [Node 的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。
* 阅读架构设计文档中有关
[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
[Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node)
的章节。
* 了解[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。
content/zh-cn/docs/concepts/cluster-administration/networking.md
+2 -2
View File
@@ -474,7 +474,7 @@ Weave Net 可以作为 [CNI 插件](https://www.weave.works/docs/net/latest/cni-
<!--
The early design of the networking model and its rationale, and some future
plans are described in more detail in the
[networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
[networking design document](https://git.k8s.io/design-proposals-archive/network/networking.md).
-->
网络模型的早期设计、运行原理以及未来的一些计划，
都在[联网设计文档](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)里有更详细的描述。
都在[联网设计文档](https://git.k8s.io/design-proposals-archive/network/networking.md)里有更详细的描述。
content/zh-cn/docs/concepts/overview/working-with-objects/names.md
+4 -4
View File
@@ -13,9 +13,9 @@ Every Kubernetes object also has a [_UID_](#uids) that is unique across your who
For example, you can only have one Pod named `myapp-1234` within the same [namespace](/docs/concepts/overview/working-with-objects/namespaces/), but you can have one Pod and one Deployment that are each named `myapp-1234`.
-->
集群中的每一个对象都有一个[_名称_](#names)来标识在同类资源中的唯一性。
集群中的每一个对象都有一个[**名称**](#names)来标识在同类资源中的唯一性。
每个 Kubernetes 对象也有一个 [_UID_](#uids) 来标识在整个集群中的唯一性。
每个 Kubernetes 对象也有一个 [**UID**](#uids) 来标识在整个集群中的唯一性。
比如，在同一个[名字空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/)
中有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。
@@ -171,9 +171,9 @@ UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。
<!--
* Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes.
* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document.
* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) design document.
-->
* 进一步了解 Kubernetes [标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)
* 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)的设计文档
* 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md)的设计文档
content/zh-cn/docs/concepts/policy/limit-range.md
+14 -13
View File
@@ -28,7 +28,7 @@ A _LimitRange_ provides constraints that can:
- Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime.
-->
一个 _LimitRange（限制范围）_ 对象提供的限制能够做到：
一个 **LimitRange（限制范围）** 对象提供的限制能够做到：
- 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
- 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
@@ -40,13 +40,14 @@ A _LimitRange_ provides constraints that can:
LimitRange support has been enabled by default since Kubernetes 1.10.
LimitRange support is enabled by default for many Kubernetes distributions.
A LimitRange is enforced in a particular namespace when there is a
LimitRange object in that namespace.
-->
## 启用 LimitRange
对 LimitRange 的支持自 Kubernetes 1.10 版本默认启用。
LimitRange 支持在很多 Kubernetes 发行版本中也是默认启用的。
当某命名空间中有一个 LimitRange 对象时，将在该命名空间中实施 LimitRange 限制。
<!--
The name of a LimitRange object must be a valid
@@ -58,7 +59,7 @@ LimitRange 的名称必须是合法的
<!--
### Overview of Limit Range
- The administrator creates one `LimitRange` in one namespace.
- The administrator creates one LimitRange in one namespace.
- Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace.
- The `LimitRanger` admission controller enforces defaults and limits for all Pods and Containers that do not set compute resource requirements and tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any LimitRange present in the namespace.
- If creating or updating a resource (Pod, Container, PersistentVolumeClaim) that violates a LimitRange constraint, the request to the API server will fail with an HTTP status code `403 FORBIDDEN` and a message explaining the constraint that have been violated.
@@ -106,21 +107,21 @@ Neither contention nor changes to a LimitRange will affect already created resou
## {{% heading "whatsnext" %}}
<!--
See [LimitRanger design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) for more information.
-->
参阅 [LimitRanger 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)获取更多信息。
参阅 [LimitRanger 设计文档](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)获取更多信息。
<!--
For examples on using limits, see:
- See [how to configure minimum and maximum CPU constraints per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/).
- See [how to configure minimum and maximum Memory constraints per namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
- See [how to configure default CPU Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
- See [how to configure default Memory Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
- Check [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
- See a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
- [how to configure minimum and maximum CPU constraints per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/).
- [how to configure minimum and maximum Memory constraints per namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
- [how to configure default CPU Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
- [how to configure default Memory Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
- [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
- a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).
-->
关于使用限值的例子，可参看
关于使用限值的例子，可参阅：
- [如何配置每个命名空间最小和最大的 CPU 约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。
- [如何配置每个命名空间最小和最大的内存约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
content/zh-cn/docs/concepts/policy/resource-quotas.md
+36 -39
View File
@@ -52,14 +52,15 @@ Resource quotas work like this:
the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements.
See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem.
-->
- 不同的团队可以在不同的命名空间下工作。这可以通过 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 强制执行。
- 不同的团队可以在不同的命名空间下工作。这可以通过
[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 强制执行。
- 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
- 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会
跟踪集群的资源使用情况，以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
- 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况，
以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
- 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN），
并在消息中给出有可能违反的约束。
- 如果命名空间下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为
这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。
- 如果命名空间下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，
则用户必须为这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。
提示: 可使用 `LimitRanger` 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。
若想避免这类问题，请参考
@@ -161,7 +162,7 @@ The following resource types are supported:
### Resource Quota For Extended Resources
In addition to the resources mentioned above, in release 1.10, quota support for
[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added.
[extended resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources) is added.
-->
### 扩展资源的资源配额
@@ -316,12 +317,9 @@ Job 而导致集群拒绝服务。
<!--
It is possible to do generic object count quota on a limited set of resources.
In addition, it is possible to further constrain quota for particular resources by their type.
The following types are supported:
-->
对有限的一组资源上实施一般性的对象数量配额也是可能的。
此外，还可以进一步按资源的类型设置其配额。
支持以下类型：
@@ -466,10 +464,10 @@ one value. For example:
```
<!--
If the `operator` is `Exists` or `DoesNotExist`, the `values field must *NOT* be
If the `operator` is `Exists` or `DoesNotExist`, the `values` field must *NOT* be
specified.
-->
如果 `operator` 为 `Exists` 或 `DoesNotExist`，则*不*可以设置 `values` 字段。
如果 `operator` 为 `Exists` 或 `DoesNotExist`，则**不**可以设置 `values` 字段。
<!--
### Resource Quota Per PriorityClass
@@ -495,8 +493,8 @@ A quota is matched and consumed only if `scopeSelector` in the quota spec select
When quota is scoped for priority class using `scopeSelector` field, quota object
is restricted to track only following resources:
-->
如果配额对象通过 `scopeSelector` 字段设置其作用域为优先级类，则配额对象只能
跟踪以下资源：
如果配额对象通过 `scopeSelector` 字段设置其作用域为优先级类，
则配额对象只能跟踪以下资源：
* `pods`
* `cpu`
@@ -713,27 +711,27 @@ Operators can use `CrossNamespacePodAffinity` quota scope to limit which namespa
have pods with affinity terms that cross namespaces. Specifically, it controls which pods are allowed
to set `namespaces` or `namespaceSelector` fields in pod affinity terms.
-->
集群运维人员可以使用 `CrossNamespacePodAffinity` 配额作用域来
限制哪个名字空间中可以存在包含跨名字空间亲和性规则的 Pod。
更为具体一点，此作用域用来配置哪些 Pod 可以在其 Pod 亲和性规则
中设置 `namespaces` 或 `namespaceSelector` 字段。
集群运维人员可以使用 `CrossNamespacePodAffinity`
配额作用域来限制哪个名字空间中可以存在包含跨名字空间亲和性规则的 Pod。
更为具体一点，此作用域用来配置哪些 Pod 可以在其 Pod 亲和性规则中设置
`namespaces` 或 `namespaceSelector` 字段。
<!--
Preventing users from using cross-namespace affinity terms might be desired since a pod
with anti-affinity constraints can block pods from all other namespaces
from getting scheduled in a failure domain.
-->
禁止用户使用跨名字空间的亲和性规则可能是一种被需要的能力，因为带有
反亲和性约束的 Pod 可能会阻止所有其他名字空间的 Pod 被调度到某失效域中。
禁止用户使用跨名字空间的亲和性规则可能是一种被需要的能力，
因为带有反亲和性约束的 Pod 可能会阻止所有其他名字空间的 Pod 被调度到某失效域中。
<!--
Using this scope operators can prevent certain namespaces (`foo-ns` in the example below)
from having pods that use cross-namespace pod affinity by creating a resource quota object in
that namespace with `CrossNamespaceAffinity` scope and hard limit of 0:
-->
使用此作用域操作符可以避免某些名字空间（例如下面例子中的 `foo-ns`）运行
特别的 Pod，这类 Pod 使用跨名字空间的 Pod 亲和性约束，在该名字空间中创建
了作用域为 `CrossNamespaceAffinity` 的、硬性约束为 0 的资源配额对象。
使用此作用域操作符可以避免某些名字空间（例如下面例子中的 `foo-ns`）运行特别的 Pod，
这类 Pod 使用跨名字空间的 Pod 亲和性约束，在该名字空间中创建了作用域为
`CrossNamespaceAffinity` 的、硬性约束为 0 的资源配额对象。
```yaml
apiVersion: v1
@@ -752,12 +750,12 @@ spec:
<!--
If operators want to disallow using `namespaces` and `namespaceSelector` by default, and
only allow it for specific namespaces, they could configure `CrossNamespaceAffinity`
as a limited resource by setting the kube-apiserver flag -admission-control-config-file
as a limited resource by setting the kube-apiserver flag --admission-control-config-file
to the path of the following configuration file:
-->
如果集群运维人员希望默认禁止使用 `namespaces` 和 `namespaceSelector`，而
仅仅允许在特定名字空间中这样做，他们可以将 `CrossNamespaceAffinity` 作为一个
被约束的资源。方法是为 `kube-apiserver` 设置标志
如果集群运维人员希望默认禁止使用 `namespaces` 和 `namespaceSelector`，
而仅仅允许在特定名字空间中这样做，他们可以将 `CrossNamespaceAffinity`
作为一个被约束的资源。方法是为 `kube-apiserver` 设置标志
`--admission-control-config-file`，使之指向如下的配置文件：
```yaml
@@ -779,8 +777,8 @@ With the above configuration, pods can use `namespaces` and `namespaceSelector`
if the namespace where they are created have a resource quota object with
`CrossNamespaceAffinity` scope and a hard limit greater than or equal to the number of pods using those fields.
-->
基于上面的配置，只有名字空间中包含作用域为 `CrossNamespaceAffinity` 且
硬性约束大于或等于使用 `namespaces` 和 `namespaceSelector` 字段的 Pods
基于上面的配置，只有名字空间中包含作用域为 `CrossNamespaceAffinity`
且硬性约束大于或等于使用 `namespaces` 和 `namespaceSelector` 字段的 Pod
个数时，才可以在该名字空间中继续创建在其 Pod 亲和性规则中设置 `namespaces`
或 `namespaceSelector` 的新 Pod。
@@ -987,18 +985,18 @@ should be allowed in a namespace, if and only if, a matching quota object exists
（例如 "cluster-services"）的 Pod。
<!--
With this mechanism, operators will be able to restrict usage of certain high
With this mechanism, operators are able to restrict usage of certain high
priority classes to a limited number of namespaces and not every namespace
will be able to consume these priority classes by default.
-->
通过这种机制，操作人员能够将限制某些高优先级类仅出现在有限数量的命名空间中，
通过这种机制，操作人员能够限制某些高优先级类仅出现在有限数量的命名空间中，
而并非每个命名空间默认情况下都能够使用这些优先级类。
<!--
To enforce this, kube-apiserver flag `-admission-control-config-file` should be
To enforce this, `kube-apiserver` flag `--admission-control-config-file` should be
used to pass path to the following configuration file:
-->
要实现此目的，应设置 kube-apiserver 的标志 `--admission-control-config-file`
要实现此目的，应设置 `kube-apiserver` 的标志 `--admission-control-config-file`
指向如下配置文件：
```yaml
@@ -1057,14 +1055,13 @@ and it is to be created in a namespace other than `kube-system`.
## {{% heading "whatsnext" %}}
<!--
- See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
- See [ResourceQuota design doc](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md) for more information.
- See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
- Read [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md).
- Read [Quota support for priority class design doc](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md).
- See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
-->
- 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)
- 查看[如何使用资源配额的详细示例](/zh-cn/docs/tasks/administer-cluster/quota-api-object/)。
- 阅读[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。
了解更多信息。
- 参阅 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
- 参阅[资源配额设计文档](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md)。
- 参阅[如何使用资源配额的详细示例](/zh-cn/docs/tasks/administer-cluster/quota-api-object/)。
- 参阅[优先级类配额支持的设计文档](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md)了解更多信息。
- 参阅 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)。
content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md
+41 -20
View File
@@ -18,13 +18,13 @@ weight: 20
<!--
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it can only run on particular set of
{{< glossary_tooltip text="Node(s)" term_id="node" >}}.
There are several ways to do this, and the recommended approaches all use
{{< glossary_tooltip text="node(s)" term_id="node" >}}.
There are several ways to do this and the recommended approaches all use
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
(e.g. spread your pods across nodes so as not place the pod on a node with insufficient free resources, etc.)
(for example, spreading your Pods across nodes so as not place Pods on a node with insufficient free resources).
However, there are some circumstances where you may want to control which node
the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it, or to co-locate pods from two different
the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it, or to co-locate Pods from two different
services that communicate a lot into the same availability zone.
-->
你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}}
@@ -172,6 +172,19 @@ define. Some of the benefits of affinity and anti-affinity include:
* 你可以使用节点上（或其他拓扑域中）运行的其他 Pod 的标签来实施调度约束，
而不是只能使用节点本身的标签。这个能力让你能够定义规则允许哪些 Pod 可以被放置在一起。
<!--
The affinity feature consists of two types of affinity:
* *Node affinity* functions like the `nodeSelector` field but is more expressive and
allows you to specify soft rules.
* *Inter-pod affinity/anti-affinity* allows you to constrain Pods against labels
on other Pods.
-->
亲和性功能由两种类型的亲和性组成：
* **节点亲和性**功能类似于 `nodeSelector` 字段，但它的表达能力更强，并且允许你指定软规则。
* Pod 间亲和性/反亲和性允许你根据其他 Pod 的标签来约束 Pod。
<!--
### Node affinity
@@ -222,15 +235,16 @@ For example, consider the following Pod spec:
<!--
In this example, the following rules apply:
* The node *must* have a label with the key `kubernetes.io/os` and
the value `linux`.
* The node *must* have a label with the key `topology.kubernetes.io/zone` and
the value of that label *must* be either `antarctica-east1` or `antarctica-west1`.
* The node *preferably* has a label with the key `another-node-label-key` and
the value `another-node-label-value`.
-->
在这一示例中，所应用的规则如下：
* 节点必须包含键名为 `kubernetes.io/os` 的标签，并且其取值为 `linux`。
* 节点 **最好** 具有键名为 `another-node-label-key` 且取值为
* 节点**必须**包含一个键名为 `topology.kubernetes.io/zone` 的标签，
并且该标签的取值**必须**为 `antarctica-east1` 或 `antarctica-west1`。
* 节点**最好**具有一个键名为 `another-node-label-key` 且取值为
`another-node-label-value` 的标签。
<!--
@@ -269,7 +283,7 @@ satisfied.
<!--
If you specify multiple `matchExpressions` associated with a single `nodeSelectorTerms`,
then the Pod can be scheduled onto a node only if all the `matchExpressions` are
satisfied.
satisfied.
-->
如果你指定了多个与同一 `nodeSelectorTerms` 关联的 `matchExpressions`，
则只有当所有 `matchExpressions` 都满足时 Pod 才可以被调度到节点上。
@@ -341,8 +355,8 @@ must have existing nodes with the `kubernetes.io/os=linux` label.
<!--
When configuring multiple [scheduling profiles](/docs/reference/scheduling/config/#multiple-profiles), you can associate
a profile with a Node affinity, which is useful if a profile only applies to a specific set of nodes.
To do so, add an `addedAffinity` to the `args` field of the [`NodeAffinity` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
a profile with a node affinity, which is useful if a profile only applies to a specific set of nodes.
To do so, add an `addedAffinity` to the `args` field of the [`NodeAffinity` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
in the [scheduler configuration](/docs/reference/scheduling/config/). For example:
-->
在配置多个[调度方案](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)时，
@@ -410,7 +424,7 @@ Inter-pod affinity and anti-affinity allow you to constrain which nodes your
Pods can be scheduled on based on the labels of **Pods** already running on that
node, instead of the node labels.
-->
### pod 间亲和性与反亲和性 {#inter-pod-affinity-and-anti-affinity}
### Pod 间亲和性与反亲和性 {#inter-pod-affinity-and-anti-affinity}
Pod 间亲和性与反亲和性使你可以基于已经在节点上运行的 **Pod** 的标签来约束
Pod 可以调度到的节点，而不是基于节点上的标签。
@@ -552,9 +566,9 @@ same zone currently running Pods with the `Security=S2` Pod label.
<!--
To get yourself more familiar with the examples of Pod affinity and anti-affinity,
refer to the [design proposal](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md).
refer to the [design proposal](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
-->
查阅[设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md)
查阅[设计文档](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)
以进一步熟悉 Pod 亲和性与反亲和性的示例。
<!--
@@ -571,8 +585,7 @@ exceptions for performance and security reasons:
有一些限制：
<!--
* For Pod affinity and anti-affinity, an empty `topologyKey` field is not allowed in both
`requiredDuringSchedulingIgnoredDuringExecution`
* For Pod affinity and anti-affinity, an empty `topologyKey` field is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
and `preferredDuringSchedulingIgnoredDuringExecution`.
* For `requiredDuringSchedulingIgnoredDuringExecution` Pod anti-affinity rules,
the admission controller `LimitPodHardAntiAffinityTopology` limits
@@ -634,6 +647,14 @@ Pod 间亲和性与反亲和性在与更高级别的集合（例如 ReplicaSet
Deployment 等）一起使用时，它们可能更加有用。
这些规则使得你可以配置一组工作负载，使其位于相同定义拓扑（例如，节点）中。
<!--
Take, for example, a three-node cluster running a web application with an
in-memory cache like redis. You could use inter-pod affinity and anti-affinity
to co-locate the web servers with the cache as much as possible.
-->
以一个三节点的集群为例，该集群运行一个带有 Redis 这种内存缓存的 Web 应用程序。
你可以使用节点间的亲和性和反亲和性来尽可能地将 Web 服务器与缓存并置。
<!--
In the following example Deployment for the redis cache, the replicas get the label `app=store`. The
`podAntiAffinity` rule tells the scheduler to avoid placing multiple replicas
@@ -803,16 +824,16 @@ The above Pod will only run on the node `kube-01`.
<!--
* Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .
* Read the design docs for [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
* Read the design docs for [node affinity](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
* Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level
resource allocation decisions.
* Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/).
* Learn how to use [affinity and anti-affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/).
-->
* 进一步阅读[污点与容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)文档。
* 阅读[节点亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
和[Pod 间亲和性与反亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
* 阅读[节点亲和性](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
和[Pod 间亲和性与反亲和性](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)
的设计文档。
* 了解[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。
* 了解如何使用 [nodeSelector](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/)。
content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md
+29 -18
View File
@@ -129,7 +129,7 @@ memory is reclaimable under pressure.
`memory.available` 的值来自 cgroupfs，而不是像 `free -m` 这样的工具。
这很重要，因为 `free -m` 在容器中不起作用，如果用户使用
[节点可分配资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
这一功能特性，资源不足的判定是基于 CGroup 层次结构中的用户 Pod 所处的局部及 CGroup 根节点作出的。
这一功能特性，资源不足的判定是基于 cgroup 层次结构中的用户 Pod 所处的局部及 cgroup 根节点作出的。
这个[脚本](/zh-cn/examples/admin/resource/memory-available.sh)
重现了 kubelet 为计算 `memory.available` 而执行的相同步骤。
kubelet 在其计算中排除了 inactive_file（即非活动 LRU 列表上基于文件来虚拟的内存的字节数），
@@ -154,15 +154,26 @@ kubelet 支持以下文件系统分区：
kubelet 会自动发现这些文件系统并忽略其他文件系统。kubelet 不支持其他配置。
{{<note>}}
<!--
Some kubelet garbage collection features are deprecated in favor of eviction.
For a list of the deprecated features, see [kubelet garbage collection deprecation](/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation).
<!--
Some kubelet garbage collection features are deprecated in favor of eviction:
| Existing Flag | New Flag | Rationale |
| ------------- | -------- | --------- |
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
| `--maximum-dead-containers` | - | deprecated once old logs are stored outside of container's context |
| `--maximum-dead-containers-per-container` | - | deprecated once old logs are stored outside of container's context |
| `--minimum-container-ttl-duration` | - | deprecated once old logs are stored outside of container's context |
-->
一些 kubelet 垃圾收集功能已被弃用，以支持驱逐。
有关已弃用功能的列表，请参阅
[kubelet 垃圾收集弃用](/zh-cn/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation)。
{{</note>}}
一些 kubelet 垃圾收集功能已被弃用，以鼓励使用驱逐机制。
| 现有标志 | 新的标志 | 原因 |
| ------------- | -------- | --------- |
| `--image-gc-high-threshold` | `--eviction-hard` 或 `--eviction-soft` | 现有的驱逐信号可以触发镜像垃圾收集 |
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 驱逐回收具有相同的行为 |
| `--maximum-dead-containers` | - | 一旦旧的日志存储在容器的上下文之外就会被弃用 |
| `--maximum-dead-containers-per-container` | - | 一旦旧的日志存储在容器的上下文之外就会被弃用 |
| `--minimum-container-ttl-duration` | - | 一旦旧的日志存储在容器的上下文之外就会被弃用 |
<!--
### Eviction thresholds
@@ -247,7 +258,7 @@ You can use the following flags to configure soft eviction thresholds:
如果驱逐条件持续时长超过指定的宽限期，可以触发 Pod 驱逐。
* `eviction-soft-grace-period`：一组驱逐宽限期，
如 `memory.available=1m30s`，定义软驱逐条件在触发 Pod 驱逐之前必须保持多长时间。
* `eviction-max-pod-grace-period`：在满足软驱逐条件而终止 Pod 时使用的最大允许宽限期（以秒为单位）。
* `eviction-max-pod-grace-period`：在满足软驱逐条件而终止 Pod 时使用的最大允许宽限期（以秒为单位）。
<!--
#### Hard eviction thresholds {#hard-eviction-thresholds}
@@ -320,7 +331,7 @@ kubelet 根据下表将驱逐信号映射为节点状况：
| 节点条件 | 驱逐信号 | 描述 |
|---------|--------|------|
| `MemoryPressure` | `memory.available` | 节点上的可用内存已满足驱逐条件 |
| `DiskPressure` | `nodefs.available`、`nodefs.inodesFree`、`imagefs.available` 或 `imagefs.inodesFree` | 节点的根文件系统或映像文件系统上的可用磁盘空间和 inode 已满足驱逐条件 |
| `DiskPressure` | `nodefs.available`、`nodefs.inodesFree`、`imagefs.available` 或 `imagefs.inodesFree` | 节点的根文件系统或镜像文件系统上的可用磁盘空间和 inode 已满足驱逐条件 |
| `PIDPressure` | `pid.available` | (Linux) 节点上的可用进程标识符已低于驱逐条件 |
kubelet 根据配置的 `--node-status-update-frequency` 更新节点条件，默认为 `10s`。
@@ -472,7 +483,7 @@ requests.
The kubelet sorts pods differently based on whether the node has a dedicated
`imagefs` filesystem:
-->
当 kubelet 因 inode 或 PID 不足而驱逐 pod 时，
当 kubelet 因 inode 或 PID 不足而驱逐 Pod 时，
它使用优先级来确定驱逐顺序，因为 inode 和 PID 没有请求。
kubelet 根据节点是否具有专用的 `imagefs` 文件系统对 Pod 进行不同的排序：
@@ -648,7 +659,7 @@ Consider the following scenario:
* 节点内存容量：`10Gi`
* 操作员希望为系统守护进程（内核、`kubelet` 等）保留 10% 的内存容量
* 操作员希望驱逐内存利用率为 95% 的Pod，以减少系统 OOM 的概率。
* 操作员希望驱逐内存利用率为 95% 的 Pod，以减少系统 OOM 的概率。
<!--
For this to work, the kubelet is launched as follows:
@@ -757,7 +768,7 @@ You can work around that behavior by setting the memory limit and memory request
the same for containers likely to perform intensive I/O activity. You will need
to estimate or measure an optimal memory limit value for that container.
-->
更多细节请参见 [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)
更多细节请参见 [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)。
你可以通过为可能执行 I/O 密集型活动的容器设置相同的内存限制和内存请求来应对该行为。
你将需要估计或测量该容器的最佳内存限制值。
@@ -765,14 +776,14 @@ to estimate or measure an optimal memory limit value for that container.
## {{% heading "whatsnext" %}}
<!--
* Learn about [API-initiated Eviction](/docs/reference/generated/kubernetes-api/v1.23/)
* Learn about [API-initiated Eviction](/docs/concepts/scheduling-eviction/api-eviction/)
* Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* Learn about [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/)
* Learn about [Quality of Service](/docs/tasks/configure-pod-container/quality-service-pod/) (QoS)
* Check out the [Eviction API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)
-->
* 了解 [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/)
* 了解 [Pod 优先级和驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* 了解 [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/)
* 了解 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)
* 了解 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* 了解 [PodDisruptionBudgets](/zh-cn/docs/tasks/run-application/configure-pdb/)
* 了解[服务质量](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/)（QoS）
* 查看[驱逐 API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)
content/zh-cn/docs/concepts/storage/volumes.md
+3 -3
View File
@@ -540,11 +540,11 @@ It mounts a directory and writes the requested data in plain text files.
这种卷类型挂载一个目录并在纯文本文件中写入所请求的数据。
<!--
A Container using Downward API as a [subPath](#using-subpath) volume mount will not
receive Downward API updates.
A container using the downward API as a [`subPath`](#using-subpath) volume mount does not
receive updates when field values change.
-->
{{< note >}}
容器以 [subPath](#using-subpath) 卷挂载方式使用 downwardAPI 时，将不能接收到它的更新。
容器以 [subPath](#using-subpath) 卷挂载方式使用 downward API 时，在字段值更改时将不能接收到它的更新。
{{< /note >}}
<!--
content/zh-cn/docs/reference/access-authn-authz/authorization.md
+8
View File
@@ -158,6 +158,14 @@ PUT | update
PATCH | patch
DELETE | delete（针对单个资源）、deletecollection（针对集合）
{{< caution >}}
<!--
The `get`, `list` and `watch` verbs can all return the full details of a resource. In terms of the returned data they are equivalent. For example, `list` on `secrets` will still reveal the `data` attributes of any returned resources.
-->
`get`、`list` 和 `watch` 动作都可以返回一个资源的完整详细信息。就返回的数据而言，它们是等价的。
例如，对 `secrets` 使用 `list` 仍然会显示所有已返回资源的 `data` 属性。
{{< /caution >}}
<!--
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
content/zh-cn/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1.md
+1736
View File
File diff suppressed because it is too large Load Diff
content/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-class-v1.md
+14 -12
View File
@@ -4,13 +4,12 @@ api_metadata:
import: "k8s.io/api/networking/v1"
kind: "IngressClass"
content_type: "api_reference"
description: "IngressClass 代表 Ingress 的类, 被 Ingress 的规约引用。"
description: "IngressClass 代表 Ingress 的类，被 Ingress 的规约引用。"
title: "IngressClass"
weight: 5
---
<!--
---
api_metadata:
apiVersion: "networking.k8s.io/v1"
import: "k8s.io/api/networking/v1"
@@ -20,7 +19,6 @@ description: "IngressClass represents the class of the Ingress, referenced by th
title: "IngressClass"
weight: 5
auto_generated: true
---
-->
`apiVersion: networking.k8s.io/v1`
@@ -34,8 +32,9 @@ IngressClass represents the class of the Ingress, referenced by the Ingress Spec
-->
## IngressClass {#IngressClass}
IngressClass 代表 Ingress 的类, 被 Ingress 的规约引用。
`ingressclass.kubernetes.io/is-default-class` 注解可以用来标明一个 IngressClass 应该被视为默认的 Ingress 类。
IngressClass 代表 Ingress 的类，被 Ingress 的规约引用。
`ingressclass.kubernetes.io/is-default-class`
注解可以用来标明一个 IngressClass 应该被视为默认的 Ingress 类。
当某个 IngressClass 资源将此注解设置为 true 时，
没有指定类的新 Ingress 资源将被分配到此默认类。
@@ -50,22 +49,23 @@ IngressClass 代表 Ingress 的类, 被 Ingress 的规约引用。
<!--
Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
-->
标准的列表元数据。
更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
标准的列表元数据。更多信息：
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
- **spec** (<a href="{{< ref "../service-resources/ingress-class-v1#IngressClassSpec" >}}">IngressClassSpec</a>)
<!--
Spec is the desired state of the IngressClass. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
-->
spec 是 IngressClass 的期望状态。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
spec 是 IngressClass 的期望状态。更多信息：
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
## IngressClassSpec {#IngressClassSpec}
<!--
IngressClassSpec provides information about the class of an Ingress.
-->
IngressClassSpec 提供有关 Ingress 类的信息。
IngressClassSpec 提供有关 Ingress 类的信息。
<hr>
@@ -120,14 +120,16 @@ IngressClassSpec 提供有关 Ingress 类的信息。
apiGroup 是被引用资源的组。
如果未指定 apiGroup，则被指定的 kind 必须在核心 API 组中。
对于任何其他第三方类型， APIGroup 是必需的。
对于任何其他第三方类型，apiGroup 是必需的。
- **parameters.namespace** (string)
<!--
Namespace is the namespace of the resource being referenced. This field is required when scope is set to "Namespace" and must be unset when scope is set to "Cluster".
-->
namespace 是被引用资源的命名空间。当范围被设置为 “namespace” 时，此字段是必需的，当范围被设置为 “Cluster”，此字段必须取消设置。
namespace 是被引用资源的命名空间。
当范围被设置为 “namespace” 时，此字段是必需的；
当范围被设置为 “Cluster” 时，此字段必须不设置。
- **parameters.scope** (string)
<!--
@@ -164,7 +166,7 @@ IngressClassList 是 IngressClasses 的集合。
-->
- **items** ([]<a href="{{< ref "../service-resources/ingress-class-v1#IngressClass" >}}">IngressClass</a>)，必需
items 是 IngressClasses 的列表
items 是 IngressClasses 的列表。
<!--
## Operations {#Operations}
content/zh-cn/docs/reference/kubernetes-api/workload-resources/controller-revision-v1.md
+17 -10
View File
@@ -7,7 +7,6 @@ content_type: "api_reference"
description: "ControllerRevision 实现了状态数据的不可变快照。"
title: "ControllerRevision"
weight: 7
auto_generated: false
---
<!--
@@ -22,7 +21,6 @@ weight: 7
auto_generated: true
-->
`apiVersion: apps/v1`
`import "k8s.io/api/apps/v1"`
@@ -71,8 +69,8 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。
-->
- **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta</a>)
标准的对象元数据。
更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
标准的对象元数据。更多信息：
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
<!--
- **revision** (int64), required
@@ -97,7 +95,7 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。
*RawExtension is used to hold extensions in external versions.
-->
<a name="RawExtension"></a>
*RawExtension 用于以外部版本来保存扩展数据。
**RawExtension 用于以外部版本来保存扩展数据。**
<!--
To use this, make a field which has RawExtension as its type in your external, versioned struct, and Object in your internal struct. You also need to register your various plugin types.
@@ -112,7 +110,9 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。
AOption string `json:"aOption"`
}
-->
// 内部包：
内部包：
```go
type MyAPIObject struct {
runtime.TypeMeta `json:",inline"`
MyPlugin runtime.Object `json:"myPlugin"`
@@ -120,6 +120,7 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。
type PluginA struct {
AOption string `json:"aOption"`
}
```
<!--
// External package: type MyAPIObject struct {
@@ -129,7 +130,9 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。
AOption string `json:"aOption"`
}
-->
// 外部包：
外部包：
```go
type MyAPIObject struct {
runtime.TypeMeta `json:",inline"`
MyPlugin runtime.RawExtension `json:"myPlugin"`
@@ -137,6 +140,7 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。
type PluginA struct {
AOption string `json:"aOption"`
}
```
<!--
// On the wire, the JSON will look something like this: {
@@ -148,7 +152,8 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。
},
}
-->
// 在网络上，JSON 看起来像这样：
在网络上，JSON 看起来像这样：
```json
{
"kind":"MyAPIObject",
"apiVersion":"v1",
@@ -157,6 +162,7 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。
"aOption":"foo",
},
}
```
<!--
So what happens? Decode first uses json or yaml to unmarshal the serialized data into your external MyAPIObject. That causes the raw JSON to be stored, but not unpacked. The next step is to copy (using pkg/conversion) into the internal struct. The runtime package's DefaultScheme has conversion functions installed which will unpack the JSON stored in RawExtension, turning it into the correct object type, and storing it in the Object. (TODO: In the case where the object is of an unknown type, a runtime.Unknown object will be created and stored.)*
@@ -167,7 +173,7 @@ API 服务器将无法成功验证所有尝试改变 data 字段的请求。
下一步是复制（使用 pkg/conversion）到内部结构中。
runtime 包的 DefaultScheme 安装了转换函数，它将解析存储在 RawExtension 中的 JSON，
将其转换为正确的对象类型，并将其存储在 Object 中。
（TODO：如果对象是未知类型，将创建并存储一个 `runtime.Unknown`对象。）*
（TODO：如果对象是未知类型，将创建并存储一个 `runtime.Unknown`对象。）
<!--
## ControllerRevisionList {#ControllerRevisionList}
@@ -199,7 +205,8 @@ ControllerRevisionList 是一个包含 ControllerRevision 对象列表的资源
-->
- **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta</a>)
更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
更多信息：
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
<!--
- **items** ([]<a href="{{< ref "../workload-resources/controller-revision-v1#ControllerRevision" >}}">ControllerRevision</a>), required
content/zh-cn/docs/reference/using-api/_index.md
+2 -2
View File
@@ -152,12 +152,12 @@ Here's a summary of each level:
## API 组
<!--
[API groups](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)
[API groups](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md)
make it easier to extend the Kubernetes API.
The API group is specified in a REST path and in the `apiVersion` field of a
serialized object.
-->
[API 组](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)
[API 组](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md)
能够简化对 Kubernetes API 的扩展。
API 组信息出现在REST 路径中，也出现在序列化对象的 `apiVersion` 字段中。
content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+2 -2
View File
@@ -462,10 +462,10 @@ PersistentVolume are not present on the Pod resource itself.
<!--
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
* Read the [Persistent Storage design document](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md).
-->
* 进一步了解 [PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/)
* 阅读[持久存储设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)
* 阅读[持久存储设计文档](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md)
<!--
### Reference
content/zh-cn/docs/tasks/configure-pod-container/security-context.md
+5 -5
View File
@@ -721,7 +721,7 @@ Pod 的安全上下文适用于 Pod 中的容器，也适用于 Pod 所挂载的
<!--
* `fsGroup`: Volumes that support ownership management are modified to be owned
and writable by the GID specified in `fsGroup`. See the
[Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
[Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)
for more details.
* `seLinuxOptions`: Volumes that support SELinux labeling are relabeled to be accessible
@@ -732,7 +732,7 @@ Pod 的安全上下文适用于 Pod 中的容器，也适用于 Pod 所挂载的
-->
* `fsGroup`：支持属主管理的卷会被修改，将其属主变更为 `fsGroup` 所指定的 GID，
并且对该 GID 可写。进一步的细节可参阅
[属主变更设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)。
[属主变更设计文档](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)。
* `seLinuxOptions`：支持 SELinux 标签的卷会被重新打标签，以便可被 `seLinuxOptions`
下所设置的标签访问。通常你只需要设置 `level` 部分。
@@ -771,11 +771,11 @@ kubectl delete pod security-context-demo-4
* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
* [Tuning Docker with the newest security enhancements](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
* [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
* [Security Contexts design document](https://git.k8s.io/design-proposals-archive/auth/security_context.md)
* [Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)
* [Pod Security Policies](/docs/concepts/security/pod-security-policy/)
* [AllowPrivilegeEscalation design
document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
document](https://git.k8s.io/design-proposals-archive/auth/no-new-privs.md)
* For more information about security mechanisms in Linux, see
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
-->