Merge pull request #25397 from tengqm/zh-fix-links-1
[zh] Fix links in zh localization (1)pull/25410/head
Kubernetes Prow Robot
GitHub
commit
c5c6d10305
|
|
@ -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)的时候。
|
||||
|
||||
<!--
|
||||
Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
|
||||
|
|
@ -61,7 +61,8 @@ The control plane components also communicate with the cluster apiserver over th
|
|||
<!--
|
||||
As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
|
||||
-->
|
||||
这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。
|
||||
这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，
|
||||
能够在不可信的网络或公网上运行。
|
||||
|
||||
<!--
|
||||
## Control Plane to node
|
||||
|
|
@ -137,7 +138,6 @@ This tunnel ensures that the traffic is not exposed outside of the network in wh
|
|||
|
||||
SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel.
|
||||
-->
|
||||
|
||||
### 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 服务。
|
||||
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
可以水平地扩展集群中的节点。请参阅
|
||||
|
||||
<!--
|
||||
The important point here is that the controller makes some change to bring about
|
||||
|
|
@ -193,7 +195,8 @@ useful changes, it doesn't matter if the overall state is or is not stable.
|
|||
|
||||
Kubernetes 采用了系统的云原生视图，并且可以处理持续的变化。
|
||||
|
||||
在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。这意味着很可能集群永远不会达到稳定状态。
|
||||
在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。
|
||||
这意味着很可能集群永远不会达到稳定状态。
|
||||
|
||||
只要集群中控制器的在运行并且进行有效的修改，整体状态的稳定与否是无关紧要的。
|
||||
|
||||
|
|
@ -278,7 +281,9 @@ Kubernetes 允许你运行一个稳定的控制平面，这样即使某些内置
|
|||
* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.
|
||||
-->
|
||||
* 阅读 [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)。
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -17,12 +17,12 @@ weight: 70
|
|||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
<!--
|
||||
[Pods](/docs/concepts/workloads/pods/pod/) can have _priority_. Priority indicates the
|
||||
[Pods](/docs/concepts/workloads/pods/) can have _priority_. Priority indicates the
|
||||
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.
|
||||
-->
|
||||
[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。
|
||||
|
||||
<!--
|
||||
### Higher priority Pods are preempted before lower priority pods
|
||||
|
|
|
|||
|
|
@ -666,7 +666,7 @@ There are several options to create a Secret:
|
|||
|
||||
- [使用 `kubectl` 命令创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [使用配置文件来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [使用 kustomize 来创建 Secret](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- [使用 kustomize 来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
<!--
|
||||
## Editing a Secret
|
||||
|
|
|
|||
|
|
@ -17,9 +17,8 @@ are matched to {{< glossary_tooltip text="Nodes" term_id="node" >}} so that
|
|||
{{< glossary_tooltip term_id="kubelet" >}} can run them.
|
||||
-->
|
||||
在 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。
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
|
|
@ -34,14 +33,17 @@ for finding the best Node for that Pod to run on. The scheduler reaches
|
|||
this placement decision taking into account the scheduling principles
|
||||
described below.
|
||||
-->
|
||||
调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。调度器会依据下文的调度原则来做出调度选择。
|
||||
调度器通过 kubernetes 的监测（Watch）机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。
|
||||
调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。
|
||||
调度器会依据下文的调度原则来做出调度选择。
|
||||
|
||||
<!--
|
||||
If you want to understand why Pods are placed onto a particular Node,
|
||||
or if you're planning to implement a custom scheduler yourself, this
|
||||
page will help you learn about scheduling.
|
||||
-->
|
||||
如果你想要理解 Pod 为什么会被调度到特定的 Node 上，或者你想要尝试实现一个自定义的调度器，这篇文章将帮助你了解调度。
|
||||
如果你想要理解 Pod 为什么会被调度到特定的 Node 上，或者你想要尝试实现
|
||||
一个自定义的调度器，这篇文章将帮助你了解调度。
|
||||
|
||||
<!--
|
||||
## kube-scheduler
|
||||
|
|
@ -55,7 +57,11 @@ 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/) 是 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。
|
||||
|
||||
<!--
|
||||
For every newly created pods or other unscheduled pods, kube-scheduler
|
||||
|
|
@ -64,14 +70,19 @@ pods has different requirements for resources and every pod also has
|
|||
different requirements. Therefore, existing nodes need to be filtered
|
||||
according to the specific scheduling requirements.
|
||||
-->
|
||||
对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的 Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且 Pod 本身也有不同的资源需求。因此，Pod 在被调度到 Node 上之前，根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。
|
||||
对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的
|
||||
Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且
|
||||
Pod 本身也有不同的资源需求。因此，Pod 在被调度到 Node 上之前，
|
||||
根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。
|
||||
|
||||
<!--
|
||||
In a cluster, Nodes that meet the scheduling requirements for a Pod
|
||||
are called _feasible_ nodes. If none of the nodes are suitable, the pod
|
||||
remains unscheduled until the scheduler is able to place it.
|
||||
-->
|
||||
在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度节点_。如果没有任何一个 Node 能满足 Pod 的资源请求，那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的 Node。
|
||||
在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度节点_。
|
||||
如果没有任何一个 Node 能满足 Pod 的资源请求，那么这个 Pod 将一直停留在
|
||||
未调度状态直到调度器能够找到合适的 Node。
|
||||
|
||||
<!--
|
||||
The scheduler finds feasible Nodes for a Pod and then runs a set of
|
||||
|
|
@ -79,7 +90,9 @@ functions to score the feasible Nodes and picks a Node with the highest
|
|||
score among the feasible ones to run the Pod. The scheduler then notifies
|
||||
the API server about this decision in a process called _binding_.
|
||||
-->
|
||||
调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，然后选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给 kube-apiserver，这个过程叫做 _绑定_。
|
||||
调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，
|
||||
选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给
|
||||
kube-apiserver，这个过程叫做 _绑定_。
|
||||
|
||||
<!--
|
||||
Factors that need taken into account for scheduling decisions include
|
||||
|
|
@ -87,7 +100,8 @@ individual and collective resource requirements, hardware / software /
|
|||
policy constraints, affinity and anti-affinity specifications, data
|
||||
locality, inter-workload interference, and so on.
|
||||
-->
|
||||
在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。
|
||||
在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、
|
||||
亲和以及反亲和要求、数据局域性、负载间的干扰等等。
|
||||
|
||||
<!--
|
||||
## Scheduling with kube-scheduler {#kube-scheduler-implementation}
|
||||
|
|
@ -113,21 +127,26 @@ resource requests. After this step, the node list contains any suitable
|
|||
Nodes; often, there will be more than one. If the list is empty, that
|
||||
Pod isn't (yet) schedulable.
|
||||
-->
|
||||
过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下，这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。
|
||||
过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。
|
||||
例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。
|
||||
在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下，
|
||||
这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。
|
||||
|
||||
<!--
|
||||
In the _scoring_ step, the scheduler ranks the remaining nodes to choose
|
||||
the most suitable Pod placement. The scheduler assigns a score to each Node
|
||||
that survived filtering, basing this score on the active scoring rules.
|
||||
-->
|
||||
在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。
|
||||
在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。
|
||||
根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。
|
||||
|
||||
<!--
|
||||
Finally, kube-scheduler assigns the Pod to the Node with the highest ranking.
|
||||
If there is more than one node with equal scores, kube-scheduler selects
|
||||
one of these at random.
|
||||
-->
|
||||
最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。
|
||||
最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。
|
||||
如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。
|
||||
|
||||
<!--
|
||||
There are two supported ways to configure the filtering and scoring behavior
|
||||
|
|
@ -143,26 +162,25 @@ 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)_ 和打分的 _优先级(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" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
|
||||
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
|
||||
* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
|
||||
* Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
|
||||
* 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/)
|
||||
* 了解关于 [配置多个调度器](/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/)
|
||||
|
||||
|
|
|
|||
|
|
@ -448,12 +448,12 @@ type PreFilterPlugin interface {
|
|||
<!--
|
||||
You can enable or disable plugins in the scheduler configuration. If you are using
|
||||
Kubernetes v1.18 or later, most scheduling
|
||||
[plugins](/docs/reference/scheduling/profiles/#scheduling-plugins) are in use and
|
||||
[plugins](/docs/reference/scheduling/config/#scheduling-plugins) are in use and
|
||||
enabled by default.
|
||||
-->
|
||||
你可以在调度器配置中启用或禁用插件。
|
||||
如果你在使用 Kubernetes v1.18 或更高版本，大部分调度
|
||||
[插件](/zh/docs/reference/scheduling/profiles/#scheduling-plugins)
|
||||
[插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)
|
||||
都在使用中且默认启用。
|
||||
|
||||
<!--
|
||||
|
|
@ -468,9 +468,9 @@ plugins and get them configured along with default plugins. You can visit
|
|||
<!--
|
||||
If you are using Kubernetes v1.18 or later, you can configure a set of plugins as
|
||||
a scheduler profile and then define multiple profiles to fit various kinds of workload.
|
||||
Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
|
||||
Learn more at [multiple profiles](/docs/reference/scheduling/config/#multiple-profiles).
|
||||
-->
|
||||
如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为
|
||||
一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
|
||||
了解更多关于[多配置文件](/zh/docs/reference/scheduling/profiles/#multiple-profiles)。
|
||||
了解更多关于[多配置文件](/zh/docs/reference/scheduling/config/#multiple-profiles)。
|
||||
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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 或者在同一可用区域的端点。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
The following prerequisites are needed in order to enable topology aware service
|
||||
routing:
|
||||
|
||||
* Kubernetes 1.17 or later
|
||||
* Kube-proxy running in iptables mode or IPVS mode
|
||||
* Enable [Endpoint Slices](/zh/docs/concepts/services-networking/endpoint-slices/)
|
||||
-->
|
||||
|
||||
## 前提条件 {#prerequisites}
|
||||
|
||||
为了启用拓扑感知服务路由功能，必须要满足以下一些前提条件：
|
||||
|
||||
* Kubernetes 的版本不低于 1.17
|
||||
* Kube-proxy 运行在 iptables 模式或者 IPVS 模式
|
||||
* 启用 [端点切片](/zh/docs/concepts/services-networking/endpoint-slices/)功能
|
||||
|
||||
<!--
|
||||
## Enable Service Topology
|
||||
|
||||
To enable service topology, enable the `ServiceTopology` feature gate for
|
||||
kube-apiserver and kube-proxy:
|
||||
|
||||
```
|
||||
--feature-gates="ServiceTopology=true"
|
||||
```
|
||||
-->
|
||||
|
||||
## 启用 `Service` 拓扑 {#enable-service-topology}
|
||||
|
||||
要启用 `Service` 拓扑，就要给 kube-apiserver 和 kube-proxy 启用 `ServiceTopology` 功能：
|
||||
|
||||
```
|
||||
--feature-gates="ServiceTopology=true"
|
||||
```
|
||||
通过对源 `Node` 和目的 `Node` 标签的匹配，运营者可以使用任何符合运营者要求的度量值
|
||||
来指定彼此“较近”和“较远”的节点组。
|
||||
例如，对于在公有云上的运营者来说，更偏向于把流量控制在同一区域内，
|
||||
因为区域间的流量是有费用成本的，而区域内的流量没有。
|
||||
其它常用需求还包括把流量路由到由 `DaemonSet` 管理的本地 Pod 上，或者
|
||||
把保持流量在连接同一机架交换机的 `Node` 上，以获得低延时。
|
||||
|
||||
<!--
|
||||
## Using Service Topology
|
||||
|
|
@ -116,11 +84,21 @@ be used to mean "any topology". This catch-all value, if used, only makes sense
|
|||
as the last value in the list.
|
||||
-->
|
||||
|
||||
## 使用 `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`
|
||||
对那个客户端是没有后端的，链接应该是失败的。
|
||||
这个字段配置为 `"*"` 意味着任意拓扑。
|
||||
这个通配符值如果使用了，那么只有作为配置值列表中的最后一个才有用。
|
||||
|
||||
<!--
|
||||
If `topologyKeys` is not specified or empty, no topology constraints will be applied.
|
||||
|
|
@ -139,14 +117,18 @@ traffic as follows.
|
|||
none are available within this zone:
|
||||
`["topology.kubernetes.io/zone", "*"]`.
|
||||
-->
|
||||
如果 `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", "*"]`。
|
||||
|
||||
<!--
|
||||
## Constraints
|
||||
|
|
@ -168,25 +150,22 @@ traffic as follows.
|
|||
|
||||
## 约束条件 {#constraints}
|
||||
|
||||
* `Service` 拓扑和 `externalTrafficPolicy=Local` 是不兼容的，所以 `Service` 不能同时使用这两种特性。但是在同一个集群的不同 `Service` 上是可以分别使用这两种特性的，只要不在同一个 `Service` 上就可以。
|
||||
* 服务拓扑和 `externalTrafficPolicy=Local` 是不兼容的，所以 `Service` 不能同时使用这两种特性。
|
||||
但是在同一个集群的不同 `Service` 上是可以分别使用这两种特性的，只要不在同一个 `Service` 上就可以。
|
||||
|
||||
* 有效的拓扑键目前只有：`kubernetes.io/hostname`，`topology.kubernetes.io/zone` 和 `topology.kubernetes.io/region`，但是未来会推广到其它的 `Node` 标签。
|
||||
* 有效的拓扑键目前只有：`kubernetes.io/hostname`、`topology.kubernetes.io/zone` 和
|
||||
`topology.kubernetes.io/region`，但是未来会推广到其它的 `Node` 标签。
|
||||
|
||||
* 拓扑键必须是有效的标签，并且最多指定16个。
|
||||
|
||||
* 通配符：`"*"`，如果要用，那必须是拓扑键值的最后一个值。
|
||||
|
||||
|
||||
* 通配符：`"*"`，如果要用，则必须是拓扑键值的最后一个值。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology)
|
||||
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
|
||||
-->
|
||||
|
||||
* 阅读关于[启用服务拓扑](/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/)
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,10 @@ title: 持久卷
|
|||
feature:
|
||||
title: 存储编排
|
||||
description: >
|
||||
自动挂载所选存储系统，包括本地存储、诸如 <a href="https://cloud.google.com/storage/">GCP</a> 或 <a href="https://aws.amazon.com/products/storage/">AWS</a> 之类公有云提供商所提供的存储或者诸如 NFS、iSCSI、Gluster、Ceph、Cinder 或 Flocker 这类网络存储系统。
|
||||
自动挂载所选存储系统，包括本地存储、诸如 <a href="https://cloud.google.com/storage/">GCP</a>
|
||||
或 <a href="https://aws.amazon.com/products/storage/">AWS</a>
|
||||
之类公有云提供商所提供的存储或者诸如 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 申领。
|
||||
|
||||
|
|
|
|||
|
|
@ -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 驱动程序的卷的存储容量。
|
||||
|
||||
<!--
|
||||
## Scheduling
|
||||
|
|
@ -163,9 +166,11 @@ parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
|
|||
-->
|
||||
## 开启存储容量跟踪
|
||||
|
||||
存储容量跟踪是一个 *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/)。
|
||||
|
||||
<!--
|
||||
A quick check
|
||||
|
|
@ -203,6 +208,7 @@ support it. Please refer to the driver's documentation for
|
|||
details.
|
||||
-->
|
||||
如果不支持，下面这个错误就会被打印出来：
|
||||
|
||||
```
|
||||
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/)。
|
||||
- 想要获得更多该设计的信息，查看
|
||||
[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/)。
|
||||
|
|
|
|||
|
|
@ -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:
|
|||
<!--
|
||||
For more information, see the [vSphere volume](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) examples.
|
||||
-->
|
||||
进一步信息可参考[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。
|
||||
进一步信息可参考
|
||||
[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。
|
||||
|
||||
<!--
|
||||
#### vSphere CSI migration {#vsphere-csi-migration}
|
||||
|
|
@ -1766,7 +1770,8 @@ must be installed on the cluster and the `CSIMigration` and `CSIMigrationvSphere
|
|||
-->
|
||||
当 `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/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -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) 资源将其暴露到互联网上。
|
||||
|
||||
|
|
|
|||
|
|
@ -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 优先级和抢占
|
||||
的情况下制定调度决策。
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
可能更适用于你的无状态应用部署需要。
|
||||
|
||||
<!--
|
||||
## Limitations
|
||||
|
|
@ -67,11 +72,19 @@ that provides a set of stateless replicas.
|
|||
it's possible to get into a broken state that requires
|
||||
[manual intervention to repair](#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) 才能修复的损坏状态。
|
||||
* 给定 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)
|
||||
才能修复的损坏状态。
|
||||
|
||||
<!--
|
||||
## Components
|
||||
|
|
@ -140,7 +153,7 @@ spec:
|
|||
* 名为 `nginx` 的 Headless Service 用来控制网络域名。
|
||||
* 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
|
||||
* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
|
||||
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
|
||||
[PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
|
||||
|
||||
<!--
|
||||
## Pod Selector
|
||||
|
|
@ -150,7 +163,10 @@ spec:
|
|||
<!--
|
||||
You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
|
||||
-->
|
||||
您必须设置 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 Identity
|
||||
|
|
@ -161,7 +177,8 @@ regardless of which node it's (re)scheduled on.
|
|||
-->
|
||||
## Pod 标识 {#pod-identity}
|
||||
|
||||
StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的，不管它被调度在哪个节点上。
|
||||
StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。
|
||||
该标识和 Pod 是绑定的，不管它被调度在哪个节点上。
|
||||
|
||||
<!--
|
||||
### Ordinal Index
|
||||
|
|
@ -171,7 +188,8 @@ assigned an integer ordinal, from 0 up through N-1, that is unique over the Set.
|
|||
-->
|
||||
### 有序索引 {#ordinal-index}
|
||||
|
||||
对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号，从 0 到 N-1，该序号在 StatefulSet 上是唯一的。
|
||||
对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号，
|
||||
从 0 到 N-1，该序号在 StatefulSet 上是唯一的。
|
||||
|
||||
<!--
|
||||
### Stable Network ID
|
||||
|
|
@ -191,8 +209,9 @@ by the `serviceName` field on the StatefulSet.
|
|||
### 稳定的网络 ID {#stable-network-id}
|
||||
|
||||
StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。
|
||||
组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。
|
||||
StatefulSet 可以使用 [headless 服务](/zh/docs/concepts/services-networking/service/#headless-services)
|
||||
组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。
|
||||
上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。
|
||||
StatefulSet 可以使用 [无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
|
||||
控制它的 Pod 的网络域。管理域的这个服务的格式为：
|
||||
`$(服务名称).$(命名空间).svc.cluster.local`，其中 `cluster.local` 是集群域。
|
||||
一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：
|
||||
|
|
@ -232,7 +251,7 @@ This must be done manually.
|
|||
-->
|
||||
### 稳定的存储 {#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。
|
||||
|
||||
<!--
|
||||
## Deployment and Scaling Guarantees
|
||||
|
|
@ -296,8 +317,10 @@ is fully shutdown and deleted. If web-0 were to fail after web-2 has been termin
|
|||
is completely shutdown, but prior to web-1's termination, web-1 would not be terminated
|
||||
until web-0 is Running and Ready.
|
||||
-->
|
||||
|
||||
如果用户想将示例中的 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 Management Policies
|
||||
|
|
@ -307,8 +330,8 @@ preserving its uniqueness and identity guarantees via its `.spec.podManagementPo
|
|||
-->
|
||||
### Pod 管理策略 {#pod-management-policies}
|
||||
|
||||
在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您不要求其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。
|
||||
在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您放宽其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。
|
||||
在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许你放宽其排序保证，
|
||||
同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。
|
||||
|
||||
<!--
|
||||
#### OrderedReady Pod Management
|
||||
|
|
@ -318,7 +341,8 @@ described [above](#deployment-and-scaling-guarantees).
|
|||
-->
|
||||
#### OrderedReady Pod 管理
|
||||
|
||||
`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了[上面](#deployment-and-scaling-guarantees)描述的功能。
|
||||
`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了
|
||||
[上面](#deployment-and-scaling-guarantees)描述的功能。
|
||||
|
||||
<!--
|
||||
#### Parallel Pod Management
|
||||
|
|
@ -342,7 +366,8 @@ annotations for the Pods in a StatefulSet.
|
|||
-->
|
||||
## 更新策略 {#update-strategies}
|
||||
|
||||
在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让您可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。
|
||||
在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让
|
||||
你可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。
|
||||
|
||||
<!--
|
||||
### On Delete
|
||||
|
|
@ -354,8 +379,11 @@ create new Pods that reflect modifications made to a StatefulSet's `.spec.templa
|
|||
-->
|
||||
### 关于删除策略 {#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
|
||||
|
|
@ -369,9 +397,12 @@ updating its predecessor.
|
|||
-->
|
||||
### 滚动更新 {#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
|
||||
|
|
@ -388,8 +419,15 @@ update, roll out a canary, or perform a phased roll out.
|
|||
-->
|
||||
#### 分区 {#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
|
||||
|
|
@ -404,9 +442,11 @@ StatefulSet will stop the rollout and wait.
|
|||
-->
|
||||
#### 强制回滚 {#forced-rollback}
|
||||
|
||||
在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。
|
||||
在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 下使用
|
||||
[滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。
|
||||
|
||||
如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件或应用程序级配置错误），StatefulSet 将停止回滚并等待。
|
||||
如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件
|
||||
或应用程序级配置错误），StatefulSet 将停止回滚并等待。
|
||||
|
||||
<!--
|
||||
In this state, it's not enough to revert the Pod template to a good configuration.
|
||||
|
|
@ -433,10 +473,7 @@ StatefulSet 才会开始使用被还原的模板来重新创建 Pod。
|
|||
* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
|
||||
* Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
|
||||
-->
|
||||
|
||||
* 示例一：[部署有状态应用](/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/)。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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，如操纵网络堆栈和访问设备）
|
||||
的容器很有用。
|
||||
|
|
|
|||
|
|
@ -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 上的干扰类型。
|
||||
|
||||
<!--
|
||||
It is also for Cluster Administrators who want to perform automated
|
||||
|
|
@ -95,7 +95,7 @@ Cluster Administrator actions include:
|
|||
集群管理员操作包括：
|
||||
|
||||
- [排空（drain）节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。
|
||||
- 从集群中排空节点以缩小集群（了解[集群自动扩缩](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)）。
|
||||
- 从集群中排空节点以缩小集群（了解[集群自动扩缩](https://github.com/kubernetes/autoscaler/)）。
|
||||
- 从节点中移除一个 Pod，以允许其他 Pod 使用该节点。
|
||||
|
||||
<!--
|
||||
|
|
@ -147,7 +147,7 @@ or across zones (if using a
|
|||
和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
|
||||
- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用
|
||||
[反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)）或跨区域
|
||||
（如果使用[多区域集群](/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
|
||||
（如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
|
||||
|
||||
<!--
|
||||
The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are
|
||||
|
|
@ -204,7 +204,7 @@ instead of directly deleting pods or deployments. Examples are the `kubectl dra
|
|||
and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
|
||||
-->
|
||||
集群管理员和托管提供商应该使用遵循 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。
|
||||
|
||||
<!--
|
||||
|
|
@ -497,7 +497,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
|
|||
including steps to maintain its availability during the rollout.
|
||||
-->
|
||||
* 参考[配置 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)
|
||||
的过程，包括如何在其进程中维持应用的可用性
|
||||
|
||||
|
|
|
|||
|
|
@ -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 >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -11,8 +11,9 @@ weight: 40
|
|||
-->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
|
||||
<!-- leave this shortcode in place until the note about EvenPodsSpread is
|
||||
obsolete -->
|
||||
<!--
|
||||
leave this shortcode in place until the note about EvenPodsSpread is obsolete
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
|
|
@ -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 >}}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue