From 482351ef2a268de28f435d96d35dd5dfdb671793 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 4 Dec 2020 14:10:01 +0800 Subject: [PATCH] [zh] Fix links in zh localization (1) --- .../control-plane-node-communication.md | 14 +-- .../docs/concepts/architecture/controller.md | 25 ++-- .../zh/docs/concepts/architecture/nodes.md | 2 - .../configuration/pod-priority-preemption.md | 13 +-- .../zh/docs/concepts/configuration/secret.md | 2 +- .../scheduling-eviction/kube-scheduler.md | 60 ++++++---- .../scheduling-framework.md | 8 +- .../taint-and-toleration.md | 2 +- .../services-networking/service-topology.md | 107 +++++++----------- .../concepts/storage/persistent-volumes.md | 7 +- .../docs/concepts/storage/storage-capacity.md | 26 +++-- content/zh/docs/concepts/storage/volumes.md | 15 ++- content/zh/docs/concepts/workloads/_index.md | 2 +- .../workloads/controllers/daemonset.md | 2 +- .../workloads/controllers/replicaset.md | 2 +- .../workloads/controllers/statefulset.md | 101 +++++++++++------ .../zh/docs/concepts/workloads/pods/_index.md | 2 +- .../concepts/workloads/pods/disruptions.md | 10 +- .../workloads/pods/ephemeral-containers.md | 2 +- .../pods/pod-topology-spread-constraints.md | 7 +- 20 files changed, 229 insertions(+), 180 deletions(-) diff --git a/content/zh/docs/concepts/architecture/control-plane-node-communication.md b/content/zh/docs/concepts/architecture/control-plane-node-communication.md index 182aaf5162..dc31269f47 100644 --- a/content/zh/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/zh/docs/concepts/architecture/control-plane-node-communication.md @@ -32,10 +32,10 @@ One or more forms of [authorization](/docs/reference/access-authn-authz/authoriz Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。 apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求， -并启用一种或多种形式的客户端[身份认证](/docs/reference/access-authn-authz/authentication/)机制。 +并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。 一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用， -特别是在允许使用[匿名请求](/docs/reference/access-authn-authz/authentication/#anonymous-requests) -或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 +特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests) +或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 -这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。 +这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的， +能够在不可信的网络或公网上运行。 - ### SSH 隧道 {#ssh-tunnels} Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，apiserver @@ -158,7 +158,6 @@ After enabling the Konnectivity service, all control plane to nodes traffic goes Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster. --> - ### Konnectivity 服务 {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -168,5 +167,6 @@ Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。 -请浏览 [Konnectivity 服务任务](/docs/tasks/extend-kubernetes/setup-konnectivity/) +请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/) 在你的集群中配置 Konnectivity 服务。 + diff --git a/content/zh/docs/concepts/architecture/controller.md b/content/zh/docs/concepts/architecture/controller.md index 6178bd68f0..fc82c14ee7 100644 --- a/content/zh/docs/concepts/architecture/controller.md +++ b/content/zh/docs/concepts/architecture/controller.md @@ -139,21 +139,23 @@ Controllers that interact with external state find their desired state from the API server, then communicate directly with an external system to bring the current state closer in line. -(There actually is a controller that horizontally scales the -nodes in your cluster. See -[Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). +(There actually is a [controller](https://github.com/kubernetes/autoscaler/) +that horizontally scales the nodes in your cluster.) --> ### 直接控制 {#direct-control} 相比 Job 控制器，有些控制器需要对集群外的一些东西进行修改。 -例如，如果你使用一个控制环来保证集群中有足够的{{< glossary_tooltip text="节点" term_id="node" >}}，那么控制就需要当前集群外的一些服务在需要时创建新节点。 +例如，如果你使用一个控制回路来保证集群中有足够的 +{{< glossary_tooltip text="节点" term_id="node" >}}，那么控制器就需要当前集群外的 +一些服务在需要时创建新节点。 -和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信并使当前状态更接近期望状态。 +和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信 +并使当前状态更接近期望状态。 -（实际上有一个控制器可以水平地扩展集群中的节点。请参阅 -[集群自动扩缩容](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。 +（实际上有一个[控制器](https://github.com/kubernetes/autoscaler/) +可以水平地扩展集群中的节点。请参阅 * 阅读 [Kubernetes 控制平面组件](/zh/docs/concepts/overview/components/#control-plane-components) -* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) 的一些基本知识 +* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) + 的一些基本知识 * 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) -* 如果你想编写自己的控制器，请看 Kubernetes 的[扩展模式](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。 +* 如果你想编写自己的控制器，请看 Kubernetes 的 + [扩展模式](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。 diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md index 3e2ec24243..490599289d 100644 --- a/content/zh/docs/concepts/architecture/nodes.md +++ b/content/zh/docs/concepts/architecture/nodes.md @@ -627,11 +627,9 @@ for more information. * Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). -* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). --> * 了解有关节点[组件](/zh/docs/concepts/overview/components/#node-components) * 阅读[节点的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core) * 阅读架构设计文档中有关[节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)的章节 * 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) -* 了解[集群自动扩缩](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) diff --git a/content/zh/docs/concepts/configuration/pod-priority-preemption.md b/content/zh/docs/concepts/configuration/pod-priority-preemption.md index 8b601a292a..4af00bd2f1 100644 --- a/content/zh/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/zh/docs/concepts/configuration/pod-priority-preemption.md @@ -17,12 +17,12 @@ weight: 70 {{< feature-state for_k8s_version="v1.14" state="stable" >}} -[Pods](/zh/docs/concepts/workloads/pods/pod/) 可以有*优先级（Priority）*。 +[Pods](/zh/docs/concepts/workloads/pods/) 可以有*优先级（Priority）*。 优先级体现的是当前 Pod 与其他 Pod 相比的重要程度。如果 Pod 无法被调度，则 调度器会尝试抢占（逐出）低优先级的 Pod，从而使得悬决的 Pod 可被调度。 @@ -460,7 +460,7 @@ despite their PDBs being violated. --> #### PodDisruptionBudget 是被支持的，但不提供保证 -[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB) +[PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/) (PDB) 的存在使得应用的属主能够限制多副本应用因主动干扰而同时离线的 Pod 的个数。 Kubernetes 在抢占 Pod 时是可以支持 PDB 的，但对 PDB 的约束也仅限于尽力而为。 调度器会尝试寻找不会因为抢占而违反其 PDB 约束的 Pod 作为牺牲品，不过如果 @@ -628,17 +628,12 @@ Pod may be created that fits on the same Node. In this case, the scheduler will schedule the higher priority Pod instead of the preemptor. This is expected behavior: the Pod with the higher priority should take the place -of a Pod with a lower priority. Other controller actions, such as -[cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling), -may eventually provide capacity to schedule the pending Pods. +of a Pod with a lower priority. --> 在抢占者 Pod 等待被牺牲的 Pod 消失期间，可能有更高优先级的 Pod 被创建，且适合 调度到同一节点。如果是这种情况，调度器会调度优先级更高的 Pod 而不是抢占者。 这是期望发生的行为：优先级更高的 Pod 应该取代优先级较低的 Pod。 -其他控制器行为，例如 -[集群自动扩缩](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) -可能会最终为集群添加容量，以调度悬决 Pod。 在 Kubernetes 中，_调度_ 是指将 {{< glossary_tooltip text="Pod" term_id="pod" >}} 放置到合适的 -{{< glossary_tooltip text="Node" term_id="node" >}} 上，然后对应 Node 上的 {{< glossary_tooltip term_id="kubelet" >}} 才能够运行这些 pod。 - - +{{< glossary_tooltip text="Node" term_id="node" >}} 上，然后对应 Node 上的 +{{< glossary_tooltip term_id="kubelet" >}} 才能够运行这些 pod。 -调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。调度器会依据下文的调度原则来做出调度选择。 +调度器通过 kubernetes 的监测（Watch）机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。 +调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。 +调度器会依据下文的调度原则来做出调度选择。 -如果你想要理解 Pod 为什么会被调度到特定的 Node 上，或者你想要尝试实现一个自定义的调度器，这篇文章将帮助你了解调度。 +如果你想要理解 Pod 为什么会被调度到特定的 Node 上，或者你想要尝试实现 +一个自定义的调度器，这篇文章将帮助你了解调度。 -[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) 是 Kubernetes 集群的默认调度器，并且是集群 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。 +[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) +是 Kubernetes 集群的默认调度器，并且是集群 +{{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。 +如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许 +你自己写一个调度组件并替换原有的 kube-scheduler。 -对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的 Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且 Pod 本身也有不同的资源需求。因此，Pod 在被调度到 Node 上之前，根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。 +对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的 +Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且 +Pod 本身也有不同的资源需求。因此，Pod 在被调度到 Node 上之前， +根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。 -在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度节点_。如果没有任何一个 Node 能满足 Pod 的资源请求，那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的 Node。 +在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度节点_。 +如果没有任何一个 Node 能满足 Pod 的资源请求，那么这个 Pod 将一直停留在 +未调度状态直到调度器能够找到合适的 Node。 -调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，然后选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给 kube-apiserver，这个过程叫做 _绑定_。 +调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分， +选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给 +kube-apiserver，这个过程叫做 _绑定_。 -在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。 +在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、 +亲和以及反亲和要求、数据局域性、负载间的干扰等等。 -过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下，这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。 +过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。 +例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。 +在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下， +这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。 -在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。 +在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。 +根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。 -最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。 +最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。 +如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。 -1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ 和打分的 _优先级(Priorities)_ 。 -2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件，包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。你也可以配置 kube-scheduler 运行不同的配置文件。 - +1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ + 和打分的 _优先级(Priorities)_ 。 +2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件， + 包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。 + 你也可以配置 kube-scheduler 运行不同的配置文件。 ## {{% heading "whatsnext" %}} - - - * 阅读关于 [调度器性能调优](/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/) -* 了解关于 [配置多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/) 的方式 +* 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式 * 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/) * 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md index 4e85bb9a38..d757a654be 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -448,12 +448,12 @@ type PreFilterPlugin interface { 你可以在调度器配置中启用或禁用插件。 如果你在使用 Kubernetes v1.18 或更高版本，大部分调度 -[插件](/zh/docs/reference/scheduling/profiles/#scheduling-plugins) +[插件](/zh/docs/reference/scheduling/config/#scheduling-plugins) 都在使用中且默认启用。 如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为 一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。 -了解更多关于[多配置文件](/zh/docs/reference/scheduling/profiles/#multiple-profiles)。 +了解更多关于[多配置文件](/zh/docs/reference/scheduling/config/#multiple-profiles)。 diff --git a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md index c98f159554..c2631fb958 100644 --- a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -516,6 +516,6 @@ arbitrary tolerations to DaemonSets. * Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/) --> * 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为 -* 阅读 [Pod 优先级](/docs/concepts/configuration/pod-priority-preemption/) +* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/) diff --git a/content/zh/docs/concepts/services-networking/service-topology.md b/content/zh/docs/concepts/services-networking/service-topology.md index 95459727a0..ea84fddfab 100644 --- a/content/zh/docs/concepts/services-networking/service-topology.md +++ b/content/zh/docs/concepts/services-networking/service-topology.md @@ -23,10 +23,8 @@ topology of the cluster. For example, a service can specify that traffic be preferentially routed to endpoints that are on the same Node as the client, or in the same availability zone. --> - -`Service` 拓扑可以让一个服务基于集群的 `Node` 拓扑进行流量路由。例如，一个服务可以指定流量是被优先路由到一个和客户端在同一个 `Node` 或者在同一可用区域的端点。 - - +服务拓扑（Service Topology）可以让一个服务基于集群的 Node 拓扑进行流量路由。 +例如，一个服务可以指定流量是被优先路由到一个和客户端在同一个 Node 或者在同一可用区域的端点。 @@ -51,50 +49,20 @@ with it, while intrazonal traffic does not. Other common needs include being abl to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to Nodes connected to the same top-of-rack switch for the lowest latency. --> - ## 介绍 {#introduction} -默认情况下，发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到任意一个服务后端的地址上。从 Kubernetes 1.7 开始，可以将“外部”流量路由到节点上运行的 pod 上，但不支持 `ClusterIP` 服务，更复杂的拓扑 — 比如分区路由 — 也还不支持。通过允许 `Service` 创建者根据源 `Node` 和目的 `Node` 的标签来定义流量路由策略，`Service` 拓扑特性实现了服务流量的路由。 +默认情况下，发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到任意一个服务后端的地址上。 +从 Kubernetes 1.7 开始，可以将“外部”流量路由到节点上运行的 Pod 上，但不支持 `ClusterIP` 服务， +更复杂的拓扑 — 比如分区路由 — 也还不支持。 +通过允许 `Service` 创建者根据源 `Node` 和目的 `Node` 的标签来定义流量路由策略， +服务拓扑特性实现了服务流量的路由。 -通过对源 `Node` 和目的 `Node` 标签的匹配，运营者可以使用任何符合运营者要求的度量值来指定彼此“较近”和“较远”的节点组。例如，对于在公有云上的运营者来说，更偏向于把流量控制在同一区域内，因为区域间的流量是有费用成本的，而区域内的流量没有。其它常用需求还包括把流量路由到由 `DaemonSet` 管理的本地 Pod 上，或者把保持流量在连接同一机架交换机的 `Node` 上，以获得低延时。 - - - -## 前提条件 {#prerequisites} - -为了启用拓扑感知服务路由功能，必须要满足以下一些前提条件： - - * Kubernetes 的版本不低于 1.17 - * Kube-proxy 运行在 iptables 模式或者 IPVS 模式 - * 启用 [端点切片](/zh/docs/concepts/services-networking/endpoint-slices/)功能 - - - -## 启用 `Service` 拓扑 {#enable-service-topology} - -要启用 `Service` 拓扑，就要给 kube-apiserver 和 kube-proxy 启用 `ServiceTopology` 功能： - -``` ---feature-gates="ServiceTopology=true" -``` +通过对源 `Node` 和目的 `Node` 标签的匹配，运营者可以使用任何符合运营者要求的度量值 +来指定彼此“较近”和“较远”的节点组。 +例如，对于在公有云上的运营者来说，更偏向于把流量控制在同一区域内， +因为区域间的流量是有费用成本的，而区域内的流量没有。 +其它常用需求还包括把流量路由到由 `DaemonSet` 管理的本地 Pod 上，或者 +把保持流量在连接同一机架交换机的 `Node` 上，以获得低延时。 -## 使用 `Service` 拓扑 {#using-service-topology} +## 使用服务拓扑 {#using-service-topology} -如果集群启用了 `Service` 拓扑功能后，就可以在 `Service` 配置中指定 `topologyKeys` 字段，从而控制 `Service` 的流量路由。此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。如果这个 `Service` 没有匹配的后端 `Node`，那么第二个标签会被使用做匹配，以此类推，直到没有标签。 +如果集群启用了服务拓扑功能后，就可以在 `Service` 配置中指定 `topologyKeys` 字段， +从而控制 `Service` 的流量路由。 +此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。 +流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。 +如果这个 `Service` 没有匹配的后端 `Node`，那么第二个标签会被使用做匹配， +以此类推，直到没有标签。 -如果没有匹配到，流量会被拒绝，就如同这个 `Service` 根本没有后端。这是根据有可用后端的第一个拓扑键来选择端点的。如果这个字段被配置了而没有后端可以匹配客户端拓扑，那么这个 `Service` 对那个客户端是没有后端的，链接应该是失败的。这个字段配置为 `"*"` 意味着任意拓扑。这个通配符值如果使用了，那么只有作为配置值列表中的最后一个才有用。 +如果没有匹配到，流量会被拒绝，就如同这个 `Service` 根本没有后端。 +换言之，系统根据可用后端的第一个拓扑键来选择端点。 +如果这个字段被配置了而没有后端可以匹配客户端拓扑，那么这个 `Service` +对那个客户端是没有后端的，链接应该是失败的。 +这个字段配置为 `"*"` 意味着任意拓扑。 +这个通配符值如果使用了，那么只有作为配置值列表中的最后一个才有用。 +如果 `topologyKeys` 没有指定或者为空，就没有启用这个拓扑约束。 -如果 `topologyKeys` 没有指定或者为空，就没有启用这个拓扑功能。 +一个集群中，其 `Node` 的标签被打为其主机名，区域名和地区名。 +那么就可以设置 `Service` 的 `topologyKeys` 的值，像下面的做法一样定向流量了。 -一个集群中，其 `Node` 的标签被打为其主机名，区域名和地区名。那么就可以设置 `Service` 的 `topologyKeys` 的值，像下面的做法一样定向流量了。 - -* 只定向到同一个 `Node` 上的端点，`Node` 上没有端点存在时就失败：配置 `["kubernetes.io/hostname"]`。 -* 偏向定向到同一个 `Node` 上的端点，回退同一区域的端点上，然后是同一地区，其它情况下就失败：配置 `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。这或许很有用，例如，数据局部性很重要的情况下。 -* 偏向于同一区域，但如果此区域中没有可用的终结点，则回退到任何可用的终结点：配置 `["topology.kubernetes.io/zone", "*"]`。 +* 只定向到同一个 `Node` 上的端点，`Node` 上没有端点存在时就失败： + 配置 `["kubernetes.io/hostname"]`。 +* 偏向定向到同一个 `Node` 上的端点，回退同一区域的端点上，然后是同一地区， + 其它情况下就失败：配置 `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。 + 这或许很有用，例如，数据局部性很重要的情况下。 +* 偏向于同一区域，但如果此区域中没有可用的终结点，则回退到任何可用的终结点： + 配置 `["topology.kubernetes.io/zone", "*"]`。 - -* 阅读关于[启用服务拓扑](/docs/tasks/administer-cluster/enabling-service-topology) -* 阅读[用 `Services` 连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/) - +* 阅读关于[启用服务拓扑](/zh/docs/tasks/administer-cluster/enabling-service-topology/) +* 阅读[用服务连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh/docs/concepts/storage/persistent-volumes.md b/content/zh/docs/concepts/storage/persistent-volumes.md index 48fbce7566..7c58f225d5 100644 --- a/content/zh/docs/concepts/storage/persistent-volumes.md +++ b/content/zh/docs/concepts/storage/persistent-volumes.md @@ -3,7 +3,10 @@ title: 持久卷 feature: title: 存储编排 description: > - 自动挂载所选存储系统，包括本地存储、诸如 GCP 或 AWS 之类公有云提供商所提供的存储或者诸如 NFS、iSCSI、Gluster、Ceph、Cinder 或 Flocker 这类网络存储系统。 + 自动挂载所选存储系统，包括本地存储、诸如 GCP + 或 AWS + 之类公有云提供商所提供的存储或者诸如 NFS、iSCSI、Gluster、Ceph、Cinder + 或 Flocker 这类网络存储系统。 content_type: concept weight: 20 @@ -1053,7 +1056,7 @@ be bound to the PVC. ### 类 {#class} 申领可以通过为 `storageClassName` 属性设置 -[StorageClass](/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。 +[StorageClass](/zh/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。 只有所请求的类的 PV 卷，即 `storageClassName` 值与 PVC 设置相同的 PV 卷， 才能绑定到 PVC 申领。 diff --git a/content/zh/docs/concepts/storage/storage-capacity.md b/content/zh/docs/concepts/storage/storage-capacity.md index 24c86537b8..c5911f0154 100644 --- a/content/zh/docs/concepts/storage/storage-capacity.md +++ b/content/zh/docs/concepts/storage/storage-capacity.md @@ -23,11 +23,13 @@ Tracking storage capacity is supported for {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) drivers and [needs to be enabled](#enabling-storage-capacity-tracking) when installing a CSI driver. --> -存储容量是有限的，并且会因为运行 pod 的节点不同而变化：网络存储可能并非所有节点都能够访问，或者对于某个节点存储是本地的。 +存储容量是有限的，并且会因为运行 Pod 的节点不同而变化： +网络存储可能并非所有节点都能够访问，或者对于某个节点存储是本地的。 {{< feature-state for_k8s_version="v1.19" state="alpha" >}} -本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将 Pod 调度到能够访问到足够存储容量的节点上。 +本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将 +Pod 调度到能够访问到足够存储容量的节点上。 如果没有跟踪存储容量，调度程序可能会选择一个没有足够容量来提供卷的节点，并且需要多次调度重试。 {{< glossary_tooltip text="容器存储接口" term_id="csi" >}}（CSI）驱动程序支持跟踪存储容量， @@ -51,9 +53,10 @@ There are two API extensions for this feature: 这个特性有两个 API 扩展接口： - [CSIStorageCapacity](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csistoragecapacity-v1alpha1-storage-k8s-io) -对象：这些对象由 CSI 驱动程序在安装驱动程序的命名空间中产生。每个对象都包含一个存储类的容量信息，并定义哪些节点可以访问该存储。 + 对象：这些对象由 CSI 驱动程序在安装驱动程序的命名空间中产生。 + 每个对象都包含一个存储类的容量信息，并定义哪些节点可以访问该存储。 - [`CSIDriverSpec.StorageCapacity` 字段](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io)： -设置为 true 时，Kubernetes 调度程序将考虑使用 CSI 驱动程序的卷的存储容量。 + 设置为 true 时，Kubernetes 调度程序将考虑使用 CSI 驱动程序的卷的存储容量。 ## 开启存储容量跟踪 -存储容量跟踪是一个 *alpha 特性*，只有当 `CSIStorageCapacity` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/) +存储容量跟踪是一个 *alpha 特性*，只有当 `CSIStorageCapacity` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 和 `storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API 组" term_id="api-group" >}}启用时才能启用。 -更多详细信息，可以查看`--feature-gates` 和 `--runtime-config` [kube-apiserver 参数](/docs/reference/command-line-tools-reference/kube-apiserver/)。 +更多详细信息，可以查看`--feature-gates` 和 `--runtime-config` +[kube-apiserver 参数](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)。 如果不支持，下面这个错误就会被打印出来： + ``` error: the server doesn't have a resource type "csistoragecapacities" ``` @@ -218,6 +224,8 @@ error: the server doesn't have a resource type "csistoragecapacities" - For more information on further development of this feature, see the [enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472). - Learn about [Kubernetes Scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) --> -- 想要获得更多该设计的信息，查看 [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)。 -- 有关此功能的进一步开发信息，查看[enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472)。 -- 学习 [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)。 \ No newline at end of file +- 想要获得更多该设计的信息，查看 + [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)。 +- 有关此功能的进一步开发信息，查看 + [enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472)。 +- 学习 [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)。 diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md index cd16a93a54..71139871bc 100644 --- a/content/zh/docs/concepts/storage/volumes.md +++ b/content/zh/docs/concepts/storage/volumes.md @@ -1190,7 +1190,7 @@ iSCSI volume) without knowing the details of the particular cloud environment. See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/) for more details. --> -更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/)。 +更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/)。 ### portworxVolume {#portworxvolume} @@ -1371,7 +1371,9 @@ for the current [service account](/docs/reference/access-authn-authz/authenticat into a Pod at a specified path. Below is an example: --> -当开启 `TokenRequestProjection` 功能时，可以将当前 [服务帐户](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的令牌注入 Pod 中的指定路径。 +当开启 `TokenRequestProjection` 功能时，可以将当前 +[服务帐号](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens) +的令牌注入 Pod 中的指定路径。 下面是一个例子： ```yaml @@ -1455,7 +1457,8 @@ GitHub project has [instructions](https://github.com/quobyte/quobyte-csi#quobyte --> Quobyte 支持{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}。 推荐使用 CSI 插件以在 Kubernetes 中使用 Quobyte 卷。 -Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi) +Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的 +[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi) 及使用示例。 ### rbd @@ -1748,7 +1751,8 @@ spec: -进一步信息可参考[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。 +进一步信息可参考 +[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。 当 `vsphereVolume` 的 `CSIMigration` 特性被启用时，所有插件操作都被从树内插件重定向到 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。 -为了使用此功能特性，必须在集群中安装[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)， +为了使用此功能特性，必须在集群中安装 +[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)， 并启用 `CSIMigration` 和 `CSIMigrationvSphere` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 diff --git a/content/zh/docs/concepts/workloads/_index.md b/content/zh/docs/concepts/workloads/_index.md index 911e8e0343..a6594a7018 100644 --- a/content/zh/docs/concepts/workloads/_index.md +++ b/content/zh/docs/concepts/workloads/_index.md @@ -114,5 +114,5 @@ mechanisms for separating code from configuration. 一旦你的应用处于运行状态，你就可能想要 以[服务](/zh/docs/concepts/services-networking/service/) 使之在互联网上可访问；或者对于 Web 应用而言，使用 -[Ingress](/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 +[Ingress](/zh/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md index ece35c15cf..5ad4bf617a 100644 --- a/content/zh/docs/concepts/workloads/controllers/daemonset.md +++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md @@ -236,7 +236,7 @@ DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。 * Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态， DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。 -* [Pod 抢占](/docs/concepts/configuration/pod-priority-preemption/) +* [Pod 抢占](/zh/docs/concepts/configuration/pod-priority-preemption/) 由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占 的情况下制定调度决策。 diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md index 4446ad496b..96ad968542 100644 --- a/content/zh/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md @@ -405,7 +405,7 @@ be rejected by the API. ### Pod 选择算符 {#pod-selector} `.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。 -如前文中[所讨论的](how-a-replicaset-works)，这些是用来标识要被获取的 Pods +如前文中[所讨论的](#how-a-replicaset-works)，这些是用来标识要被获取的 Pods 的标签。在签名的 `frontend.yaml` 示例中，选择算符为： ```yaml diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh/docs/concepts/workloads/controllers/statefulset.md index 100343be99..cdc0383316 100644 --- a/content/zh/docs/concepts/workloads/controllers/statefulset.md +++ b/content/zh/docs/concepts/workloads/controllers/statefulset.md @@ -50,7 +50,12 @@ that provides a set of stateless replicas. [Deployment](/docs/concepts/workloads/controllers/deployment/) or [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs. --> -在上面，稳定意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 可能更适用于您的无状态应用部署需要。 +在上面描述中，“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。 +如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用 +由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 +[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者 +[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) +可能更适用于你的无状态应用部署需要。 -* 给定 Pod 的存储必须由 [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) 基于所请求的 `storage class` 来提供，或者由管理员预先提供。 -* 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。 -* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services) 来负责 Pod 的网络标识。您需要负责创建此服务。 -* 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序和优雅的终止，可以在删除之前将 StatefulSet 缩放为 0。 -* 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates)，可能进入需要 [人工干预](#forced-rollback) 才能修复的损坏状态。 +* 给定 Pod 的存储必须由 + [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) + 基于所请求的 `storage class` 来提供，或者由管理员预先提供。 +* 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。 + 这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。 +* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services) + 来负责 Pod 的网络标识。你需要负责创建此服务。 +* 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。 + 为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet + 缩放为 0。 +* 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 + [滚动更新](#rolling-updates)，可能进入需要[人工干预](#forced-rollback) + 才能修复的损坏状态。 -您必须设置 StatefulSet 的 `.spec.selector` 字段，使之匹配其在 `.spec.template.metadata.labels` 中设置的标签。在 Kubernetes 1.8 版本之前，被忽略 `.spec.selector` 字段会获得默认设置值。在 1.8 和以后的版本中，未指定匹配的 Pod 选择器将在创建 StatefulSet 期间导致验证错误。 +你必须设置 StatefulSet 的 `.spec.selector` 字段，使之匹配其在 +`.spec.template.metadata.labels` 中设置的标签。在 Kubernetes 1.8 版本之前， +被忽略 `.spec.selector` 字段会获得默认设置值。 +在 1.8 和以后的版本中，未指定匹配的 Pod 选择器将在创建 StatefulSet 期间导致验证错误。 ## Pod 标识 {#pod-identity} -StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的，不管它被调度在哪个节点上。 +StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。 +该标识和 Pod 是绑定的，不管它被调度在哪个节点上。 ### 有序索引 {#ordinal-index} -对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号，从 0 到 N-1，该序号在 StatefulSet 上是唯一的。 +对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号， +从 0 到 N-1，该序号在 StatefulSet 上是唯一的。 ### 稳定的存储 {#stable-storage} -Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。 +Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)。 在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的 1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。 当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 @@ -250,7 +269,9 @@ the StatefulSet. --> ### Pod 名称标签 {#pod-name-label} -当 StatefulSet {{< glossary_tooltip term_id="controller" >}} 创建 Pod 时，它会添加一个标签 `statefulset.kubernetes.io/pod-name`，该标签设置为 Pod 名称。这个标签允许您给 StatefulSet 中的特定 Pod 绑定一个 Service。 +当 StatefulSet {{< glossary_tooltip term_id="controller" >}} 创建 Pod 时， +它会添加一个标签 `statefulset.kubernetes.io/pod-name`，该标签值设置为 Pod 名称。 +这个标签允许你给 StatefulSet 中的特定 Pod 绑定一个 Service。 - -如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`，首先被终止的是 web-2。在 web-2 没有被完全停止和删除前，web-1 不会被终止。当 web-2 已被终止和删除、web-1 尚未被终止，如果在此期间发生 web-0 运行失败，那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。 +如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`，首先被终止的是 web-2。 +在 web-2 没有被完全停止和删除前，web-1 不会被终止。 +当 web-2 已被终止和删除、web-1 尚未被终止，如果在此期间发生 web-0 运行失败， +那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。 ### Pod 管理策略 {#pod-management-policies} -在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您不要求其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。 -在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您放宽其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。 +在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许你放宽其排序保证， +同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。 #### OrderedReady Pod 管理 -`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了[上面](#deployment-and-scaling-guarantees)描述的功能。 +`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了 +[上面](#deployment-and-scaling-guarantees)描述的功能。 ## 更新策略 {#update-strategies} -在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让您可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。 +在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让 +你可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。 ### 关于删除策略 {#on-delete} -`OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的 `.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 `.spec.template` 的变动作出反应。 - +`OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的 +`.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新 +StatefulSet 中的 Pod。 +用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 +`.spec.template` 的变动作出反应。 ### 滚动更新 {#rolling-updates} -`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。在没有声明 `.spec.updateStrategy` 时，`RollingUpdate` 是默认配置。 -当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时，StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。 -它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。 +`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。 +在没有声明 `.spec.updateStrategy` 时，`RollingUpdate` 是默认配置。 +当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时， +StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。 +它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。 +它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。 #### 分区 {#partitions} -通过声明 `.spec.updateStrategy.rollingUpdate.partition` 的方式，`RollingUpdate` 更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的 `.spec.template` 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 `.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。 -在大多数情况下，您不需要使用分区，但如果您希望进行阶段更新、执行金丝雀或执行分阶段展开，则这些分区会非常有用。 +通过声明 `.spec.updateStrategy.rollingUpdate.partition` 的方式，`RollingUpdate` +更新策略可以实现分区。 +如果声明了一个分区，当 StatefulSet 的 `.spec.template` 被更新时， +所有序号大于等于该分区序号的 Pod 都会被更新。 +所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。 +如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 +`.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。 +在大多数情况下，你不需要使用分区，但如果你希望进行阶段更新、执行金丝雀或执行 +分阶段上线，则这些分区会非常有用。 #### 强制回滚 {#forced-rollback} -在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。 +在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 下使用 +[滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。 -如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件或应用程序级配置错误），StatefulSet 将停止回滚并等待。 +如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件 +或应用程序级配置错误），StatefulSet 将停止回滚并等待。 - * 示例一：[部署有状态应用](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。 * 示例二：[使用 StatefulSet 部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)。 * 示例三：[运行多副本的有状态应用程序](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。 - - diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh/docs/concepts/workloads/pods/_index.md index dba92eebcf..1d5d40393b 100644 --- a/content/zh/docs/concepts/workloads/pods/_index.md +++ b/content/zh/docs/concepts/workloads/pods/_index.md @@ -431,7 +431,7 @@ Processes within a privileged container get almost the same privileges that are ## 容器的特权模式 {#rivileged-mode-for-containers} Pod 中的任何容器都可以使用容器规约中的 -[安全性上下文](/docs/tasks/configure-pod-container/security-context/)中的 +[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的 `privileged` 参数启用特权模式。 这对于想要使用使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备） 的容器很有用。 diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md index 3c70c6ca68..1eb8fdad1e 100644 --- a/content/zh/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh/docs/concepts/workloads/pods/disruptions.md @@ -16,7 +16,7 @@ This guide is for application owners who want to build highly available applications, and thus need to understand what types of Disruptions can happen to Pods. --> -本指南针对的是希望构建高可用性应用程序的应用所有者，他们有必要了解可能发生在 pod 上的干扰类型。 +本指南针对的是希望构建高可用性应用程序的应用所有者，他们有必要了解可能发生在 Pod 上的干扰类型。 集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口 -（通过调用[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)）， +（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)）， 而不是直接删除 Pod 或 Deployment。 * 参考[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。 -* 进一步了解[排空节点](/docs/tasks/administer-cluster/safely-drain-node/)的信息。 +* 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。 * 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) 的过程，包括如何在其进程中维持应用的可用性 diff --git a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md b/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md index 0667aa206a..430a1d3c55 100644 --- a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md @@ -34,7 +34,7 @@ feature could change significantly in the future or be removed entirely. {{< warning >}} 临时容器处于早期的 alpha 阶段，不适用于生产环境集群。 应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。 -根据 [Kubernetes 弃用政策](/docs/reference/using-api/deprecation-policy/)， +根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)， 此 alpha 功能将来可能发生重大变化或被完全删除。 {{< /warning >}} diff --git a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index efa2621f06..1a71ad62a3 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -11,8 +11,9 @@ weight: 40 --> {{< feature-state for_k8s_version="v1.19" state="stable" >}} - + @@ -36,7 +37,7 @@ topology spread constraints. {{< note >}} 在 v1.19 之前的 Kubernetes 版本中，如果要使用 Pod 拓扑扩展约束，你必须在 [API 服务器](/zh/docs/concepts/overview/components/#kube-apiserver) -和[调度器](/zh/docs/reference/command-line-tools-referene/kube-scheduler/) +和[调度器](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) 中启用 `EvenPodsSpread` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 {{< /note >}}