kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[zh] Sync changes from English site (7)

This commit is contained in:
Qiming Teng 2020-11-16 14:16:15 +08:00
parent edbab98ce4
commit 089040daa7
10 changed files with 494 additions and 347 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
content/zh/docs/concepts/scheduling-eviction/eviction-policy.md
View File

@ -1,11 +1,11 @@
---
title: 驱逐策略
content_template: templates/concept
content_type: concept
weight: 60
---
<!--
title: Eviction Policy
content_template: templates/concept
content_type: concept
weight: 60
-->
@ -20,25 +20,28 @@ This page is an overview of Kubernetes' policy for eviction.
<!--
## Eviction Policy
The {{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} can proactively monitor for and prevent total starvation of a
compute resource. In those cases, the `kubelet` can reclaim the starved
resource by proactively failing one or more Pods. When the `kubelet` fails
The {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} proactively monitors for
and prevents total starvation of a compute resource. In those cases, the `kubelet` can reclaim
the starved resource by failing one or more Pods. When the `kubelet` fails
a Pod, it terminates all of its containers and transitions its `PodPhase` to `Failed`.
If the evicted Pod is managed by a Deployment, the Deployment will create another Pod
If the evicted Pod is managed by a Deployment, the Deployment creates another Pod
to be scheduled by Kubernetes.
-->
## 驱逐策略 {#eviction-policy}
{{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} 能够主动监测和防止计算资源的全面短缺。
在资源短缺的情况下，`kubelet` 可以主动地结束一个或多个 Pod 以回收短缺的资源。
当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `Phase` 将变为 `Failed`。
如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给 Kubernetes 来调度。
{{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} 主动监测和防止
计算资源的全面短缺。在资源短缺时，`kubelet` 可以主动地结束一个或多个 Pod
以回收短缺的资源。
当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `Phase`
将变为 `Failed`。
如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给
Kubernetes 来调度。
## {{% heading "whatsnext" %}}
<!--
- Read [Configure out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) to learn more about eviction signals, thresholds, and handling.
- Learn how to [configure out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) with eviction signals and thresholds.
-->
- 阅读[配置资源不足的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，
进一步了解驱逐信号、阈值以及处理方法。
进一步了解驱逐信号和阈值。

60
content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md
View File

@ -26,23 +26,25 @@ The kube-scheduler can be configured to enable bin packing of resources along wi
<!--
## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters and improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
-->
## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱
在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）的请求数量和可用容量
之比率对节点评分。
在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）
的请求数量和可用容量 之比率对节点评分。
Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重，
以便根据请求数量与可用容量之比率为节点评分。
这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。
`RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为
`requestedToCapacityRatioArguments` 的配置选项进行控制。
该标志由两个参数 `shape` 和 `resources` 组成。
shape 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求（least requested）或
`shape` 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求
（least requested）或
最多请求（most requested）计算。
resources 由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。
`resources` 包含由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，
`weight` 指定每种资源的权重。
<!--
Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
@ -53,29 +55,29 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`
```json
{
"kind" : "Policy",
"apiVersion" : "v1",
...
"priorities" : [
...
{
"name": "RequestedToCapacityRatioPriority",
"weight": 2,
"argument": {
"requestedToCapacityRatioArguments": {
"shape": [
{"utilization": 0, "score": 0},
{"utilization": 100, "score": 10}
],
"resources": [
{"name": "intel.com/foo", "weight": 3},
{"name": "intel.com/bar", "weight": 5}
]
}
"kind": "Policy",
"apiVersion": "v1",
...
"priorities": [
...
{
"name": "RequestedToCapacityRatioPriority",
"weight": 2,
"argument": {
"requestedToCapacityRatioArguments": {
"shape": [
{"utilization": 0, "score": 0},
{"utilization": 100, "score": 10}
],
"resources": [
{"name": "intel.com/foo", "weight": 3},
{"name": "intel.com/bar", "weight": 5}
]
}
}
],
}
}
],
}
```
<!--
@ -89,7 +91,6 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`
`shape` is used to specify the behavior of the `RequestedToCapacityRatioPriority` function.
-->
### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数
`shape` 用于指定 `RequestedToCapacityRatioPriority` 函数的行为。
@ -103,8 +104,9 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`
The above arguments give the node a score of 0 if utilization is 0% and 10 for utilization 100%, thus enabling bin packing behavior. To enable least requested the score value must be reversed as follows.
-->
上面的参数在 utilization 为 0% 时给节点评分为 0，在 utilization 为 100% 时给节点评分为 10，
因此启用了装箱行为。要启用最少请求（least requested）模式，必须按如下方式反转得分值。
上面的参数在 `utilization` 为 0% 时给节点评分为 0，在 `utilization` 为
100% 时给节点评分为 10，因此启用了装箱行为。
要启用最少请求（least requested）模式，必须按如下方式反转得分值。
```yaml
{"utilization": 0, "score": 100},

64
content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
View File

@ -54,7 +54,8 @@ You configure this tuning setting via kube-scheduler setting
`percentageOfNodesToScore`. This KubeSchedulerConfiguration setting determines
a threshold for scheduling nodes in your cluster.
-->
在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）和精度（调度器很少做出糟糕的放置决策）。
在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）
和精度（调度器很少做出糟糕的放置决策）。
你可以通过设置 kube-scheduler 的 `percentageOfNodesToScore` 来配置这个调优设置。
这个 KubeSchedulerConfiguration 设置决定了调度集群中节点的阈值。
@ -71,33 +72,32 @@ should use its compiled-in default.
If you set `percentageOfNodesToScore` above 100, kube-scheduler acts as if you
had set a value of 100.
-->
`percentageOfNodesToScore` 选项接受从 0 到 100 之间的整数值。0 值比较特殊，表示 kube-scheduler 应该使用其编译后的默认值。
如果你设置 `percentageOfNodesToScore` 的值超过了 100，kube-scheduler 的表现等价于设置值为 100。
`percentageOfNodesToScore` 选项接受从 0 到 100 之间的整数值。
0 值比较特殊，表示 kube-scheduler 应该使用其编译后的默认值。
如果你设置 `percentageOfNodesToScore` 的值超过了 100，
kube-scheduler 的表现等价于设置值为 100。
<!--
To change the value, edit the kube-scheduler configuration file (this is likely
to be `/etc/kubernetes/config/kube-scheduler.yaml`), then restart the scheduler.
-->
要修改这个值，编辑 kube-scheduler 的配置文件（通常是 `/etc/kubernetes/config/kube-scheduler.yaml`），然后重启调度器。
要修改这个值，编辑 kube-scheduler 的配置文件
（通常是 `/etc/kubernetes/config/kube-scheduler.yaml`），
然后重启调度器。
<!--
After you have made this change, you can run
-->
修改完成后，你可以执行
```bash
kubectl get componentstatuses
kubectl get pods -n kube-system | grep kube-scheduler
```
<!--
to verify that the kube-scheduler component is healthy. The output is similar to:
to verify that the kube-scheduler component is healthy.
-->
来检查该 kube-scheduler 组件是否健康。输出类似如下：
```
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
...
```
来检查该 kube-scheduler 组件是否健康。
<!--
## Node scoring threshold {#percentage-of-nodes-to-score}
@ -109,7 +109,8 @@ To improve scheduling performance, the kube-scheduler can stop looking for
feasible nodes once it has found enough of them. In large clusters, this saves
time compared to a naive approach that would consider every node.
-->
要提升调度性能，kube-scheduler 可以在找到足够的可调度节点之后停止查找。在大规模集群中，比起考虑每个节点的简单方法相比可以节省时间。
要提升调度性能，kube-scheduler 可以在找到足够的可调度节点之后停止查找。
在大规模集群中，比起考虑每个节点的简单方法相比可以节省时间。
<!--
You specify a threshold for how many nodes are enough, as a whole number percentage
@ -141,8 +142,8 @@ If you don't specify a threshold, Kubernetes calculates a figure using a
linear formula that yields 50% for a 100-node cluster and yields 10%
for a 5000-node cluster. The lower bound for the automatic value is 5%.
-->
如果你不指定阈值，Kubernetes 使用线性公式计算出一个比例，在 100-node 集群下取 50%，在 5000-node 的集群下取 10%。
这个自动设置的参数的最低值是 5%。
如果你不指定阈值，Kubernetes 使用线性公式计算出一个比例，在 100-节点集群
下取 50%，在 5000-节点的集群下取 10%。这个自动设置的参数的最低值是 5%。
<!--
This means that, the kube-scheduler always scores at least 5% of your cluster no
@ -205,12 +206,14 @@ scheduler's performance significantly.
{{< /note >}}
-->
{{< note >}}
当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，因为可调度节点太少，不足以停止调度器最初的过滤选择。
当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，
因为可调度节点太少，不足以停止调度器最初的过滤选择。
同理，在小规模集群中，如果你将 `percentageOfNodesToScore` 设置为一个较低的值，则没有或者只有很小的效果。
如果集群只有几百个节点或者更少，请保持这个配置的默认值。改变基本不会对调度器的性能有明显的提升。
同理，在小规模集群中，如果你将 `percentageOfNodesToScore` 设置为
一个较低的值，则没有或者只有很小的效果。
如果集群只有几百个节点或者更少，请保持这个配置的默认值。
改变基本不会对调度器的性能有明显的提升。
{{< /note >}}
<!--
@ -226,9 +229,15 @@ percentage to anything below 10%, unless the scheduler's throughput is critical
for your application and the score of nodes is not important. In other words, you
prefer to run the Pod on any Node as long as it is feasible.
-->
值得注意的是，该参数设置后可能会导致只有集群中少数节点被选为可调度节点，很多 node 都没有进入到打分阶段。这样就会造成一种后果，一个本来可以在打分阶段得分很高的 Node 甚至都不能进入打分阶段。
值得注意的是，该参数设置后可能会导致只有集群中少数节点被选为可调度节点，
很多节点都没有进入到打分阶段。这样就会造成一种后果，
一个本来可以在打分阶段得分很高的节点甚至都不能进入打分阶段。
由于这个原因，这个参数不应该被设置成一个很低的值。通常的做法是不会将这个参数的值设置的低于 10。很低的参数值一般在调度器的吞吐量很高且对 node 的打分不重要的情况下才使用。换句话说，只有当你更倾向于在可调度节点中任意选择一个 Node 来运行这个 Pod 时，才使用很低的参数设置。
由于这个原因，这个参数不应该被设置成一个很低的值。
通常的做法是不会将这个参数的值设置的低于 10。
很低的参数值一般在调度器的吞吐量很高且对节点的打分不重要的情况下才使用。
换句话说，只有当你更倾向于在可调度节点中任意选择一个节点来运行这个 Pod 时，
才使用很低的参数设置。
<!--
### How the scheduler iterates over Nodes
@ -250,14 +259,20 @@ Nodes as specified by `percentageOfNodesToScore`. For the next Pod, the
scheduler continues from the point in the Node array that it stopped at when
checking feasibility of Nodes for the previous Pod.
-->
在将 Pod 调度到 Node 上时，为了让集群中所有 Node 都有公平的机会去运行这些 Pod，调度器将会以轮询的方式覆盖全部的 Node。你可以将 Node 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，依次向后直到可调度节点的数量达到 `percentageOfNodesToScore` 参数的要求。在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Node 列表的位置，将会来作为这次调度筛选 Node 开始的位置。
在将 Pod 调度到节点上时，为了让集群中所有节点都有公平的机会去运行这些 Pod，
调度器将会以轮询的方式覆盖全部的 Node。
你可以将 Node 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，
依次向后直到可调度节点的数量达到 `percentageOfNodesToScore` 参数的要求。
在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Node 列表的位置，
将会来作为这次调度筛选 Node 开始的位置。
<!--
If Nodes are in multiple zones, the scheduler iterates over Nodes in various
zones to ensure that Nodes from different zones are considered in the
feasibility checks. As an example, consider six nodes in two zones:
-->
如果集群中的 Node 在多个区域，那么调度器将从不同的区域中轮询 Node，来确保不同区域的 Node 接受可调度性检查。如下例，考虑两个区域中的六个节点：
如果集群中的 Node 在多个区域，那么调度器将从不同的区域中轮询 Node，
来确保不同区域的 Node 接受可调度性检查。如下例，考虑两个区域中的六个节点：
```
Zone 1: Node 1, Node 2, Node 3, Node 4
@ -278,4 +293,3 @@ After going over all the Nodes, it goes back to Node 1.
-->
在评估完所有 Node 后，将会返回到 Node 1，从头开始。

173
content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
View File

@ -7,13 +7,11 @@ weight: 70
---
<!--
---
reviewers:
- ahg-g
title: Scheduling Framework
content_type: concept
weight: 60
---
-->
<!-- overview -->
@ -29,19 +27,17 @@ scheduling "core" simple and maintainable. Refer to the [design proposal of the
scheduling framework][kep] for more technical information on the design of the
framework.
-->
调度框架是 Kubernetes Scheduler 的一种可插入架构，可以简化调度器的自定义。它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。请参考[调度框架的设计提案][kep]获取框架设计的更多技术信息。
[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
调度框架是 Kubernetes Scheduler 的一种可插入架构，可以简化调度器的自定义。
它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。
这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。
请参考[调度框架的设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md)
获取框架设计的更多技术信息。
<!-- body -->
<!--
# Framework workflow
-->
# 框架工作流程
<!--
@ -49,20 +45,18 @@ The Scheduling Framework defines a few extension points. Scheduler plugins
register to be invoked at one or more extension points. Some of these plugins
can change the scheduling decisions and some are informational only.
-->
调度框架定义了一些扩展点。调度器插件注册后在一个或多个扩展点处被调用。这些插件中的一些可以改变调度决策，而另一些仅用于提供信息。
调度框架定义了一些扩展点。调度器插件注册后在一个或多个扩展点处被调用。
这些插件中的一些可以改变调度决策，而另一些仅用于提供信息。
<!--
Each attempt to schedule one Pod is split into two phases, the **scheduling
cycle** and the **binding cycle**.
-->
每次调度一个 Pod 的尝试都分为两个阶段，即 **调度周期** 和 **绑定周期**。
<!--
## Scheduling Cycle & Binding Cycle
-->
## 调度周期和绑定周期
<!--
@ -70,13 +64,12 @@ The scheduling cycle selects a node for the Pod, and the binding cycle applies
that decision to the cluster. Together, a scheduling cycle and binding cycle are
referred to as a "scheduling context".
-->
调度周期为 Pod 选择一个节点，绑定周期将该决策应用于集群。调度周期和绑定周期一起被称为“调度上下文”。
调度周期为 Pod 选择一个节点，绑定周期将该决策应用于集群。
调度周期和绑定周期一起被称为“调度上下文”。
<!--
Scheduling cycles are run serially, while binding cycles may run concurrently.
-->
调度周期是串行运行的，而绑定周期可能是同时运行的。
<!--
@ -84,13 +77,12 @@ A scheduling or binding cycle can be aborted if the Pod is determined to
be unschedulable or if there is an internal error. The Pod will be returned to
the queue and retried.
-->
如果确定 Pod 不可调度或者存在内部错误，则可以终止调度周期或绑定周期。Pod 将返回队列并重试。
如果确定 Pod 不可调度或者存在内部错误，则可以终止调度周期或绑定周期。
Pod 将返回队列并重试。
<!--
## Extension points
-->
## 扩展点
<!--
@ -98,14 +90,13 @@ The following picture shows the scheduling context of a Pod and the extension
points that the scheduling framework exposes. In this picture "Filter" is
equivalent to "Predicate" and "Scoring" is equivalent to "Priority function".
-->
下图显示了一个 Pod 的调度上下文以及调度框架公开的扩展点。在此图片中，“过滤器”等同于“断言”，“评分”相当于“优先级函数”。
下图显示了一个 Pod 的调度上下文以及调度框架公开的扩展点。
在此图片中，“过滤器”等同于“断言”，“评分”相当于“优先级函数”。
<!--
One plugin may register at multiple extension points to perform more complex or
stateful tasks.
-->
一个插件可以在多个扩展点处注册，以执行更复杂或有状态的任务。
<!--
@ -113,7 +104,6 @@ stateful tasks.
-->
{{< figure src="/images/docs/scheduling-framework-extensions.png" title="调度框架扩展点" >}}
<!--
### QueueSort {#queue-sort}
-->
@ -124,13 +114,13 @@ These plugins are used to sort Pods in the scheduling queue. A queue sort plugin
essentially provides a `less(Pod1, Pod2)` function. Only one queue sort
plugin may be enabled at a time.
-->
队列排序插件用于对调度队列中的 Pod 进行排序。队列排序插件本质上提供 "less(Pod1, Pod2)" 函数。一次只能启动一个队列插件。
队列排序插件用于对调度队列中的 Pod 进行排序。
队列排序插件本质上提供 `less(Pod1, Pod2)` 函数。
一次只能启动一个队列插件。
<!--
### PreFilter {#pre-filter}
-->
### 前置过滤 {#pre-filter}
<!--
@ -138,13 +128,12 @@ These plugins are used to pre-process info about the Pod, or to check certain
conditions that the cluster or the Pod must meet. If a PreFilter plugin returns
an error, the scheduling cycle is aborted.
-->
前置过滤插件用于预处理 Pod 的相关信息，或者检查集群或 Pod 必须满足的某些条件。如果 PreFilter 插件返回错误，则调度周期将终止。
前置过滤插件用于预处理 Pod 的相关信息，或者检查集群或 Pod 必须满足的某些条件。
如果 PreFilter 插件返回错误，则调度周期将终止。
<!--
### Filter
-->
### 过滤
<!--
@ -153,13 +142,13 @@ node, the scheduler will call filter plugins in their configured order. If any
filter plugin marks the node as infeasible, the remaining plugins will not be
called for that node. Nodes may be evaluated concurrently.
-->
过滤插件用于过滤出不能运行该 Pod 的节点。对于每个节点，调度器将按照其配置顺序调用这些过滤插件。如果任何过滤插件将节点标记为不可行，则不会为该节点调用剩下的过滤插件。节点可以被同时进行评估。
过滤插件用于过滤出不能运行该 Pod 的节点。对于每个节点，
调度器将按照其配置顺序调用这些过滤插件。如果任何过滤插件将节点标记为不可行，
则不会为该节点调用剩下的过滤插件。节点可以被同时进行评估。
<!--
### PostFilter {#post-filter}
-->
### 后置过滤 {#post-filter}
<!--
@ -170,7 +159,10 @@ will not be called. A typical PostFilter implementation is preemption, which
tries to make the pod schedulable by preempting other Pods.
-->
这些插件在筛选阶段后调用，但仅在该 pod 没有可行的节点时调用。插件按其配置的顺序调用。如果任何后过滤器插件标记节点为“可调度”， 则其余的插件不会调用。典型的后筛选实现是抢占，试图通过抢占其他 pod 的资源使该 pod 可以调度。
这些插件在筛选阶段后调用，但仅在该 Pod 没有可行的节点时调用。
插件按其配置的顺序调用。如果任何后过滤器插件标记节点为“可调度”，
则其余的插件不会调用。典型的后筛选实现是抢占，试图通过抢占其他 Pod
的资源使该 Pod 可以调度。
<!--
### PreScore {#pre-score}
@ -182,7 +174,8 @@ These plugins are used to perform "pre-scoring" work, which generates a sharable
state for Score plugins to use. If a PreScore plugin returns an error, the
scheduling cycle is aborted.
-->
前置评分插件用于执行 “前置评分” 工作，即生成一个可共享状态供评分插件使用。如果 PreScore 插件返回错误，则调度周期将终止。
前置评分插件用于执行 “前置评分” 工作，即生成一个可共享状态供评分插件使用。
如果 PreScore 插件返回错误，则调度周期将终止。
<!--
### Score {#scoring}
@ -196,13 +189,14 @@ defined range of integers representing the minimum and maximum scores. After the
[NormalizeScore](#normalize-scoring) phase, the scheduler will combine node
scores from all plugins according to the configured plugin weights.
-->
评分插件用于对通过过滤阶段的节点进行排名。调度器将为每个节点调用每个评分插件。将有一个定义明确的整数范围，代表最小和最大分数。在[标准化评分](#normalize-scoring)阶段之后，调度器将根据配置的插件权重合并所有插件的节点分数。
评分插件用于对通过过滤阶段的节点进行排名。调度器将为每个节点调用每个评分插件。
将有一个定义明确的整数范围，代表最小和最大分数。
在[标准化评分](#normalize-scoring)阶段之后，调度器将根据配置的插件权重
合并所有插件的节点分数。
<!--
### NormalizeScore {#normalize-scoring}
-->
### 标准化评分 {#normalize-scoring}
<!--
@ -211,14 +205,14 @@ ranking of Nodes. A plugin that registers for this extension point will be
called with the [Score](#scoring) results from the same plugin. This is called
once per plugin per scheduling cycle.
-->
标准化评分插件用于在调度器计算节点的排名之前修改分数。在此扩展点注册的插件将使用同一插件的[评分](#scoring) 结果被调用。每个插件在每个调度周期调用一次。
标准化评分插件用于在调度器计算节点的排名之前修改分数。
在此扩展点注册的插件将使用同一插件的[评分](#scoring) 结果被调用。
每个插件在每个调度周期调用一次。
<!--
For example, suppose a plugin `BlinkingLightScorer` ranks Nodes based on how
many blinking lights they have.
-->
例如，假设一个 `BlinkingLightScorer` 插件基于具有的闪烁指示灯数量来对节点进行排名。
```go
@ -232,8 +226,8 @@ However, the maximum count of blinking lights may be small compared to
`NodeScoreMax`. To fix this, `BlinkingLightScorer` should also register for this
extension point.
-->
然而，最大的闪烁灯个数值可能比 `NodeScoreMax` 小。要解决这个问题，`BlinkingLightScorer` 插件还应该注册该扩展点。
然而，最大的闪烁灯个数值可能比 `NodeScoreMax` 小。要解决这个问题，
`BlinkingLightScorer` 插件还应该注册该扩展点。
```go
func NormalizeScores(scores map[string]int) {
@ -251,7 +245,6 @@ func NormalizeScores(scores map[string]int) {
If any NormalizeScore plugin returns an error, the scheduling cycle is
aborted.
-->
如果任何 NormalizeScore 插件返回错误，则调度阶段将终止。
<!--
@ -265,8 +258,7 @@ NormalizeScore extension point.
<!--
### Reserve
-->
### 保留
### Reserve
<!--
This is an informational extension point. Plugins which maintain runtime state
@ -275,37 +267,38 @@ scheduler when resources on a node are being reserved for a given Pod. This
happens before the scheduler actually binds the Pod to the Node, and it exists
to prevent race conditions while the scheduler waits for the bind to succeed.
-->
保留是一个信息性的扩展点。管理运行时状态的插件（也成为“有状态插件”）应该使用此扩展点，以便调度器在节点给指定 Pod 预留了资源时能够通知该插件。这是在调度器真正将 Pod 绑定到节点之前发生的，并且它存在是为了防止在调度器等待绑定成功时发生竞争情况。
Reserve 是一个信息性的扩展点。
管理运行时状态的插件（也成为“有状态插件”）应该使用此扩展点，以便
调度器在节点给指定 Pod 预留了资源时能够通知该插件。
这是在调度器真正将 Pod 绑定到节点之前发生的，并且它存在是为了防止
在调度器等待绑定成功时发生竞争情况。
<!--
This is the last step in a scheduling cycle. Once a Pod is in the reserved
state, it will either trigger [Unreserve](#unreserve) plugins (on failure) or
[PostBind](#post-bind) plugins (on success) at the end of the binding cycle.
-->
这个是调度周期的最后一步。一旦 Pod 处于保留状态，它将在绑定周期结束时触发[不保留](#不保留) 插件（失败时）或
[绑定后](#post-bind) 插件（成功时）。
这个是调度周期的最后一步。
一旦 Pod 处于保留状态，它将在绑定周期结束时触发[不保留](#unreserve) 插件
（失败时）或 [绑定后](#post-bind) 插件（成功时）。
<!--
### Permit
-->
### 允许
### Permit
<!--
_Permit_ plugins are invoked at the end of the scheduling cycle for each Pod, to
prevent or delay the binding to the candidate node. A permit plugin can do one of
the three things:
-->
_Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 Pod 的绑定。一个允许插件可以做以下三件事之一：
_Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 Pod 的绑定。
一个允许插件可以做以下三件事之一：
<!--
1. **approve** \
Once all Permit plugins approve a Pod, it is sent for binding.
-->
1. **批准** \
一旦所有 Permit 插件批准 Pod 后，该 Pod 将被发送以进行绑定。
@ -314,9 +307,9 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟
If any Permit plugin denies a Pod, it is returned to the scheduling queue.
This will trigger [Unreserve](#unreserve) plugins.
-->
1. **拒绝** \
如果任何 Permit 插件拒绝 Pod，则该 Pod 将被返回到调度队列。这将触发[不保留](#不保留) 插件。
如果任何 Permit 插件拒绝 Pod，则该 Pod 将被返回到调度队列。
这将触发[Unreserve](#unreserve) 插件。
<!--
1. **wait** (with a timeout) \
@ -326,9 +319,11 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟
and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve)
plugins.
-->
1. **等待**（带有超时） \
如果一个 Permit 插件返回 “等待” 结果，则 Pod 将保持在一个内部的 “等待中” 的 Pod 列表，同时该 Pod 的绑定周期启动时即直接阻塞直到得到[批准](#frameworkhandle)。如果超时发生，**等待** 变成 **拒绝**，并且 Pod 将返回调度队列，从而触发[不保留](#不保留) 插件。
如果一个 Permit 插件返回 “等待” 结果，则 Pod 将保持在一个内部的 “等待中”
的 Pod 列表，同时该 Pod 的绑定周期启动时即直接阻塞直到得到
[批准](#frameworkhandle)。如果超时发生，**等待** 变成 **拒绝**，并且 Pod
将返回调度队列，从而触发 [Unreserve](#unreserve) 插件。
<!--
@ -338,13 +333,15 @@ plugins to approve binding of reserved Pods that are in "waiting" state. Once a
is approved, it is sent to the [PreBind](#pre-bind) phase.
-->
{{< note >}}
尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 (查看 [`FrameworkHandle`](#frameworkhandle))。我们希望只有允许插件可以批准处于 “等待中” 状态的 预留 Pod 的绑定。一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。
尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们
(查看 [`FrameworkHandle`](#frameworkhandle))。
我们希望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。
一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。
{{< /note >}}
<!--
### Pre-bind {#pre-bind}
-->
### 预绑定 {#pre-bind}
<!--
@ -352,21 +349,21 @@ These plugins are used to perform any work required before a Pod is bound. For
example, a pre-bind plugin may provision a network volume and mount it on the
target node before allowing the Pod to run there.
-->
预绑定插件用于执行 Pod 绑定前所需的任何工作。例如，一个预绑定插件可能需要提供网络卷并且在允许 Pod 运行在该节点之前将其挂载到目标节点上。
预绑定插件用于执行 Pod 绑定前所需的任何工作。
例如，一个预绑定插件可能需要提供网络卷并且在允许 Pod 运行在该节点之前
将其挂载到目标节点上。
<!--
If any PreBind plugin returns an error, the Pod is [rejected](#unreserve) and
returned to the scheduling queue.
-->
如果任何 PreBind 插件返回错误，则 Pod 将被[拒绝](#不保留) 并且返回到调度队列中。
如果任何 PreBind 插件返回错误，则 Pod 将被[拒绝](#unreserve) 并且
退回到调度队列中。
<!--
### Bind
-->
### 绑定
### Bind
<!--
These plugins are used to bind a Pod to a Node. Bind plugins will not be called
@ -375,13 +372,13 @@ configured order. A bind plugin may choose whether or not to handle the given
Pod. If a bind plugin chooses to handle a Pod, **the remaining bind plugins are
skipped**.
-->
绑定插件用于将 Pod 绑定到节点上。直到所有的 PreBind 插件都完成，绑定插件才会被调用。每个绑定插件按照配置顺序被调用。绑定插件可以选择是否处理指定的 Pod。如果绑定插件选择处理 Pod，**剩余的绑定插件将被跳过**。
Bind 插件用于将 Pod 绑定到节点上。直到所有的 PreBind 插件都完成，Bind 插件才会被调用。
各绑定插件按照配置顺序被调用。绑定插件可以选择是否处理指定的 Pod。
如果绑定插件选择处理 Pod，**剩余的绑定插件将被跳过**。
<!--
### PostBind {#post-bind}
-->
### 绑定后 {#post-bind}
<!--
@ -389,34 +386,32 @@ This is an informational extension point. Post-bind plugins are called after a
Pod is successfully bound. This is the end of a binding cycle, and can be used
to clean up associated resources.
-->
这是个信息性的扩展点。绑定后插件在 Pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。
这是个信息性的扩展点。
绑定后插件在 Pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。
<!--
### Unreserve
-->
### 不保留
### Unreserve
<!--
This is an informational extension point. If a Pod was reserved and then
rejected in a later phase, then unreserve plugins will be notified. Unreserve
plugins should clean up state associated with the reserved Pod.
-->
这是个信息性的扩展点。如果 Pod 被保留，然后在后面的阶段中被拒绝，则不保留插件将被通知。不保留插件应该清楚保留 Pod 的相关状态。
这是个信息性的扩展点。
如果 Pod 被保留，然后在后面的阶段中被拒绝，则 Unreserve 插件将被通知。
Unreserve 插件应该清楚保留 Pod 的相关状态。
<!--
Plugins that use this extension point usually should also use
[Reserve](#reserve).
-->
使用此扩展点的插件通常也使用[保留](#保留)。
使用此扩展点的插件通常也使用[Reserve](#reserve)。
<!--
## Plugin API
-->
## 插件 API
<!--
@ -424,8 +419,8 @@ There are two steps to the plugin API. First, plugins must register and get
configured, then they use the extension point interfaces. Extension point
interfaces have the following form.
-->
插件 API 分为两个步骤。首先，插件必须注册并配置，然后才能使用扩展点接口。扩展点接口具有以下形式。
插件 API 分为两个步骤。首先，插件必须完成注册并配置，然后才能使用扩展点接口。
扩展点接口具有以下形式。
```go
type Plugin interface {
@ -448,7 +443,6 @@ type PreFilterPlugin interface {
<!--
# Plugin Configuration
-->
# 插件配置
<!--
@ -457,21 +451,26 @@ Kubernetes v1.18 or later, most scheduling
[plugins](/docs/reference/scheduling/profiles/#scheduling-plugins) are in use and
enabled by default.
-->
你可以在调度器配置中启用或禁用插件。如果你在使用 Kubernetes v1.18 或更高版本，大部分调度[插件](/docs/reference/scheduling/profiles/#scheduling-plugins) 都在使用中且默认启用。
你可以在调度器配置中启用或禁用插件。
如果你在使用 Kubernetes v1.18 或更高版本，大部分调度
[插件](/zh/docs/reference/scheduling/profiles/#scheduling-plugins)
都在使用中且默认启用。
<!--
In addition to default plugins, you can also implement your own scheduling
plugins and get them configured along with default plugins. You can visit
[scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins) for more details.
-->
除了默认的插件，你同样可以实现自己的调度插件并且将他们与默认插件一起配置。你可以访问 [调度插件](https://github.com/kubernetes-sigs/scheduler-plugins) 了解更多详情。
除了默认的插件，你还可以实现自己的调度插件并且将它们与默认插件一起配置。
你可以访问[scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins)
了解更多信息。
<!--
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).
-->
如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
了解更多关于 [多配置文件](/docs/reference/scheduling/profiles/#multiple-profiles)。
如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为
一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
了解更多关于[多配置文件](/zh/docs/reference/scheduling/profiles/#multiple-profiles)。

18
content/zh/docs/concepts/storage/dynamic-provisioning.md
View File

@ -22,7 +22,8 @@ automatically provisions storage when it is requested by users.
-->
动态卷供应允许按需创建存储卷。
如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/docs/concepts/storage/persistent-volumes/)来表示这些卷。
然后在 Kubernetes 集群创建
[`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。
动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。
<!-- body -->
@ -46,7 +47,7 @@ that provisioner when provisioning.
<!--
A cluster administrator can define and expose multiple flavors of storage (from
the same or different storage systems) within a cluster, each with a custom set
of parameters. This design also ensures that end users don’t have to worry
of parameters. This design also ensures that end users don't have to worry
about the complexity and nuances of how storage is provisioned, but still
have the ability to select from multiple storage options.
-->
@ -122,10 +123,10 @@ administrator (see [below](#enabling-dynamic-provisioning)).
这个字段的值必须能够匹配到集群管理员配置的 `StorageClass` 名称（见[下面](#enabling-dynamic-provisioning)）。
<!--
To select the “fast” storage class, for example, a user would create the
following `PersistentVolumeClaim`:
To select the "fast" storage class, for example, a user would create the
following PersistentVolumeClaim:
-->
例如，要选择 "fast" 存储类，用户将创建如下的 `PersistentVolumeClaim`：
例如，要选择 “fast” 存储类，用户将创建如下的 PersistentVolumeClaim：
```yaml
apiVersion: v1
@ -151,7 +152,7 @@ provisioned. When the claim is deleted, the volume is destroyed.
<!--
## Defaulting Behavior
-->
## 默认行为
## 设置默认值的行为
<!--
Dynamic provisioning can be enabled on a cluster such that all claims are
@ -186,7 +187,8 @@ Note that there can be at most one *default* storage class on a cluster, or
a `PersistentVolumeClaim` without `storageClassName` explicitly specified cannot
be created.
-->
请注意，群集上最多只能有一个 *默认* 存储类，否则无法创建没有明确指定 `storageClassName` 的 `PersistentVolumeClaim`。
请注意，群集上最多只能有一个 *默认* 存储类，否则无法创建没有明确指定
`storageClassName` 的 `PersistentVolumeClaim`。
<!--
## Topology Awareness
@ -199,7 +201,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
Pods are scheduled. This can be accomplished by setting the [Volume Binding
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
-->
在[多区域](/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
单区域存储后端应该被供应到 Pod 被调度到的区域。
这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。

33
content/zh/docs/concepts/storage/ephemeral-volumes.md
View File

@ -72,10 +72,9 @@ different purposes:
[downwardAPI](/docs/concepts/storage/volumes/#downwardapi),
[secret](/docs/concepts/storage/volumes/#secret): inject different
kinds of Kubernetes data into a Pod
- [CSI ephemeral
volumes](docs/concepts/storage/volumes/#csi-ephemeral-volumes):
similar to the previous volume kinds, but provided by special [CSI
drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
- [CSI ephemeral volumes](#csi-ephemeral-volume):
similar to the previous volume kinds, but provided by special
[CSI drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
which specifically [support this feature](https://kubernetes-csi.github.io/docs/drivers.html)
- [generic ephemeral volumes](#generic-ephemeral-volumes), which
can be provided by all storage drivers that also support persistent volumes
@ -287,8 +286,8 @@ spec:
### 生命周期和 PersistentVolumeClaim {#lifecycle-and-persistentvolumeclaim}
<!--
The key design idea is that the [parameters for a
volume claim](/docs/reference/generated/kubernetes-api/#ephemeralvolumesource-v1alpha1-core)
The key design idea is that the
[parameters for a volume claim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)
are allowed inside a volume source of the Pod. Labels, annotations and
the whole set of fields for a PersistentVolumeClaim are supported. When such a Pod gets
created, the ephemeral volume controller then creates an actual PersistentVolumeClaim
@ -296,11 +295,11 @@ object in the same namespace as the Pod and ensures that the PersistentVolumeCla
gets deleted when the Pod gets deleted.
-->
关键的设计思想是在 Pod 的卷来源中允许使用
[卷申领的参数](/docs/reference/generated/kubernetes-api/#ephemeralvolumesource-v1alpha1-core)。
[卷申领的参数](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)。
PersistentVolumeClaim 的标签、注解和整套字段集均被支持。
创建这样一个 Pod 后，
临时卷控制器在 Pod 所属的命名空间中创建一个实际的 PersistentVolumeClaim 对象，
并确保删除 Pod 时， 同步删除PersistentVolumeClaim 。
并确保删除 Pod 时，同步删除 PersistentVolumeClaim。
<!--
That triggers volume binding and/or provisioning, either immediately if
@ -417,7 +416,8 @@ two choices:
`volumes` list does not contain the `ephemeral` volume type.
-->
- 通过特性门控显式禁用该特性，可以避免将来的 Kubernetes 版本默认启用时带来混乱。
- 当`卷`列表不包含 `ephemeral` 卷类型时，使用 [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)。
- 当`卷`列表不包含 `ephemeral` 卷类型时，使用
[Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)。
<!--
The normal namespace quota for PVCs in a namespace still applies, so
@ -435,6 +435,7 @@ it to circumvent other policies.
See [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage).
-->
### kubelet 管理的临时卷 {#ephemeral-volumes-managed-by-kubelet}
参阅[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)。
<!--
@ -446,9 +447,10 @@ See [local ephemeral storage](/docs/concepts/configuration/manage-resources-cont
-->
### CSI 临时卷 {#csi-ephemeral-volumes}
- 有关设计的更多信息，参阅 [Ephemeral Inline CSI
volumes KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md)。
- 本特性下一步开发的更多信息，参阅 [enhancement tracking issue #596](https://github.com/kubernetes/enhancements/issues/596)。
- 有关设计的更多信息，参阅
[Ephemeral Inline CSI volumes KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md)。
- 本特性下一步开发的更多信息，参阅
[enhancement tracking issue #596](https://github.com/kubernetes/enhancements/issues/596)。
<!--
### Generic ephemeral volumes
@ -458,5 +460,8 @@ See [local ephemeral storage](/docs/concepts/configuration/manage-resources-cont
- For more information on further development of this feature, see the [enhancement tracking issue #1698](https://github.com/kubernetes/enhancements/issues/1698).
-->
### 通用临时卷 {#generic-ephemeral-volumes}
- 有关设计的更多信息，参阅 [Generic ephemeral inline volumes KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md)。
- 本特性下一步开发的更多信息，参阅 [enhancement tracking issue #1698](https://github.com/kubernetes/enhancements/issues/1698).
- 有关设计的更多信息，参阅
[Generic ephemeral inline volumes KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md)。
- 本特性下一步开发的更多信息，参阅
[enhancement tracking issue #1698](https://github.com/kubernetes/enhancements/issues/1698).

62
content/zh/docs/concepts/storage/persistent-volumes.md
View File

@ -370,6 +370,68 @@ However, the particular path specified in the custom recycler Pod template in th
定制回收器 Pod 模板中在 `volumes` 部分所指定的特定路径要替换为
正被回收的卷的路径。
<!--
### Reserving a PersistentVolume
The control plane can [bind PersistentVolumeClaims to matching PersistentVolumes](#binding) in the
cluster. However, if you want a PVC to bind to a specific PV, you need to pre-bind them.
-->
### 预留 PersistentVolume {#reserving-a-persistentvolume}
通过在 PersistentVolumeClaim 中指定 PersistentVolume，你可以声明该特定
PV 与 PVC 之间的绑定关系。如果该 PersistentVolume 存在且未被通过其
`claimRef` 字段预留给 PersistentVolumeClaim，则该 PersistentVolume
会和该 PersistentVolumeClaim 绑定到一起。
<!--
The binding happens regardless of some volume matching criteria, including node affinity.
The control plane still checks that [storage class](/docs/concepts/storage/storage-classes/), access modes, and requested storage size are valid.
-->
绑定操作不会考虑某些卷匹配条件是否满足，包括节点亲和性等等。
控制面仍然会检查
[存储类](/zh/docs/concepts/storage/storage-classes/)、访问模式和所请求的
存储尺寸都是合法的。
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: foo-pvc
namespace: foo
spec:
storageClassName: "" # 此处须显式设置空字符串，否则会被设置为默认的 StorageClass
volumeName: foo-pv
...
```
<!--
This method does not guarantee any binding privileges to the PersistentVolume. If other PersistentVolumeClaims could use the PV that you specify, you first need to reserve that storage volume. Specify the relevant PersistentVolumeClaim in the `claimRef` field of the PV so that other PVCs can not bind to it.
-->
此方法无法对 PersistentVolume 的绑定特权做出任何形式的保证。
如果有其他 PersistentVolumeClaim 可以使用你所指定的 PV，则你应该首先预留
该存储卷。你可以将 PV 的 `claimRef` 字段设置为相关的 PersistentVolumeClaim
以确保其他 PVC 不会绑定到该 PV 卷。
```yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: foo-pv
spec:
storageClassName: ""
claimRef:
name: foo-pvc
namespace: foo
...
```
<!--
This is useful if you want to consume PersistentVolumes that have their `claimPolicy` set
to `Retain`, including cases where you are reusing an existing PV.
-->
如果你想要使用 `claimPolicy` 属性设置为 `Retain` 的 PersistentVolume 卷
时，包括你希望复用现有的 PV 卷时，这点是很有用的
<!--
### Expanding Persistent Volumes Claims
-->

309
content/zh/docs/concepts/storage/storage-classes.md
View File

@ -18,7 +18,7 @@ with [volumes](/docs/concepts/storage/volumes/) and
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
-->
本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和
[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。
[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。
<!-- body -->
@ -67,7 +67,7 @@ for details.
-->
管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ：
更多详情请参阅
[PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
```yaml
apiVersion: storage.k8s.io/v1
@ -90,15 +90,16 @@ volumeBindingMode: Immediate
Each StorageClass has a provisioner that determines what volume plugin is used
for provisioning PVs. This field must be specified.
-->
### 存储分配器
### 存储制备器 {#provisioner}
每个 StorageClass 都有一个分配器，用来决定使用哪个卷插件分配 PV。该字段必须指定。
每个 StorageClass 都有一个制备器（Provisioner），用来决定使用哪个卷插件制备 PV。
该字段必须指定。
<!--
| Volume Plugin | Internal Provisioner| Config Example |
-->
| 卷插件 | 内置分配器 | 配置例子 |
| 卷插件 | 内置制备器 | 配置例子 |
|:---------------------|:----------:|:-------------------------------------:|
| AWSElasticBlockStore | &#x2713; | [AWS EBS](#aws-ebs) |
| AzureFile | &#x2713; | [Azure File](#azure-file) |
@ -131,24 +132,25 @@ run, what volume plugin it uses (including Flex), etc. The repository
[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
houses a library for writing external provisioners that implements the bulk of
the specification. Some external provisioners are listed under the repository
[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).
[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner).
-->
您不限于指定此处列出的 "内置" 分配器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。
您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的
你不限于指定此处列出的 "内置" 制备器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。
你还可以运行和指定外部制备器，这些独立的程序遵循由 Kubernetes 定义的
[规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。
外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件（包括 Flex）等。
代码仓库 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
包含一个用于为外部分配器编写功能实现的类库。可以通过下面的代码仓库，查看外部分配器列表。
包含一个用于为外部制备器编写功能实现的类库。你可以访问代码仓库
[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
了解外部驱动列表。
[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).
<!--
For example, NFS doesn't provide an internal provisioner, but an external
provisioner can be used. There are also cases when 3rd party storage
vendors provide their own external provisioner.
-->
例如，NFS 没有内部分配器，但可以使用外部分配器。
也有第三方存储供应商提供自己的外部分配器。
例如，NFS 没有内部制备器，但可以使用外部制备器。
也有第三方存储供应商提供自己的外部制备器。
<!--
### Reclaim Policy
@ -228,7 +230,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
由 StorageClass 动态创建的 PersistentVolume 将使用类中 `mountOptions` 字段指定的挂载选项。
如果卷插件不支持挂载选项，却指定了该选项，则分配操作会失败。
如果卷插件不支持挂载选项，却指定了该选项，则制备操作会失败。
挂载选项在 StorageClass 和 PV 上都不会做验证，所以如果挂载选项无效，那么这个 PV 就会失败。
<!--
@ -240,7 +242,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
The `volumeBindingMode` field controls when [volume binding and dynamic
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
-->
`volumeBindingMode` 字段控制了[卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning)
`volumeBindingMode` 字段控制了[卷绑定和动态制备](/zh/docs/concepts/storage/persistent-volumes/#provisioning)
应该发生在什么时候。
<!--
@ -250,8 +252,9 @@ backends that are topology-constrained and not globally accessible from all Node
in the cluster, PersistentVolumes will be bound or provisioned without knowledge of the Pod's scheduling
requirements. This may result in unschedulable Pods.
-->
默认情况下，`Immediate` 模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态分配。
对于由于拓扑限制而非集群所有节点可达的存储后端，PersistentVolume 会在不知道 Pod 调度要求的情况下绑定或者分配。
默认情况下，`Immediate` 模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态制备。
对于由于拓扑限制而非集群所有节点可达的存储后端，PersistentVolume
会在不知道 Pod 调度要求的情况下绑定或者制备。
<!--
A cluster administrator can address this issue by specifying the `WaitForFirstConsumer` mode which
@ -265,8 +268,8 @@ anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-a
and [taints and tolerations](/docs/concepts/configuration/taint-and-toleration).
-->
集群管理员可以通过指定 `WaitForFirstConsumer` 模式来解决此问题。
该模式将延迟 PersistentVolume 的绑定和分配，直到使用该 PersistentVolumeClaim 的 Pod 被创建。
PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于
该模式将延迟 PersistentVolume 的绑定和制备，直到使用该 PersistentVolumeClaim 的 Pod 被创建。
PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或制备。这些包括但不限于
[资源需求](/zh/docs/concepts/configuration/manage-resources-containers/)、
[节点筛选器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)、
[pod 亲和性和互斥性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)、
@ -279,7 +282,7 @@ The following plugins support `WaitForFirstConsumer` with dynamic provisioning:
* [GCEPersistentDisk](#gce-pd)
* [AzureDisk](#azure-disk)
-->
以下插件支持动态分配的 `WaitForFirstConsumer` 模式:
以下插件支持动态供应的 `WaitForFirstConsumer` 模式:
* [AWSElasticBlockStore](#aws-ebs)
* [GCEPersistentDisk](#gce-pd)
@ -304,7 +307,7 @@ and pre-created PVs, but you'll need to look at the documentation for a specific
to see its supported topology keys and examples.
-->
动态配置和预先创建的 PV 也支持 [CSI卷](/zh/docs/concepts/storage/volumes/#csi)，
但是您需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。
但是你需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。
<!--
### Allowed Topologies
@ -317,7 +320,8 @@ When a cluster operator specifies the `WaitForFirstConsumer` volume binding mode
to restrict provisioning to specific topologies in most situations. However,
if still required, `allowedTopologies` can be specified.
-->
当集群操作人员使用了 `WaitForFirstConsumer` 的卷绑定模式，在大部分情况下就没有必要将配置限制为特定的拓扑结构。
当集群操作人员使用了 `WaitForFirstConsumer` 的卷绑定模式，
在大部分情况下就没有必要将制备限制为特定的拓扑结构。
然而，如果还有需要的话，可以使用 `allowedTopologies`。
<!--
@ -325,7 +329,8 @@ This example demonstrates how to restrict the topology of provisioned volumes to
zones and should be used as a replacement for the `zone` and `zones` parameters for the
supported plugins.
-->
这个例子描述了如何将分配卷的拓扑限制在特定的区域，在使用时应该根据插件支持情况替换 `zone` 和 `zones` 参数。
这个例子描述了如何将供应卷的拓扑限制在特定的区域，在使用时应该根据插件
支持情况替换 `zone` 和 `zones` 参数。
```yaml
apiVersion: storage.k8s.io/v1
@ -359,10 +364,12 @@ exceed 256 KiB.
-->
## 参数
Storage class 具有描述属于卷的参数。取决于分配器，可以接受不同的参数。
例如，参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。当参数被省略时，会使用默认值。
Storage class 具有描述属于卷的参数。取决于制备器，可以接受不同的参数。
例如，参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。
当参数被省略时，会使用默认值。
一个 StorageClass 最多可以定义 512 个参数。这些参数对象的总长度不能超过 256 KiB, 包括参数的键和值。
一个 StorageClass 最多可以定义 512 个参数。这些参数对象的总长度不能
超过 256 KiB, 包括参数的键和值。
### AWS EBS
@ -405,9 +412,11 @@ parameters:
* `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见
[AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。
* `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`，
通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。
通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。
`zone` 和 `zones` 参数不能同时使用。
* `zones`(弃用)：以逗号分隔的 AWS 区域列表。
如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。
如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的
活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。
* `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。
AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量，
并将其限制在 20000 IOPS（AWS 支持的最高值，请参阅
@ -465,7 +474,7 @@ parameters:
<!--
If `replication-type` is set to `none`, a regular (zonal) PD will be provisioned.
-->
如果 `replication-type` 设置为 `none`，会分配一个常规（当前区域内的）持久化磁盘。
如果 `replication-type` 设置为 `none`，会制备一个常规（当前区域内的）持久化磁盘。
<!--
If `replication-type` is set to `regional-pd`, a
@ -477,10 +486,10 @@ specified, Kubernetes will arbitrarily choose among the specified zones. If the
`zones` parameter is omitted, Kubernetes will arbitrarily choose among zones
managed by the cluster.
-->
如果 `replication-type` 设置为 `regional-pd`，会分配一个
如果 `replication-type` 设置为 `regional-pd`，会制备一个
[区域性持久化磁盘（Regional Persistent Disk）](https://cloud.google.com/compute/docs/disks/#repds)。
在这种情况下，用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域（zone）。
如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里分配。
如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里制备。
如果指定了多于两个的区域，Kubernetes 会选择其中任意两个区域。
如果省略了 `zones` 参数，Kubernetes 会在集群管理的区域中任意选择。
@ -530,8 +539,8 @@ parameters:
for authentication to the REST server. This parameter is deprecated in favor
of `secretNamespace` + `secretName`.
-->
* `resturl`：分配 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。
通用格式应该是 `IPaddress:Port`，这是 GlusterFS 动态分配器的必需参数。
* `resturl`：制备 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。
通用格式应该是 `IPaddress:Port`，这是 GlusterFS 动态制备器的必需参数。
如果 Heketi 服务在 OpenShift/kubernetes 中安装并暴露为可路由服务，则可以使用类似于
`http://heketi-storage-project.cloudapps.mystorage.com` 的格式，其中 fqdn 是可解析的 heketi 服务网址。
* `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。
@ -557,7 +566,8 @@ parameters:
Example of a secret can be found in
[glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
-->
* `secretNamespace`，`secretName`：Secret 实例的标识，包含与 Gluster REST 服务交互时使用的用户密码。
* `secretNamespace`，`secretName`：Secret 实例的标识，包含与 Gluster
REST 服务交互时使用的用户密码。
这些参数是可选的，`secretNamespace` 和 `secretName` 都省略时使用空密码。
所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs"，例如以这种方式创建：
@ -581,12 +591,13 @@ parameters:
specified, the volume will be provisioned with a value between 2000-2147483647
which are defaults for gidMin and gidMax respectively.
-->
* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时，
* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当制备卷时，
Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如：
`"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`。这个是可选参数。
* `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。
在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。
如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。
在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态制备卷。这些是可选的值。
如果不指定，所制备的卷为一个 2000-2147483647 之间的值，这是 gidMin 和
gidMax 的默认值。
<!--
* `volumetype` : The volume type and its parameters can be configured with this
@ -609,18 +620,22 @@ parameters:
`gluster-dynamic-<claimname>`. The dynamic endpoint and service are automatically
deleted when the persistent volume claim is deleted.
-->
* `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则由分配器决定卷的类型。
例如：
* `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则
由制备器决定卷的类型。
例如：
* 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量.
* 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量.
* 'Distribute volume': `volumetype: none`
* 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量.
* 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量.
* 'Distribute volume': `volumetype: none`
有关可用的卷类型和管理选项，请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。
有关可用的卷类型和管理选项，请参阅
[管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。
更多相关的参考信息，请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。
更多相关的参考信息，请参阅
[如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。
当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。
当动态制备持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>`
的端点和无头服务。在 PVC 被删除时动态端点和无头服务会自动被删除。
### OpenStack Cinder
@ -638,7 +653,8 @@ parameters:
* `availability`: Availability Zone. If not specified, volumes are generally
round-robin-ed across all active zones where Kubernetes cluster has a node.
-->
* `availability`：可用区域。如果没有指定，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。
* `availability`：可用区域。如果没有指定，通常卷会在 Kubernetes 集群节点
所在的活动区域中轮转调度。
<!--
{{< note >}}
@ -648,7 +664,8 @@ This internal provisioner of OpenStack is deprecated. Please use [the external c
-->
{{< note >}}
{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部驱动程序](https://github.com/kubernetes/cloud-provider-openstack)。
OpenStack 的内部驱动已经被弃用。请使用
[OpenStack 的外部云驱动](https://github.com/kubernetes/cloud-provider-openstack)。
{{< /note >}}
### vSphere
@ -658,108 +675,107 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部
-->
1. 使用用户指定的磁盘格式创建一个 StorageClass。
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
diskformat: zeroedthick
```
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
diskformat: zeroedthick
```
<!--
`diskformat`: `thin`, `zeroedthick` and `eagerzeroedthick`. Default: `"thin"`.
-->
`diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。
<!--
`diskformat`: `thin`, `zeroedthick` and `eagerzeroedthick`. Default: `"thin"`.
-->
`diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。
<!--
2. Create a StorageClass with a disk format on a user specified datastore.
-->
2. 在用户指定的数据存储上创建磁盘格式的 StorageClass。
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
diskformat: zeroedthick
datastore: VSANDatastore
```
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
diskformat: zeroedthick
datastore: VSANDatastore
```
<!--
`datastore`: The user can also specify the datastore in the StorageClass.
The volume will be created on the datastore specified in the storage class,
which in this case is `VSANDatastore`. This field is optional. If the
datastore is not specified, then the volume will be created on the datastore
specified in the vSphere config file used to initialize the vSphere Cloud
Provider.
-->
<!--
`datastore`: The user can also specify the datastore in the StorageClass.
The volume will be created on the datastore specified in the storage class,
which in this case is `VSANDatastore`. This field is optional. If the
datastore is not specified, then the volume will be created on the datastore
specified in the vSphere config file used to initialize the vSphere Cloud
Provider.
-->
`datastore`：用户也可以在 StorageClass 中指定数据存储。
卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。
该字段是可选的。
如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere
配置文件中指定的数据存储上创建该卷。
`datastore`：用户也可以在 StorageClass 中指定数据存储。
卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。
该字段是可选的。
如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere
配置文件中指定的数据存储上创建该卷。
<!--
3. Storage Policy Management inside kubernetes
-->
3. Kubernetes 中的存储策略管理
<!--
* Using existing vCenter SPBM policy
<!--
* Using existing vCenter SPBM policy
One of the most important features of vSphere for Storage Management is
policy based Management. Storage Policy Based Management (SPBM) is a
storage policy framework that provides a single unified control plane
across a broad range of data services and storage solutions. SPBM enables
vSphere administrators to overcome upfront storage provisioning challenges,
such as capacity planning, differentiated service levels and managing
capacity headroom.
One of the most important features of vSphere for Storage Management is
policy based Management. Storage Policy Based Management (SPBM) is a
storage policy framework that provides a single unified control plane
across a broad range of data services and storage solutions. SPBM enables
vSphere administrators to overcome upfront storage provisioning challenges,
such as capacity planning, differentiated service levels and managing
capacity headroom.
The SPBM policies can be specified in the StorageClass using the
`storagePolicyName` parameter.
The SPBM policies can be specified in the StorageClass using the
`storagePolicyName` parameter.
-->
* 使用现有的 vCenter SPBM 策略
vSphere 用于存储管理的最重要特性之一是基于策略的管理。
基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的
跨越广泛的数据服务和存储解决方案。
SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。
vSphere 用于存储管理的最重要特性之一是基于策略的管理。
基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的
跨越广泛的数据服务和存储解决方案。
SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。
SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。
SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。
<!--
* Virtual SAN policy support inside Kubernetes
Vsphere Infrastructure (VI) Admins will have the ability to specify custom
Virtual SAN Storage Capabilities during dynamic volume provisioning. You
can now define storage requirements, such as performance and availability,
in the form of storage capabilities during dynamic volume provisioning.
The storage capability requirements are converted into a Virtual SAN
policy which are then pushed down to the Virtual SAN layer when a
persistent volume (virtual disk) is being created. The virtual disk is
distributed across the Virtual SAN datastore to meet the requirements.
Vsphere Infrastructure (VI) Admins will have the ability to specify custom
Virtual SAN Storage Capabilities during dynamic volume provisioning. You
can now define storage requirements, such as performance and availability,
in the form of storage capabilities during dynamic volume provisioning.
The storage capability requirements are converted into a Virtual SAN
policy which are then pushed down to the Virtual SAN layer when a
persistent volume (virtual disk) is being created. The virtual disk is
distributed across the Virtual SAN datastore to meet the requirements.
You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)
for more details on how to use storage policies for persistent volumes
management.
You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)
for more details on how to use storage policies for persistent volumes
management.
-->
* Kubernetes 内的 Virtual SAN 策略支持
Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN
存储功能。您现在可以定义存储需求，例如性能和可用性，当动态卷供分配时会以存储功能的形式提供。
存储功能需求会转换为 Virtual SAN 策略，然后当持久卷（虚拟磁盘）在创建时，
会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。
Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN
存储功能。你现在可以在动态制备卷期间以存储能力的形式定义存储需求，例如性能和可用性。
存储能力需求会转换为 Virtual SAN 策略，之后当持久卷（虚拟磁盘）被创建时，
会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。
更多有关 persistent volume 管理的存储策略的详细信息，
您可以参考 [基于存储策略的动态分配卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)。
你可以参考[基于存储策略的动态制备卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)，
进一步了解有关持久卷管理的存储策略的详细信息。
<!--
There are few
@ -767,7 +783,7 @@ There are few
which you try out for persistent volume management inside Kubernetes for vSphere.
-->
有几个 [vSphere 例子](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)
供您在 Kubernetes for vSphere 中尝试进行 persistent volume 管理。
供你在 Kubernetes for vSphere 中尝试进行持久卷管理。
### Ceph RBD
@ -882,7 +898,7 @@ parameters:
* `registry`：用于挂载卷的 Quobyte registry。你可以指定 registry 为 ``<host>:<port>``
或者如果你想指定多个 registry，你只需要在他们之间添加逗号，例如
``<host1>:<port>,<host2>:<port>,<host3>:<port>``。
主机可以是一个 IP 地址，或者如果您有正在运行的 DNS，您也可以提供 DNS 名称。
主机可以是一个 IP 地址，或者如果你有正在运行的 DNS，你也可以提供 DNS 名称。
* `adminSecretNamespace`：`adminSecretName`的 namespace。
默认值是 "default"。
@ -920,7 +936,7 @@ parameters:
-->
* `user`：对这个用户映射的所有访问权限。默认是 "root"。
* `group`：对这个组映射的所有访问权限。默认是 "nfsnobody"。
* `quobyteConfig`：使用指定的配置来创建卷。您可以创建一个新的配置，或者，可以修改 Web console 或
* `quobyteConfig`：使用指定的配置来创建卷。你可以创建一个新的配置，或者，可以修改 Web console 或
quobyte CLI 中现有的配置。默认是 "BASE"。
* `quobyteTenant`：使用指定的租户 ID 创建/删除卷。这个 Quobyte 租户必须已经于 Quobyte。
默认是 "DEFAULT"。
@ -1053,17 +1069,19 @@ mounting credentials. If the cluster has enabled both
add the `create` permission of resource `secret` for clusterrole
`system:controller:persistent-volume-binder`.
-->
在存储分配期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了
[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和 [控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)，
为 `system:controller:persistent-volume-binder` 的 clusterrole 添加 `secret` 资源的 `create` 权限。
在存储制备期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了
[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和
[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)，
为 `system:controller:persistent-volume-binder` 的 clusterrole 添加
`Secret` 资源的 `create` 权限。
<!--
In a multi-tenancy context, it is strongly recommended to set the value for
`secretNamespace` explicitly, otherwise the storage account credentials may
be read by other users.
-->
在多租户上下文中，强烈建议显式设置 `secretNamespace` 的值，否则其他用户可能会读取存储帐户凭据。
在多租户上下文中，强烈建议显式设置 `secretNamespace` 的值，否则
其他用户可能会读取存储帐户凭据。
<!--
### Portworx Volume
@ -1108,14 +1126,19 @@ parameters:
* `block_size`：以 Kbytes 为单位的块大小（默认值：`32`）。
* `repl`：同步副本数量，以复制因子 `1..3`（默认值：`1`）的形式提供。
这里需要填写字符串，即，`"1"` 而不是 `1`。
* `io_priority`：决定是否从更高性能或者较低优先级存储创建卷 `high/medium/low`（默认值：`low`）。
* `snap_interval`：触发快照的时钟/时间间隔（分钟）。快照是基于与先前快照的增量变化，0 是禁用快照（默认：`0`）。
* `io_priority`：决定是否从更高性能或者较低优先级存储创建卷
`high/medium/low`（默认值：`low`）。
* `snap_interval`：触发快照的时钟/时间间隔（分钟）。
快照是基于与先前快照的增量变化，0 是禁用快照（默认：`0`）。
这里需要填写字符串，即，是 `"70"` 而不是 `70`。
* `aggregation_level`：指定卷分配到的块数量，0 表示一个非聚合卷（默认：`0`）。
这里需要填写字符串，即，是 `"0"` 而不是 `0`。
* `ephemeral`：指定卷在卸载后进行清理还是持久化。 `emptyDir` 的使用场景可以将这个值设置为 true ，
`persistent volumes` 的使用场景可以将这个值设置为 false（例如 Cassandra 这样的数据库）
`true/false`（默认为 `false`）。这里需要填写字符串，即，是 `"true"` 而不是 `true`。
* `ephemeral`：指定卷在卸载后进行清理还是持久化。
`emptyDir` 的使用场景可以将这个值设置为 true ，
`persistent volumes` 的使用场景可以将这个值设置为 false
（例如 Cassandra 这样的数据库）
`true/false`（默认为 `false`）。这里需要填写字符串，即，
是 `"true"` 而不是 `true`。
### ScaleIO
@ -1171,8 +1194,8 @@ kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \
```
-->
ScaleIO Kubernetes 卷插件需要配置一个 Secret 对象。
secret 必须用 `kubernetes.io/scaleio` 类型创建，并与引用它的 PVC 所属的名称空间使用相同的值
如下面的命令所示：
Secret 必须用 `kubernetes.io/scaleio` 类型创建，并与引用它的
PVC 所属的名称空间使用相同的值。如下面的命令所示：
```shell
kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \
@ -1210,13 +1233,17 @@ parameters:
* `adminSecretName`: The name of the secret to use for obtaining the StorageOS
API credentials. If not specified, default values will be attempted.
-->
* `pool`：分配卷的 StorageOS 分布式容量池的名称。如果未指定，则使用通常存在的 `default` 池。
* `description`：分配给动态创建的卷的描述。所有卷描述对于 storage class 都是相同的，
* `pool`：制备卷的 StorageOS 分布式容量池的名称。如果未指定，则使用
通常存在的 `default` 池。
* `description`：指定给动态创建的卷的描述。所有卷描述对于存储类而言都是相同的，
但不同的 storage class 可以使用不同的描述，以区分不同的使用场景。
默认为 `Kubernetas volume`。
* `fsType`：请求的默认文件系统类型。请注意，在 StorageOS 中用户定义的规则可以覆盖此值。默认为 `ext4`
* `adminSecretNamespace`：API 配置 secret 所在的命名空间。如果设置了 adminSecretName，则是必需的。
* `adminSecretName`：用于获取 StorageOS API 凭证的 secret 名称。如果未指定，则将尝试默认值。
* `fsType`：请求的默认文件系统类型。
请注意，在 StorageOS 中用户定义的规则可以覆盖此值。默认为 `ext4`
* `adminSecretNamespace`：API 配置 secret 所在的命名空间。
如果设置了 adminSecretName，则是必需的。
* `adminSecretName`：用于获取 StorageOS API 凭证的 secret 名称。
如果未指定，则将尝试默认值。
<!--
The StorageOS Kubernetes volume plugin can use a Secret object to specify an
@ -1253,7 +1280,8 @@ and referenced with the `adminSecretNamespace` parameter. Secrets used by
pre-provisioned volumes must be created in the same namespace as the PVC that
references it.
-->
用于动态分配卷的 Secret 可以在任何名称空间中创建，并通过 `adminSecretNamespace` 参数引用。
用于动态制备卷的 Secret 可以在任何名称空间中创建，并通过
`adminSecretNamespace` 参数引用。
预先配置的卷使用的 Secret 必须在与引用它的 PVC 在相同的名称空间中。
<!--
@ -1277,13 +1305,14 @@ Local volumes do not currently support dynamic provisioning, however a StorageCl
should still be created to delay volume binding until pod scheduling. This is
specified by the `WaitForFirstConsumer` volume binding mode.
-->
本地卷还不支持动态分配，然而还是需要创建 StorageClass 以延迟卷绑定，直到完成 pod 的调度。这是由 `WaitForFirstConsumer` 卷绑定模式指定的。
本地卷还不支持动态制备，然而还是需要创建 StorageClass 以延迟卷绑定，
直到完成 Pod 的调度。这是由 `WaitForFirstConsumer` 卷绑定模式指定的。
<!--
Delaying volume binding allows the scheduler to consider all of a pod's
scheduling constraints when choosing an appropriate PersistentVolume for a
PersistentVolumeClaim.
-->
延迟卷绑定使得调度器在为 PersistentVolumeClaim 选择一个合适的 PersistentVolume 时能考虑到所有 pod 的调度限制。
延迟卷绑定使得调度器在为 PersistentVolumeClaim 选择一个合适的
PersistentVolume 时能考虑到所有 Pod 的调度限制。

76
content/zh/docs/concepts/storage/volume-snapshot-classes.md
View File

@ -7,13 +7,13 @@ weight: 30
<!-- overview -->
<!--
This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity
This document describes the concept of VolumeSnapshotClass in Kubernetes. Familiarity
with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
[storage classes](/docs/concepts/storage/storage-classes) is suggested.
-->
本文档描述了 Kubernetes 中 `VolumeSnapshotClass` 的概念。 建议熟悉[卷快照（Volume Snapshots）](/docs/concepts/storage/volume-snapshots/)和[存储类（Storage Class）](/docs/concepts/storage/storage-classes)。
本文档描述了 Kubernetes 中 VolumeSnapshotClass 的概念。建议熟悉
[卷快照（Volume Snapshots）](/zh/docs/concepts/storage/volume-snapshots/)和
[存储类（Storage Class）](/zh/docs/concepts/storage/storage-classes)。
<!-- body -->
@ -21,37 +21,35 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
<!--
## Introduction
Just like `StorageClass` provides a way for administrators to describe the "classes"
of storage they offer when provisioning a volume, `VolumeSnapshotClass` provides a
Just like StorageClass provides a way for administrators to describe the "classes"
of storage they offer when provisioning a volume, VolumeSnapshotClass provides a
way to describe the "classes" of storage when provisioning a volume snapshot.
-->
## 介绍 {#introduction}
就像 `StorageClass` 为管理员提供了一种在配置卷时描述存储“类”的方法，`VolumeSnapshotClass` 提供了一种在配置卷快照时描述存储“类”的方法。
就像 StorageClass 为管理员提供了一种在配置卷时描述存储“类”的方法，
VolumeSnapshotClass 提供了一种在配置卷快照时描述存储“类”的方法。
<!--
## The VolumeSnapshotClass Resource
Each `VolumeSnapshotClass` contains the fields `driver`, `deletionPolicy`, and `parameters`,
which are used when a `VolumeSnapshot` belonging to the class needs to be
Each VolumeSnapshotClass contains the fields `driver`, `deletionPolicy`, and `parameters`,
which are used when a VolumeSnapshot belonging to the class needs to be
dynamically provisioned.
The name of a `VolumeSnapshotClass` object is significant, and is how users can
The name of a VolumeSnapshotClass object is significant, and is how users can
request a particular class. Administrators set the name and other parameters
of a class when first creating `VolumeSnapshotClass` objects, and the objects cannot
of a class when first creating VolumeSnapshotClass objects, and the objects cannot
be updated once they are created.
Administrators can specify a default `VolumeSnapshotClass` just for VolumeSnapshots
that don't request any particular class to bind to.
-->
## VolumeSnapshotClass 资源
## VolumeSnapshotClass 资源 {#the-volumesnapshortclass-resource}
每个 `VolumeSnapshotClass` 都包含 `driver` 、`deletionPolicy` 和 `parameters` 字段，当需要动态配置属于该类的 `VolumeSnapshot` 时使用。
每个 VolumeSnapshotClass 都包含 `driver`、`deletionPolicy` 和 `parameters` 字段，
在需要动态配置属于该类的 VolumeSnapshot 时使用。
`VolumeSnapshotClass` 对象的名称很重要，是用户可以请求特定类的方式。
管理员在首次创建 `VolumeSnapshotClass` 对象时设置类的名称和其他参数，对象一旦创建就无法更新。
管理员可以为不请求任何特定类绑定的 VolumeSnapshots 指定默认的 `VolumeSnapshotClass`。
VolumeSnapshotClass 对象的名称很重要，是用户可以请求特定类的方式。
管理员在首次创建 VolumeSnapshotClass 对象时设置类的名称和其他参数，
对象一旦创建就无法更新。
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
@ -63,6 +61,26 @@ deletionPolicy: Delete
parameters:
```
<!--
Administrators can specify a default VolumeSnapshotClass for VolumeSnapshots
that don't request any particular class to bind to by adding the
`snapshot.storage.kubernetes.io/is-default-class: "true"` annotation:
-->
管理员可以为未请求任何特定类绑定的 VolumeSnapshots 指定默认的 VolumeSnapshotClass，
方法是设置注解 `snapshot.storage.kubernetes.io/is-default-class: "true"`：
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotClass
metadata:
name: csi-hostpath-snapclass
annotations:
snapshot.storage.kubernetes.io/is-default-class: "true"
driver: hostpath.csi.k8s.io
deletionPolicy: Delete
parameters:
```
<!--
### Driver
@ -71,20 +89,25 @@ used for provisioning VolumeSnapshots. This field must be specified.
-->
### 驱动程序 {#driver}
卷快照类有一个驱动程序，用于确定配置 VolumeSnapshot 的 CSI 卷插件。 必须指定此字段。
卷快照类有一个驱动程序，用于确定配置 VolumeSnapshot 的 CSI 卷插件。
此字段必须指定。
<!--
### DeletionPolicy
Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a `VolumeSnapshotContent` when the `VolumeSnapshot` object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified.
Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified.
If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the deletionPolicy is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain.
If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the deletionPolicy is `Retain`, then both the underlying snapshot and VolumeSnapshotContent remain.
-->
### 删除策略 {#deletion-policy}
卷快照类具有 `deletionPolicy` 属性。用户可以配置当所绑定的 `VolumeSnapshot` 对象将被删除时，如何处理 `VolumeSnapshotContent` 对象。卷快照的这个策略可以是 `Retain` 或者 `Delete`。这个策略字段必须指定。
卷快照类具有 `deletionPolicy` 属性。用户可以配置当所绑定的 VolumeSnapshot
对象将被删除时，如何处理 VolumeSnapshotContent 对象。
卷快照的这个策略可以是 `Retain` 或者 `Delete`。这个策略字段必须指定。
如果删除策略是 `Delete`，那么底层的存储快照会和 `VolumeSnapshotContent` 对象一起删除。如果删除策略是 `Retain`，那么底层快照和 `VolumeSnapshotContent` 对象都会被保留。
如果删除策略是 `Delete`，那么底层的存储快照会和 VolumeSnapshotContent 对象
一起删除。如果删除策略是 `Retain`，那么底层快照和 VolumeSnapshotContent
对象都会被保留。
<!--
## Parameters
@ -95,6 +118,5 @@ the volume snapshot class. Different parameters may be accepted depending on the
-->
## 参数 {#parameters}
卷快照类具有描述属于该卷快照类的卷快照的参数。 可根据 `driver` 接受不同的参数。
卷快照类具有描述属于该卷快照类的卷快照的参数，可根据 `driver` 接受不同的参数。

19
content/zh/docs/concepts/storage/volume-snapshots.md
View File

@ -18,7 +18,7 @@ weight: 20
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
-->
在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
的 [持久卷](/docs/concepts/storage/persistent-volumes/)。
的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。
<!-- body -->
@ -48,6 +48,13 @@ A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is simila
-->
`VolumeSnapshotClass` 允许指定属于 `VolumeSnapshot` 的不同属性。在从存储系统的相同卷上获取的快照之间，这些属性可能有所不同，因此不能通过使用与 `PersistentVolumeClaim` 相同的 `StorageClass` 来表示。
<!--
Volume snapshots provide Kubernetes users with a standardized way to copy a volume's contents at a particular point in time without creating an entirely new volume. This functionality enables, for example, database administrators to backup databases before performing edit or delete modifications.
-->
卷快照能力为 Kubernetes 用户提供了一种标准的方式来在指定时间点
复制卷的内容，并且不需要创建全新的卷。例如，这一功能使得数据库管理员
能够在执行编辑或删除之类的修改之前对数据库执行备份。
<!--
Users need to be aware of the following when using this feature:
-->
@ -171,7 +178,8 @@ A volume snapshot can request a particular class by specifying the name of a
[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
using the attribute `volumeSnapshotClassName`. If nothing is set, then the default class is used if available.
-->
`persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。这个字段是动态配置快照中的必填字段。
`persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。
这个字段是动态配置快照中的必填字段。
卷快照可以通过指定 [VolumeSnapshotClass](/zh/docs/concepts/storage/volume-snapshot-classes/)
使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
@ -182,14 +190,14 @@ For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName`
如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。
对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。
```
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
name: test-snapshot
spec:
source:
volumeSnapshotContentName: test-content
volumeSnapshotContentName: test-content
```
<!--
@ -260,5 +268,6 @@ the *dataSource* field in the `PersistentVolumeClaim` object.
For more details, see
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
-->
更多详细信息，请参阅 [卷快照和从快照还原卷](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
更多详细信息，请参阅
[卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。