From 5f0ec40aaad2cb909ff48b1738465d28550ddd6a Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:18:40 +0800 Subject: [PATCH] [zh]Update concepts pages(part-3) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- .../concepts/scheduling-eviction/_index.md | 20 ++++---- .../scheduling-eviction/api-eviction.md | 14 +++--- .../scheduling-eviction/assign-pod-node.md | 42 ++++++++--------- .../scheduling-eviction/kube-scheduler.md | 20 ++++---- .../node-pressure-eviction.md | 14 +++--- .../scheduling-eviction/pod-overhead.md | 10 ++-- .../pod-priority-preemption.md | 22 ++++----- .../scheduler-perf-tuning.md | 8 ++-- .../scheduling-framework.md | 4 +- .../taint-and-toleration.md | 20 ++++---- .../concepts/security/controlling-access.md | 42 ++++++++--------- .../zh-cn/docs/concepts/security/overview.md | 34 +++++++------- .../security/pod-security-admission.md | 32 ++++++------- .../concepts/security/pod-security-policy.md | 40 ++++++++-------- .../security/pod-security-standards.md | 14 +++--- .../concepts/security/rbac-good-practices.md | 22 ++++----- .../concepts/security/windows-security.md | 4 +- .../concepts/services-networking/_index.md | 2 +- .../connect-applications-service.md | 14 +++--- .../services-networking/dns-pod-service.md | 10 ++-- .../services-networking/endpoint-slices.md | 4 +- .../ingress-controllers.md | 12 ++--- .../concepts/services-networking/ingress.md | 46 +++++++++---------- .../services-networking/network-policies.md | 18 ++++---- .../services-networking/service-topology.md | 8 ++-- .../service-traffic-policy.md | 10 ++-- .../concepts/services-networking/service.md | 26 +++++------ .../topology-aware-hints.md | 6 +-- .../services-networking/windows-networking.md | 2 +- 29 files changed, 260 insertions(+), 260 deletions(-) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/_index.md b/content/zh-cn/docs/concepts/scheduling-eviction/_index.md index de33763b46..3919a6cfa0 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/_index.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/_index.md @@ -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 干扰 -* [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/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md b/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md index f51af2f678..4b9615951b 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md @@ -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) ## 调用 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/)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md index 3dcd46b8c4..c6d249d465 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -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 >}} -[`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)。 `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/)， 以了解进一步的信息。 -在配置多个[调度方案](/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 >}} -参阅 [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/)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md index 30791e6249..067dd959fa 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -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/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md index 810324c0c2..8a0910315e 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md @@ -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)。 {{}} 你可以使用 `--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/{{}}/#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/{{}}/#create-eviction-pod-v1-core) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md b/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md index 17951dd91e..046a27cd99 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md @@ -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)时设置的。 -在准入阶段 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` 字段都将计算在内。 -* 学习更多关于 [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)增强建议以获取更多上下文 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md index f22065f8f9..afa224896a 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -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 >}} #### 支持 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/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index dd6e1da395..6ceffe8461 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -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 上。 -要修改这个值，先编辑 [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)。 -* 参见 [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/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md index 9e0fee45ac..80cefde2e1 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -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) 都在使用中且默认启用。 如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为 一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。 -了解更多关于[多配置文件](/zh/docs/reference/scheduling/config/#multiple-profiles)。 +了解更多关于[多配置文件](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md index 1e02d72fdd..39ad284a00 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -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. --> 控制平面使用节点{{}}自动创建 -与[节点状况](/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/) diff --git a/content/zh-cn/docs/concepts/security/controlling-access.md b/content/zh-cn/docs/concepts/security/controlling-access.md index 5946a002b6..5de2cb3e59 100644 --- a/content/zh-cn/docs/concepts/security/controlling-access.md +++ b/content/zh-cn/docs/concepts/security/controlling-access.md @@ -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/)节中有更详细的描述。 ## 准入控制 {#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 服务器端口和 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 凭证. diff --git a/content/zh-cn/docs/concepts/security/overview.md b/content/zh-cn/docs/concepts/security/overview.md index 9a9e9845a7..165c339de1 100644 --- a/content/zh-cn/docs/concepts/security/overview.md +++ b/content/zh-cn/docs/concepts/security/overview.md @@ -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/)的建议。 学习了解相关的 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) diff --git a/content/zh-cn/docs/concepts/security/pod-security-admission.md b/content/zh-cn/docs/concepts/security/pod-security-admission.md index b5097a995e..6e04de352d 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-admission.md +++ b/content/zh-cn/docs/concepts/security/pod-security-admission.md @@ -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 行为。 作为一项 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 >}} @@ -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 安全标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。 +[使用名字空间标签来强制实施 Pod 安全标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。 -- [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/) diff --git a/content/zh-cn/docs/concepts/security/pod-security-policy.md b/content/zh-cn/docs/concepts/security/pod-security-policy.md index 6bb83482f6..d68df8050c 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-policy.md +++ b/content/zh-cn/docs/concepts/security/pod-security-policy.md @@ -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**。 大多数 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)。 更多的示例可参考 -[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。 +[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/#policy-instantiation)。 -参阅 [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 细节。 diff --git a/content/zh-cn/docs/concepts/security/pod-security-standards.md b/content/zh-cn/docs/concepts/security/pod-security-standards.md index 4bd324ceb0..1aafe77bf2 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-standards.md +++ b/content/zh-cn/docs/concepts/security/pod-security-standards.md @@ -117,7 +117,7 @@ fail validation. -->

