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

Merge pull request #34506 from howieyuen/concept-pages-3

Browse Source 
[zh]Update concepts pages(part-3) for links with '/zh/' prefix, using new prefix '/zh-cn/'
This commit is contained in:
Kubernetes Prow Robot
2022-06-23 18:21:19 -07:00
committed by GitHub
parent a1e3ba7fc2 5f0ec40aaa
commit eea83a544d
29 changed files with 260 additions and 260 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh-cn/docs/concepts/scheduling-eviction/_index.md
+10 -10
View File
@@ -35,18 +35,18 @@ of terminating one or more Pods on Nodes.
## 调度
* [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
* [将 Pods 指派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)
* [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
* [污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
* [调度框架](/zh/docs/concepts/scheduling-eviction/scheduling-framework)
* [调度器的性能调试](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* [扩展资源的资源装箱](/zh/docs/concepts/scheduling-eviction/resource-bin-packing/)
* [Kubernetes 调度器](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/)
* [将 Pods 指派到节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)
* [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/)
* [污点和容忍](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)
* [调度框架](/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework)
* [调度器的性能调试](/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* [扩展资源的资源装箱](/zh-cn/docs/concepts/scheduling-eviction/resource-bin-packing/)
<!-- ## Pod Disruption -->
## Pod 干扰
* [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* [API发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/)
* [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* [节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* [API发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)
content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md
+7 -7
View File
@@ -30,12 +30,12 @@ on the Pod.
此操作创建一个 `Eviction` 对象，该对象再驱动 API 服务器终止选定的 Pod。
API 发起的驱逐将遵从你的
[`PodDisruptionBudgets`](/zh/docs/tasks/run-application/configure-pdb/)
和 [`terminationGracePeriodSeconds`](/zh/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)
[`PodDisruptionBudgets`](/zh-cn/docs/tasks/run-application/configure-pdb/)
和 [`terminationGracePeriodSeconds`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)
配置。
使用 API 创建 Eviction 对象，就像对 Pod 执行策略控制的
[`DELETE` 操作](/zh/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod)
[`DELETE` 操作](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod)
<!--
## Calling the Eviction API
@@ -46,7 +46,7 @@ POST the attempted operation, similar to the following example:
-->
## 调用 Eviction API
你可以使用 [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)
你可以使用 [Kubernetes 语言客户端](/zh-cn/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)
来访问 Kubernetes API 并创建 `Eviction` 对象。
要执行此操作，你应该用 POST 发出要尝试的请求，类似于下面的示例：
@@ -201,6 +201,6 @@ If you notice stuck evictions, try one of the following solutions:
* Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
* Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/).
-->
* 了解如何使用 [Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/) 保护你的应用。
* 了解[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。
* 了解 [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)。
* 了解如何使用 [Pod 干扰预算](/zh-cn/docs/tasks/run-application/configure-pdb/) 保护你的应用。
* 了解[节点压力引发的驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。
* 了解 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)。
content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md
+21 -21
View File
@@ -30,7 +30,7 @@ services that communicate a lot into the same availability zone.
你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}}
只能在特定的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。
有几种方法可以实现这点，推荐的方法都是用
[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。
[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来进行选择。
通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上，
而不是将 Pod 放置在可用资源不足的节点上等等）。但在某些情况下，你可能需要进一步控制
Pod 被部署到的节点。例如，确保 Pod 最终落在连接了 SSD 的机器上，
@@ -62,10 +62,10 @@ for a list of common node labels.
-->
## 节点标签 {#built-in-node-labels}
与很多其他 Kubernetes 对象类似，节点也有[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。
你可以[手动地添加标签](/zh/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)。
与很多其他 Kubernetes 对象类似，节点也有[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。
你可以[手动地添加标签](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)。
Kubernetes 也会为集群中所有节点添加一些标准的标签。
参见[常用的标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)以了解常见的节点标签。
参见[常用的标签、注解和污点](/zh-cn/docs/reference/labels-annotations-taints/)以了解常见的节点标签。
{{< note >}}
<!--
@@ -108,7 +108,7 @@ prevents the kubelet from setting or modifying labels with a
To make use of that label prefix for node isolation:
-->
[`NodeRestriction` 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)防止
[`NodeRestriction` 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)防止
kubelet 使用 `node-restriction.kubernetes.io/` 前缀设置或修改标签。
要使用该标签前缀进行节点隔离：
@@ -118,8 +118,8 @@ kubelet 使用 `node-restriction.kubernetes.io/` 前缀设置或修改标签。
2. Add labels with the `node-restriction.kubernetes.io/` prefix to your nodes, and use those labels in your [node selectors](#nodeselector).
For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`.
-->
1. 确保你在使用[节点鉴权](/zh/docs/reference/access-authn-authz/node/)机制并且已经启用了
[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。
1. 确保你在使用[节点鉴权](/zh-cn/docs/reference/access-authn-authz/node/)机制并且已经启用了
[NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。
2. 将带有 `node-restriction.kubernetes.io/` 前缀的标签添加到 Node 对象，
然后在[节点选择器](#nodeSelector)中使用这些标签。
例如，`example.com.node-restriction.kubernetes.io/fips=true` 或
@@ -142,7 +142,7 @@ Kubernetes 只会将 Pod 调度到拥有你所指定的每个标签的节点上
See [Assign Pods to Nodes](/docs/tasks/configure-pod-container/assign-pods-nodes) for more
information.
-->
进一步的信息可参见[将 Pod 指派给节点](/zh/docs/tasks/configure-pod-container/assign-pods-nodes)。
进一步的信息可参见[将 Pod 指派给节点](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes)。
<!--
## Affinity and anti-affinity
@@ -247,7 +247,7 @@ Alternatively, you can use [node taints](/docs/concepts/scheduling-eviction/tain
to repel Pods from specific nodes.
-->
`NotIn` 和 `DoesNotExist` 可用来实现节点反亲和性行为。
你也可以使用[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
你也可以使用[节点污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)
将 Pod 从特定节点上驱逐。
{{< note >}}
@@ -279,7 +279,7 @@ satisfied.
See [Assign Pods to Nodes using Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)
for more information.
-->
参阅[使用节点亲和性来为 Pod 指派节点](/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)，
参阅[使用节点亲和性来为 Pod 指派节点](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)，
以了解进一步的信息。
<!--
@@ -345,11 +345,11 @@ a profile with a Node affinity, which is useful if a profile only applies to a s
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/docs/reference/scheduling/config/#multiple-profiles)时，
在配置多个[调度方案](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)时，
你可以将某个方案与节点亲和性关联起来，如果某个调度方案仅适用于某组特殊的节点时，
这样做是很有用的。
要实现这点，可以在[调度器配置](/zh/docs/reference/scheduling/config/)中为
[`NodeAffinity` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)的
要实现这点，可以在[调度器配置](/zh-cn/docs/reference/scheduling/config/)中为
[`NodeAffinity` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)的
`args` 字段添加 `addedAffinity`。例如：
```yaml
@@ -397,7 +397,7 @@ does not support scheduling profiles. When the DaemonSet controller creates
Pods, the default Kubernetes scheduler places those Pods and honors any
`nodeAffinity` rules in the DaemonSet controller.
-->
DaemonSet 控制器[为 DaemonSet 创建 Pods](/zh/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)，
DaemonSet 控制器[为 DaemonSet 创建 Pods](/zh-cn/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)，
但该控制器不理会调度方案。
DaemonSet 控制器创建 Pod 时，默认的 Kubernetes 调度器负责放置 Pod，
并遵从 DaemonSet 控制器中奢侈的 `nodeAffinity` 规则。
@@ -434,7 +434,7 @@ Kubernetes, so Pod labels also implicitly have namespaces. Any label selectors
for Pod labels should specify the namespaces in which Kubernetes should look for those
labels.
-->
你通过[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)
你通过[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)
的形式来表达规则（Y），并可根据需要指定选关联的名字空间列表。
Pod 在 Kubernetes 中是名字空间作用域的对象，因此 Pod 的标签也隐式地具有名字空间属性。
针对 Pod 标签的所有标签选择算符都要指定名字空间，Kubernetes
@@ -446,7 +446,7 @@ the node label that the system uses to denote the domain. For examples, see
[Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/).
-->
你会通过 `topologyKey` 来表达拓扑域（X）的概念，其取值是系统用来标示域的节点标签键。
相关示例可参见[常用标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)。
相关示例可参见[常用标签、注解和污点](/zh-cn/docs/reference/labels-annotations-taints/)。
{{< note >}}
<!--
@@ -740,7 +740,7 @@ See the [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tol
for an example of a StatefulSet configured with anti-affinity for high
availability, using the same technique as this example.
-->
参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
参阅 [ZooKeeper 教程](/zh-cn/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
了解一个 StatefulSet 的示例，该 StatefulSet 配置了反亲和性以实现高可用，
所使用的是与此例相同的技术。
@@ -810,11 +810,11 @@ The above Pod will only run on the node `kube-01`.
* 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/docs/concepts/scheduling-eviction/taint-and-toleration/)文档。
* 进一步阅读[污点与容忍度](/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)
的设计文档。
* 了解[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。
* 了解如何使用 [nodeSelector](/zh/docs/tasks/configure-pod-container/assign-pods-nodes/)。
* 了解如何使用[亲和性和反亲和性](/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)。
* 了解[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。
* 了解如何使用 [nodeSelector](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/)。
* 了解如何使用[亲和性和反亲和性](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)。
content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md
+10 -10
View File
@@ -57,7 +57,7 @@ is the default scheduler for Kubernetes and runs as part of the
kube-scheduler is designed so that, if you want and need to, you can
write your own scheduling component and use that instead.
-->
[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
[kube-scheduler](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/)
是 Kubernetes 集群的默认调度器，并且是集群
{{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。
如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许
@@ -162,9 +162,9 @@ of the scheduler:
`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
can also configure the kube-scheduler to run different profiles.
-->
1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _断言(Predicates)_
1. [调度策略](/zh-cn/docs/reference/scheduling/policies) 允许你配置过滤的 _断言(Predicates)_
和打分的 _优先级(Priorities)_ 。
2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件，
2. [调度配置](/zh-cn/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件，
包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。
你也可以配置 kube-scheduler 运行不同的配置文件。
@@ -178,10 +178,10 @@ of the scheduler:
* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
* Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
-->
* 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* 阅读关于 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
* 阅读 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)
* 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式
* 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
* 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
* 阅读关于 [调度器性能调优](/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* 阅读关于 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* 阅读关于 kube-scheduler 的 [参考文档](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/)
* 阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
* 了解关于 [配置多个调度器](/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式
* 了解关于 [拓扑结构管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)
* 了解关于 [Pod 额外开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/)
content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md
+7 -7
View File
@@ -128,9 +128,9 @@ memory is reclaimable under pressure.
-->
`memory.available` 的值来自 cgroupfs，而不是像 `free -m` 这样的工具。
这很重要，因为 `free -m` 在容器中不起作用，如果用户使用
[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
[节点可分配资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
这一功能特性，资源不足的判定是基于 CGroup 层次结构中的用户 Pod 所处的局部及 CGroup 根节点作出的。
这个[脚本](/zh/examples/admin/resource/memory-available.sh)
这个[脚本](/zh-cn/examples/admin/resource/memory-available.sh)
重现了 kubelet 为计算 `memory.available` 而执行的相同步骤。
kubelet 在其计算中排除了 inactive_file（即非活动 LRU 列表上基于文件来虚拟的内存的字节数），
因为它假定在压力下内存是可回收的。
@@ -161,7 +161,7 @@ For a list of the deprecated features, see [kubelet garbage collection deprecati
-->
一些 kubelet 垃圾收集功能已被弃用，以支持驱逐。
有关已弃用功能的列表，请参阅
[kubelet 垃圾收集弃用](/zh/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation)。
[kubelet 垃圾收集弃用](/zh-cn/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation)。
{{</note>}}
<!--
@@ -414,7 +414,7 @@ The kubelet uses the following parameters to determine pod eviction order:
kubelet 使用以下参数来确定 Pod 驱逐顺序：
1. Pod 的资源使用是否超过其请求
1. [Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
1. [Pod 优先级](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
1. Pod 相对于请求的资源使用情况
<!--
@@ -524,7 +524,7 @@ reclaims the quantity you specify.
For example, the following configuration sets minimum reclaim amounts:
-->
你可以使用 `--eviction-minimum-reclaim` 标志或
[kubelet 配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)
[kubelet 配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)
为每个资源配置最小回收量。
当 kubelet 注意到某个资源耗尽时，它会继续回收该资源，直到回收到你所指定的数量为止。
@@ -772,7 +772,7 @@ to estimate or measure an optimal memory limit value for that container.
* 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/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* 了解 [Pod 优先级和驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* 了解 [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/)
* 了解[服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)（QoS）
* 了解[服务质量](/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/scheduling-eviction/pod-overhead.md
+5 -5
View File
@@ -40,8 +40,8 @@ time according to the overhead associated with the Pod's
[RuntimeClass](/docs/concepts/containers/runtime-class/).
-->
在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)
相关联的开销在[准入](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)时设置的。
在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)
相关联的开销在[准入](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)时设置的。
<!--
When Pod Overhead is enabled, the overhead is considered in addition to the sum of container
@@ -129,7 +129,7 @@ updates the workload's PodSpec to include the `overhead` as described in the Run
the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod
to include an `overhead`.
-->
在准入阶段 RuntimeClass [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
在准入阶段 RuntimeClass [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)
更新工作负载的 PodSpec 以包含
RuntimeClass 中定义的 `overhead`。如果 PodSpec 中已定义该字段，该 Pod 将会被拒绝。
在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod，使之包含 `overhead`。
@@ -154,7 +154,7 @@ map[cpu:250m memory:120Mi]
If a [ResourceQuota](/docs/concepts/policy/resource-quotas/) is defined, the sum of container requests as well as the
`overhead` field are counted.
-->
如果定义了 [ResourceQuata](/zh/docs/concepts/policy/resource-quotas/),
如果定义了 [ResourceQuata](/zh-cn/docs/concepts/policy/resource-quotas/),
则容器请求的总量以及 `overhead` 字段都将计算在内。
<!--
@@ -332,5 +332,5 @@ running with a defined overhead.
* Read the [PodOverhead Design](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
enhancement proposal for extra context
-->
* 学习更多关于 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 的信息
* 学习更多关于 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/) 的信息
* 阅读 [PodOverhead 设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)增强建议以获取更多上下文
content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md
+11 -11
View File
@@ -23,7 +23,7 @@ importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
pending Pod possible.
-->
[Pod](/zh/docs/concepts/workloads/pods/) 可以有 _优先级_。
[Pod](/zh-cn/docs/concepts/workloads/pods/) 可以有 _优先级_。
优先级表示一个 Pod 相对于其他 Pod 的重要性。
如果一个 Pod 无法被调度，调度程序会尝试抢占（驱逐）较低优先级的 Pod，
以使悬决 Pod 可以被调度。
@@ -44,7 +44,7 @@ for details.
在一个并非所有用户都是可信的集群中，恶意用户可能以最高优先级创建 Pod，
导致其他 Pod 被驱逐或者无法被调度。
管理员可以使用 ResourceQuota 来阻止用户创建高优先级的 Pod。
参见[默认限制优先级消费](/zh/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)。
参见[默认限制优先级消费](/zh-cn/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)。
{{< /warning >}}
@@ -82,7 +82,7 @@ These are common classes and are used to [ensure that critical components are al
-->
Kubernetes 已经提供了 2 个 PriorityClass：
`system-cluster-critical` 和 `system-node-critical`。
这些是常见的类，用于[确保始终优先调度关键组件](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。
这些是常见的类，用于[确保始终优先调度关键组件](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。
{{< /note >}}
<!--
@@ -103,7 +103,7 @@ PriorityClass 是一个无名称空间对象，它定义了从优先级类名称
名称在 PriorityClass 对象元数据的 `name` 字段中指定。
值在必填的 `value` 字段中指定。值越大，优先级越高。
PriorityClass 对象的名称必须是有效的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)，
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)，
并且它不能以 `system-` 为前缀。
<!--
@@ -377,7 +377,7 @@ priority Pods to zero or a small number.
#### 被抢占牺牲者的体面终止
当 Pod 被抢占时，牺牲者会得到他们的
[体面终止期](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
[体面终止期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
它们可以在体面终止期内完成工作并退出。如果它们不这样做就会被杀死。
这个体面终止期在调度程序抢占 Pod 的时间点和待处理的 Pod (P)
可以在节点 (N) 上调度的时间点之间划分出了一个时间跨度。
@@ -399,7 +399,7 @@ despite their PDBs being violated.
-->
#### 支持 PodDisruptionBudget，但不保证
[PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)
[PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)
(PDB) 允许多副本应用程序的所有者限制因自愿性质的干扰而同时终止的 Pod 数量。
Kubernetes 在抢占 Pod 时支持 PDB，但对 PDB 的支持是基于尽力而为原则的。
调度器会尝试寻找不会因被抢占而违反 PDB 的牺牲者，但如果没有找到这样的牺牲者，
@@ -639,7 +639,7 @@ exceeding its requests, it won't be evicted. Another Pod with higher priority
that exceeds its requests may be evicted.
-->
kubelet 使用优先级来确定
[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) Pod 的顺序。
[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) Pod 的顺序。
你可以使用 QoS 类来估计 Pod 最有可能被驱逐的顺序。kubelet 根据以下因素对 Pod 进行驱逐排名：
1. 对紧俏资源的使用是否超过请求值
@@ -647,7 +647,7 @@ kubelet 使用优先级来确定
1. 相对于请求的资源使用量
有关更多详细信息，请参阅
[kubelet 驱逐时 Pod 的选择](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。
[kubelet 驱逐时 Pod 的选择](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。
当某 Pod 的资源用量未超过其请求时，kubelet 节点压力驱逐不会驱逐该 Pod。
如果优先级较低的 Pod 没有超过其请求，则不会被驱逐。
@@ -663,7 +663,7 @@ kubelet 使用优先级来确定
* Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
-->
* 阅读有关将 ResourceQuota 与 PriorityClass 结合使用的信息：
[默认限制优先级消费](/zh/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
* 了解 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/)
[默认限制优先级消费](/zh-cn/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
* 了解 [Pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/)
* 了解 [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/)
* 了解[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* 了解[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+4 -4
View File
@@ -23,7 +23,7 @@ is the Kubernetes default scheduler. It is responsible for placement of Pods
on Nodes in a cluster.
-->
作为 kubernetes 集群的默认调度器，
[kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)
[kube-scheduler](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)
主要负责将 Pod 调度到集群的 Node 上。
<!--
@@ -85,7 +85,7 @@ To change the value, edit the
and then restart the scheduler.
In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml`
-->
要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)
要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
然后重启调度器。
大多数情况下，这个配置文件是 `/etc/kubernetes/config/kube-scheduler.yaml`。
@@ -128,7 +128,7 @@ stops searching for more feasible nodes and moves on to the
kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果
kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量，
kube-scheduler 将停止继续查找可调度节点并继续进行
[打分阶段](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。
[打分阶段](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。
<!--
[How the scheduler iterates over Nodes](#how-the-scheduler-iterates-over-nodes)
@@ -300,4 +300,4 @@ After going over all the Nodes, it goes back to Node 1.
<!-- * Check the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) -->
* 参见 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)
* 参见 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md
+2 -2
View File
@@ -451,7 +451,7 @@ enabled by default.
-->
你可以在调度器配置中启用或禁用插件。
如果你在使用 Kubernetes v1.18 或更高版本，大部分调度
[插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)
[插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)
都在使用中且默认启用。
<!--
@@ -470,6 +470,6 @@ Learn more at [multiple profiles](/docs/reference/scheduling/config/#multiple-pr
-->
如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为
一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
了解更多关于[多配置文件](/zh/docs/reference/scheduling/config/#multiple-profiles)。
了解更多关于[多配置文件](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)。
content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md
+10 -10
View File
@@ -11,7 +11,7 @@ is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attrac
a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods.
-->
[_节点亲和性_](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
[_节点亲和性_](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
是 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的一种属性，它使 Pod
被吸引到一类特定的{{< glossary_tooltip text="节点" term_id="node" >}}
（这可能出于一种偏好，也可能是硬性要求）。
@@ -270,7 +270,7 @@ onto nodes labeled with `dedicated=groupName`.
* **专用节点**：如果你想将某些节点专门分配给特定的一组用户使用，你可以给这些节点添加一个污点（即，
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`），
然后给这组用户的 Pod 添加一个相对应的 toleration（通过编写一个自定义的
[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)，很容易就能做到）。
[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)，很容易就能做到）。
拥有上述容忍度的 Pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。
如果你希望这些 Pod 只能被分配到上述专用节点，那么你还需要给这些专用节点另外添加一个和上述
污点类似的 label （例如：`dedicated=groupName`），同时 还要在上述准入控制器中给 Pod
@@ -306,10 +306,10 @@ manually add tolerations to your pods.
`kubectl taint nodes nodename special=true:PreferNoSchedule`)，
然后给使用了这类特殊硬件的 Pod 添加一个相匹配的 toleration。
和专用节点的例子类似，添加这个容忍度的最简单的方法是使用自定义
[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。
比如，我们推荐使用[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)
[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)。
比如，我们推荐使用[扩展资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources)
来表示特殊硬件，给配置了特殊硬件的节点添加污点时包含扩展资源名称，
然后运行一个 [ExtendedResourceToleration](/zh/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration)
然后运行一个 [ExtendedResourceToleration](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration)
准入控制器。此时，因为节点已经被设置污点了，没有对应容忍度的 Pod
不会被调度到这些节点。但当你创建一个使用了扩展资源的 Pod 时，
`ExtendedResourceToleration` 准入控制器会自动给 Pod 加上正确的容忍度，
@@ -395,7 +395,7 @@ as the master becoming partitioned from the nodes.
-->
{{< note >}}
为了保证由于节点问题引起的 Pod 驱逐
[速率限制](/zh/docs/concepts/architecture/nodes/)行为正常，
[速率限制](/zh-cn/docs/concepts/architecture/nodes/)行为正常，
系统实际上会以限定速率的方式添加污点。在像主控节点与工作节点间通信中断等场景下，
这样做可以避免 Pod 被大量驱逐。
{{< /note >}}
@@ -461,7 +461,7 @@ Nodes for 5 minutes after one of these problems is detected.
This ensures that DaemonSet pods are never evicted due to these problems.
-->
[DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/) 中的 Pod 被创建时，
[DaemonSet](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 中的 Pod 被创建时，
针对以下污点自动添加的 `NoExecute` 的容忍度将不会指定 `tolerationSeconds`：
* `node.kubernetes.io/unreachable`
@@ -487,7 +487,7 @@ control plane adds the `node.kubernetes.io/memory-pressure` taint.
-->
控制平面使用节点{{<glossary_tooltip text="控制器" term_id="controller">}}自动创建
与[节点状况](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)对应的带有 `NoSchedule` 效应的污点。
与[节点状况](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)对应的带有 `NoSchedule` 效应的污点。
调度器在进行调度时检查污点，而不是检查节点状况。这确保节点状况不会直接影响调度。
例如，如果 `DiskPressure` 节点状况处于活跃状态，则控制平面
@@ -544,5 +544,5 @@ arbitrary tolerations to DaemonSets.
* Read about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) and how you can configure it
* Read about [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
-->
* 阅读[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)，以及如何配置其行为
* 阅读 [Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
* 阅读[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)，以及如何配置其行为
* 阅读 [Pod 优先级](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
content/zh-cn/docs/concepts/security/controlling-access.md
+21 -21
View File
@@ -28,8 +28,8 @@ authorized for API access.
When a request reaches the API, it goes through several stages, illustrated in the
following diagram:
-->
用户使用 `kubectl`、客户端库或构造 REST 请求来访问 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)。
人类用户和 [Kubernetes 服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。
用户使用 `kubectl`、客户端库或构造 REST 请求来访问 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/)。
人类用户和 [Kubernetes 服务账户](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。
当请求到达 API 时，它会经历多个阶段，如下图所示：
![Kubernetes API 请求处理步骤示意图](/images/docs/admin/access-control-overview.svg)
@@ -72,7 +72,7 @@ Authenticators are described in more detail in
-->
如上图步骤 **1** 所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。
集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。
身份认证组件在[认证](/zh/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。
身份认证组件在[认证](/zh-cn/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。
<!--
The input to the authentication step is the entire HTTP request; however, it typically
@@ -182,7 +182,7 @@ Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhoo
如果所有模块拒绝了该请求，请求将会被拒绝（HTTP 状态码 403）。
要了解更多有关 Kubernetes 鉴权的更多信息，包括有关使用支持鉴权模块创建策略的详细信息，
请参阅[鉴权](/zh/docs/reference/access-authn-authz/authorization/)。
请参阅[鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/)。
<!-- ## Admission control -->
## 准入控制 {#admission-control}
@@ -223,7 +223,7 @@ for the corresponding API object, and then written to the object store (shown as
除了拒绝对象之外，准入控制器还可以为字段设置复杂的默认值。
可用的准入控制模块在[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。
可用的准入控制模块在[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。
请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 **4** 所示）。
@@ -241,7 +241,7 @@ For more information, see [Auditing](/docs/tasks/debug/debug-cluster/audit/).
Kubernetes 审计提供了一套与安全相关的、按时间顺序排列的记录，其中记录了集群中的操作序列。
集群对用户、使用 Kubernetes API 的应用程序以及控制平面本身产生的活动进行审计。
更多信息请参考 [审计](/zh/docs/tasks/debug/debug-cluster/audit/).
更多信息请参考 [审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/).
<!-- ## API server ports and IPs -->
## API 服务器端口和 IP {#api-server-ports-and-ips}
@@ -327,23 +327,23 @@ You can learn about:
-->
阅读更多有关身份认证、鉴权和 API 访问控制的文档：
- [认证](/zh/docs/reference/access-authn-authz/authentication/)
- [使用 Bootstrap 令牌进行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)
- [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
- [动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [鉴权](/zh/docs/reference/access-authn-authz/authorization/)
- [基于角色的访问控制](/zh/docs/reference/access-authn-authz/rbac/)
- [基于属性的访问控制](/zh/docs/reference/access-authn-authz/abac/)
- [节点鉴权](/zh/docs/reference/access-authn-authz/node/)
- [Webhook 鉴权](/zh/docs/reference/access-authn-authz/webhook/)
- [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
- 包括 [CSR 认证](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
和[证书签名](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
- [认证](/zh-cn/docs/reference/access-authn-authz/authentication/)
- [使用 Bootstrap 令牌进行身份认证](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/)
- [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)
- [动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/)
- [基于角色的访问控制](/zh-cn/docs/reference/access-authn-authz/rbac/)
- [基于属性的访问控制](/zh-cn/docs/reference/access-authn-authz/abac/)
- [节点鉴权](/zh-cn/docs/reference/access-authn-authz/node/)
- [Webhook 鉴权](/zh-cn/docs/reference/access-authn-authz/webhook/)
- [证书签名请求](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/)
- 包括 [CSR 认证](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
和[证书签名](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
- 服务账户
- [开发者指导](/zh/docs/tasks/configure-pod-container/configure-service-account/)
- [管理](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
- [开发者指导](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)
- [管理](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/)
你可以了解
- Pod 如何使用
[Secrets](/zh/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
[Secrets](/zh-cn/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
获取 API 凭证.
content/zh-cn/docs/concepts/security/overview.md
+17 -17
View File
@@ -165,7 +165,7 @@ good information practices, read and follow the advice about
-->
### 集群组件 {#cluster-components}
如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/)的建议。
如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/)的建议。
<!--
### Components in the cluster (your application) {#cluster-applications}
@@ -196,13 +196,13 @@ TLS for Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networ
工作负载安全性关注领域 | 建议 |
------------------------------ | --------------------- |
RBAC 授权(访问 Kubernetes API) | https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/
认证方式 | https://kubernetes.io/zh/docs/concepts/security/controlling-access/
应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密) | https://kubernetes.io/zh/docs/concepts/configuration/secret/ <br> https://kubernetes.io/zh/docs/tasks/administer-cluster/encrypt-data/
确保 Pod 符合定义的 Pod 安全标准 | https://kubernetes.io/zh/docs/concepts/security/pod-security-standards/#policy-instantiation
服务质量（和集群资源管理）| https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/
网络策略 | https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/
Kubernetes Ingress 的 TLS 支持 | https://kubernetes.io/zh/docs/concepts/services-networking/ingress/#tls
RBAC 授权(访问 Kubernetes API) | https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/
认证方式 | https://kubernetes.io/zh-cn/docs/concepts/security/controlling-access/
应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密) | https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/ <br> https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/encrypt-data/
确保 Pod 符合定义的 Pod 安全标准 | https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards/#policy-instantiation
服务质量（和集群资源管理）| https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/
网络策略 | https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/
Kubernetes Ingress 的 TLS 支持 | https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#tls
<!--
## Container
@@ -226,7 +226,7 @@ Use container runtime with stronger isolation | Select [container runtime classe
容器漏洞扫描和操作系统依赖安全性 | 作为镜像构建的一部分，你应该扫描你的容器里的已知漏洞。
镜像签名和执行 | 对容器镜像进行签名，以维护对容器内容的信任。
禁止特权用户 | 构建容器时，请查阅文档以了解如何在具有最低操作系统特权级别的容器内部创建用户，以实现容器的目标。
使用带有较强隔离能力的容器运行时 | 选择提供较强隔离能力的[容器运行时类](/zh/docs/concepts/containers/runtime-class/)。
使用带有较强隔离能力的容器运行时 | 选择提供较强隔离能力的[容器运行时类](/zh-cn/docs/concepts/containers/runtime-class/)。
<!--
## Code
@@ -283,12 +283,12 @@ Learn about related Kubernetes security topics:
-->
学习了解相关的 Kubernetes 安全主题：
* [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
* [Pod 的网络策略](/zh/docs/concepts/services-networking/network-policies/)
* [控制对 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)
* [保护你的集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/)
* 为控制面[加密通信中的数据](/zh/docs/tasks/tls/managing-tls-in-a-cluster/)
* [加密静止状态的数据](/zh/docs/tasks/administer-cluster/encrypt-data/)
* [Kubernetes 中的 Secret](/zh/docs/concepts/configuration/secret/)
* [运行时类](/zh/docs/concepts/containers/runtime-class)
* [Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)
* [Pod 的网络策略](/zh-cn/docs/concepts/services-networking/network-policies/)
* [控制对 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/)
* [保护你的集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/)
* 为控制面[加密通信中的数据](/zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/)
* [加密静止状态的数据](/zh-cn/docs/tasks/administer-cluster/encrypt-data/)
* [Kubernetes 中的 Secret](/zh-cn/docs/concepts/configuration/secret/)
* [运行时类](/zh-cn/docs/concepts/containers/runtime-class)
content/zh-cn/docs/concepts/security/pod-security-admission.md
+16 -16
View File
@@ -29,7 +29,7 @@ The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-sta
different isolation levels for Pods. These standards let you define how you want to restrict the
behavior of pods in a clear, consistent fashion.
-->
Kubernetes [Pod 安全性标准（Security Standards）](/zh/docs/concepts/security/pod-security-standards/)
Kubernetes [Pod 安全性标准（Security Standards）](/zh-cn/docs/concepts/security/pod-security-standards/)
为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。
<!--
@@ -41,7 +41,7 @@ are created.
-->
作为一项 Beta 功能特性，Kubernetes 提供一种内置的 _Pod 安全性_
{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}，
作为 [PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/)
作为 [PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/)
特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在
{{< glossary_tooltip text="名字空间" term_id="namespace" >}}层面实施的。
@@ -51,7 +51,7 @@ The PodSecurityPolicy API is deprecated and will be
[removed](/docs/reference/using-api/deprecation-guide/#v1-25) from Kubernetes in v1.25.
-->
PodSecurityPolicy API 已经被废弃，会在 Kubernetes v1.25 发行版中
[移除](/zh/docs/reference/using-api/deprecation-guide/#v1-25)。
[移除](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-25)。
{{< /note >}}
<!-- body -->
@@ -75,7 +75,7 @@ is a beta feature and is enabled by default. You must have this feature gate ena
If you are running a different version of Kubernetes, consult the documentation for that release.
-->
在 Kubernetes v{{< skew currentVersion >}} 中，`PodSecurity`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性，
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性，
默认被启用。你必须启用此功能门控。如果你运行的是不同版本的 Kubernetes，请查阅该版本的文档。
@@ -132,11 +132,11 @@ Standards](/docs/concepts/security/pod-security-standards): `privileged`, `basel
`restricted`. Refer to the [Pod Security Standards](/docs/concepts/security/pod-security-standards)
page for an in-depth look at those requirements.
-->
Pod 安全性准入插件对 Pod 的[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)
有一定的要求，并且依据 [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)
Pod 安全性准入插件对 Pod 的[安全性上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)
有一定的要求，并且依据 [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards)
所定义的三个级别（`privileged`、`baseline` 和 `restricted`）对其他字段也有要求。
关于这些需求的更进一步讨论，请参阅
[Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)页面。
[Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)页面。
<!--
## Pod Security Admission labels for namespaces
@@ -170,7 +170,7 @@ Mode | Description
模式 | 描述
:---------|:------------
**enforce** | 策略违例会导致 Pod 被拒绝
**audit** | 策略违例会触发[审计日志](/zh/docs/tasks/debug/debug-cluster/audit/)中记录新事件时添加审计注解；但是 Pod 仍是被接受的。
**audit** | 策略违例会触发[审计日志](/zh-cn/docs/tasks/debug/debug-cluster/audit/)中记录新事件时添加审计注解；但是 Pod 仍是被接受的。
**warn** | 策略违例会触发用户可见的警告信息，但是 Pod 仍是被接受的。
{{< /table >}}
@@ -216,7 +216,7 @@ pod-security.kubernetes.io/<MODE>-version: <VERSION>
Check out [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) to see example usage.
-->
关于用法示例，可参阅
[使用名字空间标签来强制实施 Pod 安全标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。
[使用名字空间标签来强制实施 Pod 安全标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。
<!--
## Workload resources and Pod templates
@@ -232,7 +232,7 @@ applied to workload resources, only to the resulting pod objects.
## 负载资源和 Pod 模板 {#workload-resources-and-pod-templates}
Pod 通常是通过创建 {{< glossary_tooltip term_id="deployment" >}} 或
{{< glossary_tooltip term_id="job">}} 这类[工作负载对象](/zh/docs/concepts/workloads/controllers/)
{{< glossary_tooltip term_id="job">}} 这类[工作负载对象](/zh-cn/docs/concepts/workloads/controllers/)
来间接创建的。工作负载对象为工作负载资源定义一个 _Pod 模板_ 和一个对应的
负责基于该模板来创建 Pod 的{{< glossary_tooltip term_id="controller" text="控制器" >}}。
为了尽早地捕获违例状况，`audit` 和 `warn` 模式都应用到负载资源。
@@ -250,7 +250,7 @@ Exemptions can be statically configured in the
你可以为 Pod 安全性的实施设置 _豁免（Exemptions）_ 规则，
从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。
豁免规则可以在[准入控制器配置](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
豁免规则可以在[准入控制器配置](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
中静态配置。
<!--
@@ -322,9 +322,9 @@ current policy level:
- [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels)
- [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp)
-->
- [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)
- [强制实施 Pod 安全性标准](/zh/docs/setup/best-practices/enforcing-pod-security-standards/)
- [通过配置内置的准入控制器强制实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)
- [使用名字空间标签来实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)
- [从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)
- [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)
- [强制实施 Pod 安全性标准](/zh-cn/docs/setup/best-practices/enforcing-pod-security-standards/)
- [通过配置内置的准入控制器强制实施 Pod 安全性标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)
- [使用名字空间标签来实施 Pod 安全性标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)
- [从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/)
content/zh-cn/docs/concepts/security/pod-security-policy.md
+20 -20
View File
@@ -24,9 +24,9 @@ For more information on the deprecation,
see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/).
-->
PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，**将在 v1.25 中删除**。
我们建议迁移到 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission)，
我们建议迁移到 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission)，
或者第三方的准入插件。
若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。
若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/)。
关于弃用的更多信息，请查阅 [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。
{{< /caution >}}
@@ -107,8 +107,8 @@ cluster.
-->
## 启用 Pod 安全策略 {#enabling-pod-security-policies}
Pod 安全策略实现为一种可选的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。
[启用了准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)即可强制实施
Pod 安全策略实现为一种可选的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。
[启用了准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)即可强制实施
Pod 安全策略，不过如果没有授权认可策略之前即启用准入控制器 **将导致集群中无法创建任何 Pod**。
<!--
@@ -132,7 +132,7 @@ must be authorized to use the policy, by allowing the `use` verb on the policy.
PodSecurityPolicy 资源被创建时，并不执行任何操作。为了使用该资源，
需要对发出请求的用户或者目标 Pod
的[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)授权，
的[服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)授权，
通过允许其对策略执行 `use` 动词允许其使用该策略。
<!--
@@ -146,8 +146,8 @@ so the preferred method for authorizing policies is to grant access to the
pod's service account (see [example](#run-another-pod)).
-->
大多数 Kubernetes Pod 不是由用户直接创建的。相反，这些 Pod 是由
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)
[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)、
[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/)
或者经由控制器管理器模版化的控制器创建。
赋予控制器访问策略的权限意味着对应控制器所创建的 *所有* Pod 都可访问策略。
因此，对策略进行授权的优先方案是为 Pod 的服务账号授予访问权限
@@ -164,7 +164,7 @@ policies. The rules to grant access look like this:
-->
### 通过 RBAC 授权 {#via-rbac}
[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes
[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes
鉴权模式，可以很容易地用来授权策略访问。
首先，某 `Role` 或 `ClusterRole` 需要获得使用 `use` 访问目标策略的权限。
@@ -272,7 +272,7 @@ For more examples of RBAC bindings, see
[Role Binding Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples).
For a complete example of authorizing a PodSecurityPolicy, see [below](#example).
-->
参阅[角色绑定示例](/zh/docs/reference/access-authn-authz/rbac#role-binding-examples)查看
参阅[角色绑定示例](/zh-cn/docs/reference/access-authn-authz/rbac#role-binding-examples)查看
RBAC 绑定的更多实例。
参阅[下文](#example)，查看对 PodSecurityPolicy 进行授权的完整示例。
@@ -303,7 +303,7 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity`
- {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
-->
1. 将 PodSecurityPolicies 限制为
[Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)所定义的策略：
[Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards)所定义的策略：
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
@@ -371,9 +371,9 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity`
-->
### 故障排查 {#troubleshooting}
- [控制器管理器组件](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
- [控制器管理器组件](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
必须运行在安全的 API 端口之上，并且不能拥有超级用户的访问权限。
参阅[控制 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access)以了解
参阅[控制 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access)以了解
API 服务器的访问控制。
如果控制器管理器通过可信的 API 端口连接（也称作 `localhost` 监听组件），
@@ -381,7 +381,7 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity`
用户亦能授予自身创建特权容器的特权。
关于配置控制器管理器鉴权的进一步细节，
请参阅[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)。
请参阅[控制器角色](/zh-cn/docs/reference/access-authn-authz/rbac/#controller-roles)。
<!--
## Policy Order
@@ -467,7 +467,7 @@ The name of a PodSecurityPolicy object must be a valid
在一个文件中定义一个示例的 PodSecurityPolicy 对象。
这里的策略只是用来禁止创建有特权要求的 Pods。
PodSecurityPolicy 对象的名称必须是合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
{{< codenew file="policy/example-psp.yaml" >}}
@@ -794,7 +794,7 @@ several security mechanisms.
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
-->
更多的示例可参考
[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。
[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/#policy-instantiation)。
<!--
## Policy Reference
@@ -868,7 +868,7 @@ The **recommended minimum set** of allowed volumes for new PSPs are:
### 卷和文件系统 {#volumes-and-file-systems}
**Volumes** - 提供一组被允许的卷类型列表。可被允许的值对应于创建卷时可以设置的卷来源。
卷类型的完整列表可参见[卷类型](/zh/docs/concepts/storage/volumes/#types-of-volumes)。
卷类型的完整列表可参见[卷类型](/zh-cn/docs/concepts/storage/volumes/#types-of-volumes)。
此外，`*` 可以用来允许所有卷类型。
对于新的 Pod 安全策略设置而言，建议设置的卷类型的**最小列表**包含：
@@ -1235,7 +1235,7 @@ documentation](/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations).
通过 PodSecurityPolicy 上的注解来控制。
详情请参阅
[AppArmor 文档](/zh/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations)。
[AppArmor 文档](/zh-cn/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations)。
<!--
@@ -1255,7 +1255,7 @@ are:
### Seccomp
从 Kubernetes v1.19 开始，你可以使用 Pod 或容器的 `securityContext` 中的 `seccompProfile`
字段来[控制 seccomp 配置的使用](/zh/docs/tutorials/security/seccomp/)。
字段来[控制 seccomp 配置的使用](/zh-cn/docs/tutorials/security/seccomp/)。
在更早的版本中，seccomp 是通过为 Pod 添加注解来控制的。
相同的 PodSecurityPolicy 可以用于不同版本，进而控制如何应用对应的字段或注解。
@@ -1336,7 +1336,7 @@ By default, all safe sysctls are allowed.
<!--
Refer to the [Sysctl documentation](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy).
-->
参阅 [Sysctl 文档](/zh/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。
参阅 [Sysctl 文档](/zh-cn/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。
## {{% heading "whatsnext" %}}
@@ -1353,7 +1353,7 @@ Refer to the [Sysctl documentation](/docs/tasks/administer-cluster/sysctl-cluste
Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)，
了解 Pod 安全策略的未来。
- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)，
- 参阅[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)，
了解策略建议。
- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)，
了解 API 细节。
content/zh-cn/docs/concepts/security/pod-security-standards.md
+7 -7
View File
@@ -117,7 +117,7 @@ fail validation.
</td> -->
<td>
<p>Windows Pod 提供了运行
<a href="/zh/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess 容器</a> 的能力，
<a href="/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess 容器</a> 的能力，
这使得对 Windows 节点的特权访问成为可能。
基线策略中对宿主的特权访问是被禁止的。
HostProcess Pod 是 Kubernetes <strong>v1.22</strong> 版本的
@@ -833,13 +833,13 @@ of individual policies are not defined here.
随着相关机制的成熟，这些机制会按策略分别定义在下面。特定策略的实施方法不在这里定义。
[**Pod 安全性准入控制器**](/zh/docs/concepts/security/pod-security-admission/)
[**Pod 安全性准入控制器**](/zh-cn/docs/concepts/security/pod-security-admission/)
- {{< example file="security/podsecurity-privileged.yaml" >}}Privileged 名字空间{{< /example >}}
- {{< example file="security/podsecurity-baseline.yaml" >}}Baseline 名字空间{{< /example >}}
- {{< example file="security/podsecurity-restricted.yaml" >}}Restricted 名字空间{{< /example >}}
[**PodSecurityPolicy**](/zh/docs/concepts/security/pod-security-policy/) （已弃用）
[**PodSecurityPolicy**](/zh-cn/docs/concepts/security/pod-security-policy/) （已弃用）
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
@@ -896,7 +896,7 @@ in the Pod manifest, and represent parameters to the container runtime.
-->
### 安全策略与安全上下文的区别是什么？
[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod
[安全上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod
和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的，
所代表的是传递给容器运行时的参数。
@@ -908,8 +908,8 @@ built-in [Pod Security Admission Controller](/docs/concepts/security/pod-securit
-->
安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。
在 2020 年 7 月，
[Pod 安全性策略](/zh/docs/concepts/security/pod-security-policy/)已被废弃，
取而代之的是内置的 [Pod 安全性准入控制器](/zh/docs/concepts/security/pod-security-admission/)。
[Pod 安全性策略](/zh-cn/docs/concepts/security/pod-security-policy/)已被废弃，
取而代之的是内置的 [Pod 安全性准入控制器](/zh-cn/docs/concepts/security/pod-security-admission/)。
<!--
### What profiles should I apply to my Windows Pods?
@@ -923,7 +923,7 @@ such, no standardized Pod Security profiles currently exists.
Kubernetes 中的 Windows 负载与标准的基于 Linux 的负载相比有一些局限性和区别。
尤其是 Pod SecurityContext
字段[对 Windows 不起作用](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
字段[对 Windows 不起作用](/zh-cn/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
因此，目前没有对应的标准 Pod 安全性框架。
<!--
content/zh-cn/docs/concepts/security/rbac-good-practices.md
+11 -11
View File
@@ -31,7 +31,7 @@ Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}}
降低因过多权限而导致安全事件的风险。
此文档的良好实践应该与通用
[RBAC 文档](/zh/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)一起阅读。
[RBAC 文档](/zh-cn/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)一起阅读。
<!-- body -->
@@ -74,7 +74,7 @@ some general rules that can be applied are :
由于 Kubernetes 是一个可扩展的系统，因此通过通配符来授予访问权限不仅会授予集群中当前的所有对象类型，
还包含所有未来被创建的所有对象类型。
- 管理员不应使用 `cluster-admin` 账号，除非特别需要。为低特权帐户提供
[伪装权限](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation)
[伪装权限](/zh-cn/docs/reference/access-authn-authz/authentication/#user-impersonation)
可以避免意外修改集群资源。
- 避免将用户添加到 `system:masters` 组。任何属于此组成员的用户都会绕过所有 RBAC 权限检查，
始终具有不受限制的超级用户访问权限，并且不能通过删除 `RoleBinding` 或 `ClusterRoleBinding`
@@ -102,9 +102,9 @@ In cases where a workload requires powerful permissions, consider the following
- 限制运行此类 Pod 的节点数量。确保你运行的任何 DaemonSet 都是必需的，
并且以最小权限运行，以限制容器逃逸的影响范围。
- 避免将此类 Pod 与不可信任或公开的 Pod 在一起运行。
考虑使用[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)、
[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)或
[Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)确保
考虑使用[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)、
[节点亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)或
[Pod 反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)确保
Pod 不会与不可信或不太受信任的 Pod 一起运行。
特别注意可信度不高的 Pod 不符合 **Restricted** Pod 安全标准的情况。
<!--
@@ -133,7 +133,7 @@ Kubernetes 默认提供访问权限并非是每个集群都需要的。
- 审查 `system:unauthenticated` 组的绑定，并在可能的情况下将其删除，
因为这会给所有能够访问 API 服务器的人以网络级别的权限。
- 通过设置 `automountServiceAccountToken: false` 来避免服务账号令牌的默认自动挂载，
有关更多详细信息，请参阅[使用默认服务账号令牌](/zh/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)。
有关更多详细信息，请参阅[使用默认服务账号令牌](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)。
此参数可覆盖 Pod 服务账号设置，而需要服务账号令牌的工作负载仍可以挂载。
<!--
@@ -192,9 +192,9 @@ be able to gain access to the underlying node unless restrictions based on the K
-->
### 工作负载的创建 {#workload-creation}
能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh/docs/concepts/workloads/controllers/)）
能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)）
能够访问下层的节点，除非基于 Kubernetes 的
[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)做限制。
[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)做限制。
<!--
Users who can run privileged Pods can use that access to gain node access and potentially to
@@ -208,7 +208,7 @@ or other (third party) mechanisms to implement that enforcement.
并可能进一步提升他们的特权。如果你不完全信任某用户或其他主体，
不相信他们能够创建比较安全且相互隔离的 Pod，你应该强制实施 **Baseline**
或 **Restricted** Pod 安全标准。
你可以使用 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)或其他（第三方）机制来强制实施这些限制。
你可以使用 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或其他（第三方）机制来强制实施这些限制。
<!--
You can also use the deprecated [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) mechanism
@@ -264,7 +264,7 @@ users with this right can effectively escalate their privileges.
### esclate 动词 {#escalate-verb}
通常，RBAC 系统会阻止用户创建比他所拥有的更多权限的 `ClusterRole`。
而 `escalate` 动词是个例外。如
[RBAC 文档](/zh/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)
[RBAC 文档](/zh-cn/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)
中所述，拥有此权限的用户可以有效地提升他们的权限。
<!--
@@ -352,4 +352,4 @@ to limit the quantity of objects which can be created.
产生拒绝服务状况，如 [Kubernetes 使用的 etcd 容易受到 OOM 攻击](https://github.com/kubernetes/kubernetes/issues/107325)中的讨论。
允许太不受信任或者不受信任的用户对系统进行有限的访问在多租户集群中是特别重要的。
缓解此问题的一种选择是使用[资源配额](/zh/docs/concepts/policy/resource-quotas/#object-count-quota)以限制可以创建的对象数量。
缓解此问题的一种选择是使用[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/#object-count-quota)以限制可以创建的对象数量。
content/zh-cn/docs/concepts/security/windows-security.md
+2 -2
View File
@@ -56,7 +56,7 @@ can be specified for Windows Pods or containers to execute the container
processes as specific user. This is roughly equivalent to
[RunAsUser](/docs/concepts/policy/pod-security-policy/#users-and-groups).
-->
可以为 Windows Pod 或容器指定 [RunAsUsername](/zh/docs/tasks/configure-pod-container/configure-runasusername)
可以为 Windows Pod 或容器指定 [RunAsUsername](/zh-cn/docs/tasks/configure-pod-container/configure-runasusername)
以作为特定用户执行容器进程。这大致相当于 [RunAsUser](/zh-cn/docs/concepts/security/pod-security-policy/#users-and-groups)。
<!--
@@ -86,7 +86,7 @@ Local users can be added to container images during the container build process.
<!--
Windows containers can also run as Active Directory identities by utilizing [Group Managed Service Accounts](/docs/tasks/configure-pod-container/configure-gmsa/)
-->
Windows 容器还可以通过使用[组管理的服务账号](/zh/docs/tasks/configure-pod-container/configure-gmsa/)作为
Windows 容器还可以通过使用[组管理的服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/)作为
Active Directory 身份运行。
<!--
content/zh-cn/docs/concepts/services-networking/_index.md
+1 -1
View File
@@ -21,7 +21,7 @@ application configuration, and migration.
独一无二的 IP 地址，
这就意味着你不需要显式地在 `Pod` 之间创建链接，你几乎不需要处理容器端口到主机端口之间的映射。
这将形成一个干净的、向后兼容的模型；在这个模型里，从端口分配、命名、服务发现、
[负载均衡](/zh/docs/concepts/services-networking/ingress/#load-balancing)、
[负载均衡](/zh-cn/docs/concepts/services-networking/ingress/#load-balancing)、
应用配置和迁移的角度来看，`Pod` 可以被视作虚拟机或者物理主机。
<!--
content/zh-cn/docs/concepts/services-networking/connect-applications-service.md
+7 -7
View File
@@ -82,7 +82,7 @@ You can read more about the [Kubernetes Networking Model](/docs/concepts/cluster
Pod 或节点上使用 IP 的方式访问到它们。
如果你想的话，你依然可以将宿主节点的某个端口的流量转发到 Pod 中，但是出于网络模型的原因，你不必这么做。
如果对此好奇，请参考 [Kubernetes 网络模型](/zh/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model)。
如果对此好奇，请参考 [Kubernetes 网络模型](/zh-cn/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model)。
<!--
## Creating a Service
@@ -193,7 +193,7 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip
现在，你应该能够从集群中任意节点上使用 curl 命令向 `<CLUSTER-IP>:<PORT>` 发送请求以访问 Nginx Service。
注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇，
可以进一步阅读[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
可以进一步阅读[服务代理](/zh-cn/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
的内容。
<!--
@@ -312,7 +312,7 @@ IP 分配名称的 DNS 服务器。 这里我们使用 CoreDNS 集群插件（
所以在集群中的任何 Pod 中，你都可以使用标准方法（例如：`gethostbyname()`）与该 Service 通信。
如果 CoreDNS 没有在运行，你可以参照
[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes)
或者[安装 CoreDNS](/zh/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
或者[安装 CoreDNS](/zh-cn/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
让我们运行另一个 curl 应用来进行测试：
```shell
@@ -357,7 +357,7 @@ You can acquire all these from the [nginx https example](https://github.com/kube
* 用于 HTTPS 的自签名证书（除非已经有了一个身份证书）
* 使用证书配置的 Nginx 服务器
* 使 Pod 可以访问证书的 [Secret](/zh/docs/concepts/configuration/secret/)
* 使 Pod 可以访问证书的 [Secret](/zh-cn/docs/concepts/configuration/secret/)
你可以从
[Nginx https 示例](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)获取所有上述内容。
@@ -620,6 +620,6 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
* Learn more about [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/)
* Learn more about [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
-->
* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)
* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/)
* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)
* 进一步了解如何[使用 Service 访问集群中的应用](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)
* 进一步了解如何[使用 Service 将前端连接到后端](/zh-cn/docs/tasks/access-application-cluster/connecting-frontend-backend/)
* 进一步了解如何[创建外部负载均衡器](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/)
content/zh-cn/docs/concepts/services-networking/dns-pod-service.md
+5 -5
View File
@@ -168,7 +168,7 @@ of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`
#### SRV 记录 {#srv-records}
Kubernetes 根据普通 Service 或
[Headless Service](/zh/docs/concepts/services-networking/service/#headless-services)
[Headless Service](/zh-cn/docs/concepts/services-networking/service/#headless-services)
中的命名端口创建 SRV 记录。每个命名端口，
SRV 记录格式为 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`。
普通 Service，该记录会被解析成端口号和域名：`my-svc.my-namespace.svc.cluster-domain.example`。
@@ -370,7 +370,7 @@ Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerC
（无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64
字符，请求字符数为 70）。
对于这种场景而言，改善用户体验的一种方式是创建一个
[准入 Webhook 控制器](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)，
[准入 Webhook 控制器](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)，
在用户创建顶层对象（如 Deployment）的时候控制 FQDN 的长度。
{{< /note >}}
@@ -405,11 +405,11 @@ DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod
这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置：
- "`Default`": Pod 从运行所在的节点继承名称解析配置。参考
[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers)
[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers)
获取更多信息。
- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"）
都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。
参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers)
参阅[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers)
了解在这些场景中如何处理 DNS 查询的信息。
- "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略
"`ClusterFirstWithHostNet`"。
@@ -609,5 +609,5 @@ For guidance on administering DNS configurations, check
[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
-->
有关管理 DNS 配置的指导，请查看
[配置 DNS 服务](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/)
[配置 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/)
content/zh-cn/docs/concepts/services-networking/endpoint-slices.md
+2 -2
View File
@@ -82,7 +82,7 @@ Kubernetes Service.
这些 EndpointSlice 将包含对与 Service 选择算符匹配的所有 Pod 的引用。
EndpointSlice 通过唯一的协议、端口号和 Service 名称将网络端点组织在一起。
EndpointSlice 的名称必须是合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
例如，下面是 Kubernetes Service `example` 的 EndpointSlice 资源示例。
@@ -459,5 +459,5 @@ implementation in `kube-proxy`.
<!--
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-->
* 阅读[使用 Service 连接到应用](/zh/docs/concepts/services-networking/connect-applications-service/)
* 阅读[使用 Service 连接到应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)
content/zh-cn/docs/concepts/services-networking/ingress-controllers.md
+6 -6
View File
@@ -143,13 +143,13 @@ You may deploy any number of ingress controllers using [ingress class](/docs/con
within a cluster. Note the `.metadata.name` of your ingress class resource. When you create an ingress you would need that name to specify the `ingressClassName` field on your Ingress object (refer to [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec). `ingressClassName` is a replacement of the older [annotation method](/docs/concepts/services-networking/ingress/#deprecated-annotation).
-->
你可以使用
[Ingress 类](/zh/docs/concepts/services-networking/ingress/#ingress-class)在集群中部署任意数量的
[Ingress 类](/zh-cn/docs/concepts/services-networking/ingress/#ingress-class)在集群中部署任意数量的
Ingress 控制器。
请注意你的 Ingress 类资源的 `.metadata.name` 字段。
当你创建 Ingress 时，你需要用此字段的值来设置 Ingress 对象的 `ingressClassName` 字段（请参考
[IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec)）。
`ingressClassName`
是之前的[注解](/zh/docs/concepts/services-networking/ingress/#deprecated-annotation)做法的替代。
是之前的[注解](/zh-cn/docs/concepts/services-networking/ingress/#deprecated-annotation)做法的替代。
<!--
If you do not specify an IngressClass for an Ingress, and your cluster has exactly one IngressClass marked as default, then Kubernetes [applies](/docs/concepts/services-networking/ingress/#default-ingress-class) the cluster's default IngressClass to the Ingress.
@@ -160,10 +160,10 @@ controllers operate slightly differently.
-->
如果你不为 Ingress 指定 IngressClass，并且你的集群中只有一个 IngressClass 被标记为默认，那么
Kubernetes 会将此集群的默认 IngressClass
[应用](/zh/docs/concepts/services-networking/ingress/#default-ingress-class)到 Ingress 上。
[应用](/zh-cn/docs/concepts/services-networking/ingress/#default-ingress-class)到 Ingress 上。
IngressClass。
你可以通过将
[`ingressclass.kubernetes.io/is-default-class` 注解](/zh/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class)
[`ingressclass.kubernetes.io/is-default-class` 注解](/zh-cn/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class)
的值设置为 `"true"` 来将一个 IngressClass 标记为集群默认。
理想情况下，所有 Ingress 控制器都应满足此规范，但各种 Ingress 控制器的操作略有不同。
@@ -181,6 +181,6 @@ Make sure you review your ingress controller's documentation to understand the c
* Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube).
-->
* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。
* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube)。
* 进一步了解 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)。
* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube)。
content/zh-cn/docs/concepts/services-networking/ingress.md
+23 -23
View File
@@ -36,7 +36,7 @@ For clarity, this guide defines the following terms:
在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。
* 边缘路由器（Edge Router）: 在集群中强制执行防火墙策略的路由器。可以是由云提供商管理的网关，也可以是物理硬件。
* 集群网络（Cluster Network）: 一组逻辑的或物理的连接，根据 Kubernetes
[网络模型](/zh/docs/concepts/cluster-administration/networking/)在集群内实现通信。
[网络模型](/zh-cn/docs/concepts/cluster-administration/networking/)在集群内实现通信。
* 服务（Service）：Kubernetes {{< glossary_tooltip term_id="service" >}}，
使用{{< glossary_tooltip text="标签" term_id="label" >}}选择器（selectors）辨认一组 Pod。
除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。
@@ -51,7 +51,7 @@ Traffic routing is controlled by rules defined on the Ingress resource.
## Ingress 是什么？ {#what-is-ingress}
[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
公开从集群外部到集群内[服务](/zh/docs/concepts/services-networking/service/)的
公开从集群外部到集群内[服务](/zh-cn/docs/concepts/services-networking/service/)的
HTTP 和 HTTPS 路由。
流量路由由 Ingress 资源上定义的规则控制。
@@ -66,7 +66,7 @@ Here is a simple example where an Ingress sends all its traffic to one Service:
An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
-->
Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。
[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)
[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)
通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。
<!--
@@ -76,8 +76,8 @@ uses a service of type [Service.Type=NodePort](/docs/concepts/services-networkin
-->
Ingress 不会公开任意端口或协议。
将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用
[Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport)
或 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer)
[Service.Type=NodePort](/zh-cn/docs/concepts/services-networking/service/#type-nodeport)
或 [Service.Type=LoadBalancer](/zh-cn/docs/concepts/services-networking/service/#loadbalancer)
类型的 Service。
<!--
@@ -87,7 +87,7 @@ You must have an [ingress controller](/docs/concepts/services-networking/ingress
-->
## 环境准备
你必须拥有一个 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。
你必须拥有一个 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。
仅创建 Ingress 资源本身没有任何效果。
<!--
@@ -95,7 +95,7 @@ You may need to deploy an Ingress controller such as [ingress-nginx](https://kub
[Ingress controllers](/docs/concepts/services-networking/ingress-controllers).
-->
你可能需要部署 Ingress 控制器，例如 [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)。
你可以从许多 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 中进行选择。
你可以从许多 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 中进行选择。
<!--
Ideally, all Ingress controllers should fit the reference specification. In reality, the various Ingress
@@ -133,13 +133,13 @@ Different [Ingress controllers](/docs/concepts/services-networking/ingress-contr
your choice of Ingress controller to learn which annotations are supported.
-->
Ingress 需要指定 `apiVersion`、`kind`、 `metadata`和 `spec` 字段。
Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
关于如何使用配置文件，请参见[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、
[配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)、
[管理资源](/zh/docs/concepts/cluster-administration/manage-deployment/)。
Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
关于如何使用配置文件，请参见[部署应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)、
[配置容器](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)、
[管理资源](/zh-cn/docs/concepts/cluster-administration/manage-deployment/)。
Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress
控制器，例如[重写目标注解](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。
不同的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)支持不同的注解。
不同的 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)支持不同的注解。
查看你所选的 Ingress 控制器的文档，以了解其支持哪些注解。
<!--
@@ -195,7 +195,7 @@ Each HTTP rule contains the following information:
如果提供了 `host`（例如 foo.bar.com），则 `rules` 适用于该 `host`。
* 路径列表 paths（例如，`/testpath`）,每个路径都有一个由 `serviceName` 和 `servicePort` 定义的关联后端。
在负载均衡器将流量定向到引用的服务之前，主机和路径都必须匹配传入请求的内容。
* `backend`（后端）是 [Service 文档](/zh/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。
* `backend`（后端）是 [Service 文档](/zh-cn/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。
与规则的 `host` 和 `path` 匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的 `backend`。
<!--
@@ -224,7 +224,7 @@ routed to your default backend.
没有设置规则的 Ingress 将所有流量发送到同一个默认后端，而
`.spec.defaultBackend` 则是在这种情况下处理请求的那个默认后端。
`defaultBackend` 通常是
[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)的配置选项，而非在
[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)的配置选项，而非在
Ingress 资源中指定。
如果未设置任何的 `.spec.rules`，那么必须指定 `.spec.defaultBackend`。
如果未设置 `defaultBackend`，那么如何处理所有与规则不匹配的流量将交由
@@ -524,7 +524,7 @@ that is used for a workload. If you used a cluster-scoped parameter then either:
网关定义）。如果你使用集群作用域的参数，那么你必须从以下两项中选择一项执行：
- 每次修改配置，集群操作团队需要批准其他团队的修改。
- 集群操作团队定义具体的准入控制，比如 [RBAC](/zh/docs/reference/access-authn-authz/rbac/)
- 集群操作团队定义具体的准入控制，比如 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)
角色与角色绑定，以使得应用程序团队可以修改集群作用域的配置参数资源。
<!--
@@ -739,8 +739,8 @@ you are using, you may need to create a default-http-backend
[Service](/docs/concepts/services-networking/service/).
-->
{{< note >}}
取决于你所使用的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)，
你可能需要创建默认 HTTP 后端[服务](/zh/docs/concepts/services-networking/service/)。
取决于你所使用的 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)，
你可能需要创建默认 HTTP 后端[服务](/zh-cn/docs/concepts/services-networking/service/)。
{{< /note >}}
<!--
@@ -881,7 +881,7 @@ specific documentation to see how they handle health checks (
-->
值得注意的是，尽管健康检查不是通过 Ingress 直接暴露的，在 Kubernetes
中存在并行的概念，比如
[就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)，
[就绪检查](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)，
允许你实现相同的目的。
请检查特定控制器的说明文档（[nginx](https://git.k8s.io/ingress-nginx/README.md)、
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)）以了解它们是怎样处理健康检查的。
@@ -1000,7 +1000,7 @@ Please check the documentation of the relevant [Ingress controller](/docs/concep
## 跨可用区失败 {#failing-across-availability-zones}
不同的云厂商使用不同的技术来实现跨故障域的流量分布。详情请查阅相关 Ingress 控制器的文档。
请查看相关 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。
请查看相关 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。
<!--
## Alternatives
@@ -1015,8 +1015,8 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
-->
* 使用 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer)
* 使用 [Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#nodeport)
* 使用 [Service.Type=LoadBalancer](/zh-cn/docs/concepts/services-networking/service/#loadbalancer)
* 使用 [Service.Type=NodePort](/zh-cn/docs/concepts/services-networking/service/#nodeport)
## {{% heading "whatsnext" %}}
@@ -1026,6 +1026,6 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/)
-->
* 进一步了解 [Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API
* 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/)
* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube/)
* 进一步了解 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/)
* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube/)
content/zh-cn/docs/concepts/services-networking/network-policies.md
+9 -9
View File
@@ -58,7 +58,7 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k
-->
## 前置条件 {#prerequisites}
网络策略通过[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
网络策略通过[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案。
创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。
@@ -144,8 +144,8 @@ __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the g
-->
__必需字段__：与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、
`kind` 和 `metadata` 字段。关于配置文件操作的一般信息，请参考
[配置 Pod 以使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/),
和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。
[配置 Pod 以使用 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/),
和[对象管理](/zh-cn/docs/concepts/overview/working-with-objects/object-management)。
__spec__：NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
中包含了在一个名字空间中定义特定网络策略所需的所有信息。
@@ -204,7 +204,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-
3. （Egress 规则）允许 “default” 命名空间中任何带有标签 “role=db” 的 Pod 到 CIDR
10.0.0.0/24 下 5978 TCP 端口的连接。
参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)演练
参阅[声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/)演练
了解更多示例。
<!--
@@ -422,7 +422,7 @@ When the feature gate is enabled, you can set the `protocol` field of a NetworkP
作为一个稳定特性，SCTP 支持默认是被启用的。
要在集群层面禁用 SCTP，你（或你的集群管理员）需要为 API 服务器指定
`--feature-gates=SCTPSupport=false,...`
来禁用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
来禁用 `SCTPSupport` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
启用该特性门控后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。
{{< note >}}
@@ -494,7 +494,7 @@ The following restrictions apply when using this field:
范围内禁止使用 `endPort` 字段，你（或者你的集群管理员）需要为 API
服务器设置 `--feature-gates=NetworkPolicyEndPort=false,...` 以禁用
`NetworkPolicyEndPort`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
* `endPort` 字段必须等于或者大于 `port` 字段的值。
* 两个字段的设置值都只能是数字。
@@ -508,7 +508,7 @@ the policy will be applied only for the single `port` field.
-->
你的集群所使用的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件
必须支持在 NetworkPolicy 规约中使用 `endPort` 字段。
如果你的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
如果你的[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
不支持 `endPort` 字段，而你指定了一个包含 `endPort` 字段的 NetworkPolicy，
策略只对单个 `port` 字段生效。
{{< /note >}}
@@ -530,7 +530,7 @@ While NetworkPolicy cannot target a namespace by its name with some object field
standardized label to target a specific namespace.
-->
只要 `NamespaceDefaultLabelName`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
被启用，Kubernetes 控制面会在所有名字空间上设置一个不可变更的标签
`kubernetes.io/metadata.name`。该标签的值是名字空间的名称。
@@ -588,7 +588,7 @@ As of Kubernetes {{< skew latestVersion >}}, the following functionality does no
walkthrough for further examples.
- See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.
-->
- 参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
- 参阅[声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/)
演练了解更多示例；
- 有关 NetworkPolicy 资源所支持的常见场景的更多信息，请参见
[此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。
content/zh-cn/docs/concepts/services-networking/service-topology.md
+4 -4
View File
@@ -25,7 +25,7 @@ introduced in Kubernetes v1.21, provide similar functionality.
-->
此功能特性，尤其是 Alpha 阶段的 `topologyKeys` API，在 Kubernetes v1.21
版本中已被废弃。Kubernetes v1.21 版本中引入的
[拓扑感知的提示](/zh/docs/concepts/services-networking/topology-aware-hints/),
[拓扑感知的提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints/),
提供类似的功能。
{{</ note >}}
@@ -104,7 +104,7 @@ as the last value in the list.
## 使用服务拓扑 {#using-service-topology}
如果集群启用了 `ServiceTopology`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
你就可以在 Service 规约中设定 `topologyKeys` 字段，从而控制其流量路由。
此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。
流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。
@@ -300,6 +300,6 @@ spec:
* Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-->
* 阅读关于[启用服务拓扑](/zh/docs/tasks/administer-cluster/enabling-service-topology/)
* 阅读[用服务连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)
* 阅读关于[启用服务拓扑](/zh-cn/docs/tasks/administer-cluster/enabling-service-topology/)
* 阅读[用服务连接应用程序](/zh-cn/docs/concepts/services-networking/connect-applications-service/)
content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md
+5 -5
View File
@@ -43,7 +43,7 @@ When the feature is enabled, you can enable the internal-only traffic policy for
This tells kube-proxy to only use node local endpoints for cluster internal traffic.
-->
`ServiceInternalTrafficPolicy`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 是 Beta 功能，默认启用。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 是 Beta 功能，默认启用。
启用该功能后，你就可以通过将 {{< glossary_tooltip text="Services" term_id="service" >}} 的
`.spec.internalTrafficPolicy` 项设置为 `Local`，
来为它指定一个内部专用的流量策略。
@@ -99,7 +99,7 @@ When the [feature gate](/docs/reference/command-line-tools-reference/feature-gat
kube-proxy 基于 `spec.internalTrafficPolicy` 的设置来过滤路由的目标服务端点。
当它的值设为 `Local` 时，只选择节点本地的服务端点。
当它的值设为 `Cluster` 或缺省时，则选择所有的服务端点。
启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
`ServiceInternalTrafficPolicy` 后，
`spec.internalTrafficPolicy` 的值默认设为 `Cluster`。
@@ -123,6 +123,6 @@ kube-proxy 基于 `spec.internalTrafficPolicy` 的设置来过滤路由的目标
* Read about [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-->
* 请阅读[拓扑感知提示](/zh/docs/concepts/services-networking/topology-aware-hints)
* 请阅读[Service 的外部流量策略](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)
* 请阅读[用 Service 连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
* 请阅读[拓扑感知提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints)
* 请阅读[Service 的外部流量策略](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)
* 请阅读[用 Service 连接应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)
content/zh-cn/docs/concepts/services-networking/service.md
+13 -13
View File
@@ -320,7 +320,7 @@ The name of the Endpoints object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-->
Endpoints 对象的名称必须是合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
<!--
When you create an [Endpoints](docs/reference/kubernetes-api/service-resources/endpoints-v1/)
@@ -401,7 +401,7 @@ EndpointSlices 是一种 API 资源，可以为 Endpoints 提供更可扩展的
届时将创建其他 EndpointSlices 来存储任何其他 Endpoints。
EndpointSlices 提供了附加的属性和功能，这些属性和功能在
[EndpointSlices](/zh/docs/concepts/services-networking/endpoint-slices/)
[EndpointSlices](/zh-cn/docs/concepts/services-networking/endpoint-slices/)
中有详细描述。
<!--
@@ -546,7 +546,7 @@ having traffic sent via kube-proxy to a Pod that's known to have failed.
这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，
并会自动使用其他后端 Pod 重试。
你可以使用 Pod [就绪探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
你可以使用 Pod [就绪探测器](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。
这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod。
@@ -752,7 +752,7 @@ has local endpoints and whether or not all the local endpoints are marked as ter
-->
如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。
<!--
@@ -864,7 +864,7 @@ Services and creates a set of DNS records for each one. If DNS has been enabled
throughout your cluster then all Pods should automatically be able to resolve
Services by their DNS name.
-->
你可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/)
你可以（几乎总是应该）使用[附加组件](/zh-cn/docs/concepts/cluster-administration/addons/)
为 Kubernetes 集群设置 DNS 服务。
支持集群的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。
@@ -905,7 +905,7 @@ Kubernetes 还支持命名端口的 DNS SRV（服务）记录。
Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 Service 的方式。
更多关于 `ExternalName` 信息可以查看
[DNS Pod 和 Service](/zh/docs/concepts/services-networking/dns-pod-service/)。
[DNS Pod 和 Service](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。
<!--
## Headless Services {#headless-services}
@@ -1023,7 +1023,7 @@ Kubernetes `ServiceTypes` 允许指定你所需要的 Service 类型，默认是
<!--
You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.
-->
你也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。
你也可以使用 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 来暴露自己的服务。
Ingress 不是一种服务类型，但它充当集群的入口点。
它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。
@@ -1735,10 +1735,10 @@ groups are modified with the following IP rules:
-->
为了获得均衡流量，请使用 DaemonSet 或指定
[Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
[Pod 反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
使其不在同一节点上。
你还可以将 NLB 服务与[内部负载平衡器](/zh/docs/concepts/services-networking/service/#internal-load-balancer)
你还可以将 NLB 服务与[内部负载平衡器](/zh-cn/docs/concepts/services-networking/service/#internal-load-balancer)
注解一起使用。
为了使客户端流量能够到达 NLB 后面的实例，使用以下 IP 规则修改了节点安全组：
@@ -2089,7 +2089,7 @@ assigned from the lower band.
This allows users to use the lower band of the `service-cluster-ip-range` for their
Services with static IPs assigned with a very low risk of running into conflicts.
-->
如果启用 `ServiceIPStaticSubrange`[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
如果启用 `ServiceIPStaticSubrange`[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
分配策略根据配置的 `service-cluster-ip-range` 的大小，使用以下公式
`min(max(16, cidrSize / 16), 256)` 进行划分，该公式可描述为
“在不小于 16 且不大于 256 之间有一个步进量（Graduated Step）”，将
@@ -2351,7 +2351,7 @@ followed by the data from the client.
* Read about [Ingress](/docs/concepts/services-networking/ingress/)
* Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)
-->
* 阅读[使用服务访问应用](/zh/docs/concepts/services-networking/connect-applications-service/)
* 阅读了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)
* 阅读了解[端点切片（Endpoint Slices）](/zh/docs/concepts/services-networking/endpoint-slices/)
* 阅读[使用服务访问应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)
* 阅读了解 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)
* 阅读了解[端点切片（Endpoint Slices）](/zh-cn/docs/concepts/services-networking/endpoint-slices/)
content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md
+3 -3
View File
@@ -41,7 +41,7 @@ by default. To try out this feature, you have to enable the `TopologyAwareHints`
{{< note >}}
“拓扑感知提示”特性处于 Beta 阶段，并且默认情况下**未**启用。
要试用此特性，你必须启用 `TopologyAwareHints`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
{{< /note >}}
<!-- body -->
@@ -117,7 +117,7 @@ as many endpoints to the zone with 2 CPU cores.
此特性开启后，EndpointSlice 控制器负责在 EndpointSlice 上设置提示信息。
控制器按比例给每个区域分配一定比例数量的端点。
这个比例来源于此区域中运行节点的
[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
[可分配](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
CPU 核心数。
例如，如果一个区域拥有 2 CPU 核心，而另一个区域只有 1 CPU 核心，
那控制器将给那个有 2 CPU 的区域分配两倍数量的端点。
@@ -292,4 +292,4 @@ Kubernetes 控制平面和每个节点上的 kube-proxy，在使用拓扑感知
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-->
* 参阅[通过服务连通应用](/zh/docs/concepts/services-networking/connect-applications-service/)
* 参阅[通过服务连通应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)
content/zh-cn/docs/concepts/services-networking/windows-networking.md
+1 -1
View File
@@ -42,7 +42,7 @@ is responsible for the management of networking resources such as:
-->
## Windows 容器网络 {#networking}
Windows 容器网络通过 [CNI 插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)暴露。
Windows 容器网络通过 [CNI 插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)暴露。
Windows 容器网络的工作方式与虚拟机类似。
每个容器都有一个连接到 Hyper-V 虚拟交换机（vSwitch）的虚拟网络适配器（vNIC）。
主机网络服务（Host Networking Service，HNS）和主机计算服务（Host Comute Service，HCS）