Windows Pod 提供了运行 - HostProcess 容器 的能力， + HostProcess 容器 的能力， 这使得对 Windows 节点的特权访问成为可能。 基线策略中对宿主的特权访问是被禁止的。 HostProcess Pod 是 Kubernetes v1.22 版本的 @@ -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/)。 @@ -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 安全标准的情况。 ### 工作负载的创建 {#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/)做限制。 -可以为 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)。 -Windows 容器还可以通过使用[组管理的服务账号](/zh/docs/tasks/configure-pod-container/configure-gmsa/)作为 +Windows 容器还可以通过使用[组管理的服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/)作为 Active Directory 身份运行。 -* 进一步了解如何[使用 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/) diff --git a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md index 2bee2ba425..9946a88eb3 100644 --- a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md @@ -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/) diff --git a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md index 05f808a1a9..b3f0949298 100644 --- a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md @@ -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`. -* 阅读[使用 Service 连接到应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 阅读[使用 Service 连接到应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md b/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md index 06a4c948bd..1e2d6ae078 100644 --- a/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md @@ -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)做法的替代。 如果你不为 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)。 diff --git a/content/zh-cn/docs/concepts/services-networking/ingress.md b/content/zh-cn/docs/concepts/services-networking/ingress.md index e14cd79ef8..6b5bf60c38 100644 --- a/content/zh-cn/docs/concepts/services-networking/ingress.md +++ b/content/zh-cn/docs/concepts/services-networking/ingress.md @@ -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，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。 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。 ## 环境准备 -你必须拥有一个 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 +你必须拥有一个 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 仅创建 Ingress 资源本身没有任何效果。 你可能需要部署 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) 中进行选择。 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 控制器的文档，以了解其支持哪些注解。 {{< 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 >}} 值得注意的是，尽管健康检查不是通过 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)的文档以了解详细信息。 -* 使用 [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/) diff --git a/content/zh-cn/docs/concepts/services-networking/network-policies.md b/content/zh-cn/docs/concepts/services-networking/network-policies.md index ef2884c281..f86efea978 100644 --- a/content/zh-cn/docs/concepts/services-networking/network-policies.md +++ b/content/zh-cn/docs/concepts/services-networking/network-policies.md @@ -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/)演练 了解更多示例。 你的集群所使用的 {{< 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)。 diff --git a/content/zh-cn/docs/concepts/services-networking/service-topology.md b/content/zh-cn/docs/concepts/services-networking/service-topology.md index 4ab71cee41..e899786565 100644 --- a/content/zh-cn/docs/concepts/services-networking/service-topology.md +++ b/content/zh-cn/docs/concepts/services-networking/service-topology.md @@ -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/), 提供类似的功能。 {{}} @@ -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/) diff --git a/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md b/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md index dad9dcc79b..b291c17758 100644 --- a/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md @@ -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/) diff --git a/content/zh-cn/docs/concepts/services-networking/service.md b/content/zh-cn/docs/concepts/services-networking/service.md index 71140bf426..05aec469ff 100644 --- a/content/zh-cn/docs/concepts/services-networking/service.md +++ b/content/zh-cn/docs/concepts/services-networking/service.md @@ -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)。 如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。 -你可以（几乎总是应该）使用[附加组件](/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/)。 -你也可以使用 [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/) diff --git a/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md b/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md index f0b28aca2a..a867c2a537 100644 --- a/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md @@ -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 >}} @@ -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/) diff --git a/content/zh-cn/docs/concepts/services-networking/windows-networking.md b/content/zh-cn/docs/concepts/services-networking/windows-networking.md index b6a7662461..ea2df2e815 100644 --- a/content/zh-cn/docs/concepts/services-networking/windows-networking.md +++ b/content/zh-cn/docs/concepts/services-networking/windows-networking.md @@ -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）