[zh] Fix links in zh localization (3)

2020-12-04 16:05:40 +08:00
parent 9c696a5883
commit b9e8fb699e
22 changed files with 514 additions and 352 deletions
@@ -26,10 +26,9 @@ such as your desktop machine.
 -->
 ## 访问集群上运行的服务

-
-在 Kubernetes 里，[Node](/zh/docs/concepts/architecture/nodes/)、
+在 Kubernetes 里，[节点](/zh/docs/concepts/architecture/nodes/)、
 [Pod](/zh/docs/concepts/workloads/pods/) 和
-[Service](/zh/docs/concepts/services-networking/services/) 都有自己的 IP。
+[服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。
 许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 是路由不可达的，
 所以不能从集群之外访问它们，例如从你自己的台式机。

@@ -57,7 +56,7 @@ You have several options for connecting to nodes, pods and services from outside
 -->
 - 通过公网 IP 访问服务
  - 使用类型为 `NodePort` 或 `LoadBalancer` 的服务，可以从外部访问它们。
-    请查阅[服务](/zh/docs/concepts/services-networking/services/) 和
+    请查阅[服务](/zh/docs/concepts/services-networking/service/) 和
    [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
  - 取决于你的集群环境，你可以仅把服务暴露在你的企业网络环境中，也可以将其暴露在
    因特网上。需要考虑暴露的服务是否安全，它是否有自己的用户认证？
@@ -134,13 +133,16 @@ at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-l
 -->
 这一输出显示了用 proxy 动词访问每个服务时可用的 URL。例如，此集群
 （使用 Elasticsearch）启用了集群层面的日志。如果提供合适的凭据，可以通过
-`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 访问，或通过一个 `kubectl proxy` 来访问：`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。
+`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`
+访问，或通过一个 `kubectl proxy` 来访问：
+`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。

 <!--
 See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.
 -->
 {{< note >}}
-请参阅[使用 Kubernets API 访问集群](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)了解如何传递凭据或如何使用 `kubectl proxy`。
+请参阅[使用 Kubernets API 访问集群](/zh/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)
+了解如何传递凭据或如何使用 `kubectl proxy`。
 {{< /note >}}

 <!--
@@ -30,7 +30,8 @@ for details.

 取决于安装模式，你的 Kubernetes 集群可能和一个被标记为默认的已有 StorageClass 一起部署。
 这个默认的 StorageClass 以后将被用于动态的为没有特定存储类需求的 PersistentVolumeClaims 
-配置存储。更多细节请查看 [PersistentVolumeClaim 文档](/zh/docs/user-guide/persistent-volumes/#class-1)。
+配置存储。更多细节请查看
+[PersistentVolumeClaim 文档](/zh/docs/concepts/storage/persistent-volumes/#perspersistentvolumeclaims)。

 <!--
 The pre-installed default StorageClass may not fit well with your expected workload;
@@ -138,7 +139,7 @@ for details about addon manager and how to disable individual addons.
   -->
   输出类似这样：

-   ```bash
+   ```
   NAME             PROVISIONER               AGE
   standard         kubernetes.io/gce-pd      1d
   gold (default)   kubernetes.io/gce-pd      1d
@@ -149,5 +150,5 @@ for details about addon manager and how to disable individual addons.
 <!--
 * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
 -->
-* 进一步了解 [StorageClasses](/docs/concepts/storage/persistent-volumes/)
+* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)

@@ -2,7 +2,9 @@
 title: 更改 PersistentVolume 的回收策略
 content_type: task
 ---
+
 <!-- overview -->
+
 <!--
 This page shows how to change the reclaim policy of a Kubernetes
 PersistentVolume.
@@ -131,8 +133,8 @@ PersistentVolumes 可以有多种回收策略，包括 "Retain"、"Recycle" 和
 * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
 * Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
 -->
-* 进一步了解 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
-* 进一步了解 [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
+* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)
+* 进一步了解 [PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)

 ### 参考

@@ -1,53 +1,40 @@
 ---
-reviewers:
- jszczepkowski
-translaters:
- Coffey Gao
 title: 搭建高可用的 Kubernetes Masters
 content_type: task
 ---

 <!--
---
 reviewers:
 - jszczepkowski
 title: Set up High-Availability Kubernetes Masters
 content_type: task
---
 -->

-
 <!-- overview -->

 {{< feature-state for_k8s_version="1.5" state="alpha" >}}
+
 <!--
 You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
 This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.
 -->
-
-您可以在谷歌计算引擎（GCE）的 `kubeup` 或 `kube-down` 脚本中复制 Kubernetes Master。
-本文描述了如何使用 kube-up/down 脚本来管理高可用（HA）的 Master，以及如何使用 GCE 实现高可用 Master。
-
-
-
+你可以在谷歌计算引擎（GCE）的 `kubeup` 或 `kube-down` 脚本中复制 Kubernetes Master。
+本文描述了如何使用 kube-up/down 脚本来管理高可用（HA）的 Master，
+以及如何使用 GCE 实现高可用控制节点。

 ## {{% heading "prerequisites" %}}

-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

-
-
 <!-- steps -->
 <!--
 ## Starting an HA-compatible cluster

 To create a new HA-compatible cluster, you must set the following flags in your `kube-up` script:
 -->
-
 ## 启动一个兼容高可用的集群

-要创建一个新的兼容高可用的集群，您必须在 `kubeup` 脚本中设置以下标志:
+要创建一个新的兼容高可用的集群，你必须在 `kubeup` 脚本中设置以下标志:

 <!--
 * `MULTIZONE=true` - to prevent removal of master replicas kubelets from zones different than server's default zone.
@@ -71,13 +58,16 @@ MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./clu
 Note that the commands above create a cluster with one master;
 however, you can add new master replicas to the cluster with subsequent commands.
 -->
-* `MULTIZONE=true` - 为了防止从不同于 Master 默认区域的区域中删除 kubelets 副本。如果您希望在不同的区域运行 Master 副本，那么这一项是必需并且推荐的。
+* `MULTIZONE=true` - 为了防止从不同于服务器的默认区域的区域中删除 kubelets 副本。
+  如果你希望在不同的区域运行副本，那么这一项是必需并且推荐的。

-* `ENABLE_ETCD_QUORUM_READ=true` - 确保从所有 API 服务器读取数据时将返回最新的数据。如果为 true，读操作将被定向到 leader etcd 副本。可以选择将这个值设置为 true，那么读取将更可靠，但也会更慢。
+* `ENABLE_ETCD_QUORUM_READ=true` - 确保从所有 API 服务器读取数据时将返回最新的数据。
+  如果为 true，读操作将被定向到主 etcd 副本。可以选择将这个值设置为 true，
+  那么读取将更可靠，但也会更慢。

-您还可以指定一个 GCE 区域，在这里创建第一个 Master 副本。设置以下标志:
+你还可以指定一个 GCE 区域，在这里创建第一个主节点副本。设置以下标志:

-* `KUBE_GCE_ZONE=zone` - 将运行第一个 Master 副本的区域。
+* `KUBE_GCE_ZONE=zone` - 将运行第一个主节点副本的区域。

 下面的命令演示在 GCE  europe-west1-b 区域中设置一个兼容高可用的集群:

@@ -85,8 +75,8 @@ however, you can add new master replicas to the cluster with subsequent commands
 MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
 ```

-注意，上面的命令创建一个只有单一 Master 的集群;
-但是，您可以使用后续命令将新的 Master 副本添加到集群中。
+注意，上面的命令创建一个只有单一主节点的集群;
+但是，你可以使用后续命令将新的主节点副本添加到集群中。

 <!--
 ## Adding a new master replica
@@ -109,17 +99,16 @@ The following sample command replicates the master on an existing HA-compatible
 KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
 ```
 -->
+## 增加一个新的主节点副本

-## 增加一个新的 Master 副本
+在创建了兼容高可用的集群之后，可以向其中添加主节点副本。
+你可以使用带有如下标记的 `kubeup` 脚本添加主节点副本:

-在创建了兼容高可用的集群之后，可以向其中添加 Master 副本。
-您可以使用带有如下标记的 `kubeup` 脚本添加 Master 副本:
+* `KUBE_REPLICATE_EXISTING_MASTER=true` - 创建一个已经存在的主节点的副本。

-* `KUBE_REPLICATE_EXISTING_MASTER=true` - 创建一个已经存在的 Master 的副本。
+* `KUBE_GCE_ZONE=zone` -主节点副本将运行的区域。必须与其他副本位于同一区域。

-* `KUBE_GCE_ZONE=zone` - Master 副本将运行的区域。必须与其他副本位于同一区域。
-
-您无需设置 `MULTIZONE` 或 `ENABLE_ETCD_QUORUM_READS` 标志，因为他们可以从兼容高可用的集群中继承。
+你无需设置 `MULTIZONE` 或 `ENABLE_ETCD_QUORUM_READS` 标志，因为他们可以从兼容高可用的集群中继承。

 使用下面的命令可以复制现有兼容高可用的集群上的 Master:

@@ -144,16 +133,15 @@ The following sample command removes a master replica from an existing HA cluste
 KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
 ```
 -->
+## 删除主节点副本

-## 删除一个 Master 副本
-
-你可以使用一个 `kube-down` 脚本从高可用集群中删除一个 Master 副本，并可以使用以下标记:
+你可以使用一个 `kube-down` 脚本从高可用集群中删除一个主节点副本，并可以使用以下标记:

 * `KUBE_DELETE_NODES=false` - 限制删除 kubelets。

-* `KUBE_GCE_ZONE=zone` - 将移除 Master 副本的区域。
+* `KUBE_GCE_ZONE=zone` - 将移除主节点副本的区域。

-* `KUBE_REPLICA_NAME=replica_name` - （可选）要删除的 Master 副本的名称。
+* `KUBE_REPLICA_NAME=replica_name` - （可选）要删除的主节点副本的名称。
 如果为空：将删除给定区域中的所有副本。

 使用下面的命令可以从一个现有的高可用集群中删除一个 Master副本:
@@ -180,10 +168,10 @@ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_nam
 KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
 ```
 -->
+## 处理主节点副本失败

-## 处理 Master 副本失败
-
-如果高可用集群中的一个 Master 副本失败，最佳实践是从集群中删除副本，并在相同的区域中添加一个新副本。
+如果高可用集群中的一个主节点副本失败，最佳实践是从集群中删除副本，
+并在相同的区域中添加一个新副本。
 下面的命令演示了这个过程:

 1. 删除失败的副本:
@@ -214,19 +202,22 @@ This operation may be sped up by migrating etcd data directory, as described [he
 (we are considering adding support for etcd data dir migration in future).
 -->

-## 高可用集群复制 Master 的最佳实践
-
-* 尝试将 Master 副本放置在不同的区域。在某区域故障时，放置在该区域内的所有主机都将失败。
-为了在区域故障中幸免，请同样将工作节点放置在多区域中（详情请见[多区域](/docs/setup/best-practices/multiple-zones/)）。
-
-* 不要使用具有两个 Master 副本的集群。在双副本集群上达成一致需要在更改持久状态时两个副本都处于运行状态。因此，两个副本都是需要的，任一副本的失败都会将集群带入多数失败状态。因此，就高可用而言，双副本集群不如单个副本集群。
-
-* 添加 Master 副本时，集群状态（etcd）会被复制到一个新实例。如果集群很大，可能需要很长时间才能复制它的状态。
-这个操作可以通过迁移 etcd 数据存储来加速, 详情参见 [这里](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
-（我们正在考虑在未来添加对迁移 etcd 数据存储的支持）。
+## 高可用集群复制主节点的最佳实践

+* 尝试将主节点副本放置在不同的区域。在某区域故障时，放置在该区域内的所有主机都将失败。
+  为了在区域故障中幸免，请同样将工作节点放置在多区域中
+  （详情请见[多区域](/zh/docs/setup/best-practices/multiple-zones/)）。

+* 不要使用具有两个主节点副本的集群。在双副本集群上达成一致需要在更改持久状态时
+  两个副本都处于运行状态。
+  因此，两个副本都是需要的，任一副本的失败都会将集群带入多数失败状态。
+  因此，就高可用而言，双副本集群不如单个副本集群。

+* 添加主节点副本时，集群状态（etcd）会被复制到一个新实例。如果集群很大，
+  可能需要很长时间才能复制它的状态。
+  这个操作可以通过迁移 etcd 数据存储来加速, 详情参见
+  [这里](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
+  （我们正在考虑在未来添加对迁移 etcd 数据存储的支持）。

 <!-- discussion -->
 <!--
@@ -234,8 +225,7 @@ This operation may be sped up by migrating etcd data directory, as described [he

 ![ha-master-gce](/images/docs/ha-master-gce.png)
 -->
-
-## 实施注意事项
+## 实现说明

 ![ha-master-gce](/images/docs/ha-master-gce.png)

@@ -254,10 +244,9 @@ Each of master replicas will run the following components in the following mode:

 In addition, there will be a load balancer in front of API servers that will route external and internal traffic to them.
 -->
-
 ### 概述

-每个 Master 副本将以以下模式运行以下组件:
+每个主节点副本将以以下模式运行以下组件:

 * etcd 实例： 所有实例将会以共识方式组建集群；

@@ -265,7 +254,7 @@ In addition, there will be a load balancer in front of API servers that will rou

 * 控制器、调度器和集群自动扩缩器：将使用租约机制 —— 每个集群中只有一个实例是可用的；

-* add-on manager：每个管理器将独立工作，试图保持插件同步。
+* 插件管理器：每个管理器将独立工作，试图保持插件同步。

 此外，在 API 服务器前面将有一个负载均衡器，用于将外部和内部通信路由到他们。

@@ -277,15 +266,16 @@ and the IP address of the first replica will be promoted to IP address of load b
 Similarly, after removal of the penultimate master replica, the load balancer will be removed and its IP address will be assigned to the last remaining replica.
 Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate.
 -->
+### 负载均衡

-### 负载均衡器
-
-启动第二个 Master 副本时，将创建一个包含两个副本的负载均衡器，并将第一个副本的 IP 地址提升为负载均衡器的 IP 地址。
-类似地，在删除倒数第二个 Master 副本之后，将删除负载均衡器，并将其 IP 地址分配给最后一个剩余的副本。
+启动第二个主节点副本时，将创建一个包含两个副本的负载均衡器，
+并将第一个副本的 IP 地址提升为负载均衡器的 IP 地址。
+类似地，在删除倒数第二个主节点副本之后，将删除负载均衡器，
+并将其 IP 地址分配给最后一个剩余的副本。
 请注意，创建和删除负载均衡器是复杂的操作，可能需要一些时间（约20分钟）来同步。

 <!--
-### Master service & kubelets
+###主节点service & kubelets

 Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service,
 the system directs all traffic to the external IP:
@@ -296,30 +286,28 @@ the system directs all traffic to the external IP:

 Similarly, the external IP will be used by kubelets to communicate with master.
 -->
+### 主节点服务 & kubelets

-### Master 服务 & kubelets
+Kubernetes 并不试图在其服务中保持 apiserver 的列表为最新，
+相反，它将将所有访问请求指向外部 IP：

-Kubernetes 并不试图在其服务中保持 apiserver 的列表为最新，相反，它将将所有访问请求指向外部 IP：
+* 在拥有一个主节点的集群中，IP 指向单一的主节点，
+* 在拥有多个主节点的集群中，IP 指向主节点前面的负载均衡器。

-* 在拥有一个 Master 的集群中，IP 指向单一的 Master，
-
-* 在拥有多个 Master 的集群中，IP 指向 Master 前面的负载均衡器。
-
-类似地，kubelets 将使用外部 IP 与 Master 通信。
+类似地，kubelets 将使用外部 IP 与主节点通信。

 <!--
 ### Master certificates

-Kubernetes generates Master TLS certificates for the external public IP and local IP for each replica.
+Kubernetes generates主节点TLS certificates for the external public IP and local IP for each replica.
 There are no certificates for the ephemeral public IP for replicas;
 to access a replica via its ephemeral public IP, you must skip TLS verification.
 -->
+### 主节点证书

-### Master 证书
-
-Kubernetes 为每个副本的外部公共 IP 和本地 IP 生成 Master TLS 证书。
+Kubernetes 为每个副本的外部公共 IP 和本地 IP 生成主节点 TLS 证书。
 副本的临时公共 IP 没有证书；
-要通过其临时公共 IP 访问副本，必须跳过TLS验证。
+要通过其临时公共 IP 访问副本，必须跳过 TLS 检查。

 <!--
 ### Clustering etcd
@@ -327,7 +315,6 @@ Kubernetes 为每个副本的外部公共 IP 和本地 IP 生成 Master TLS 证
 To allow etcd clustering, ports needed to communicate between etcd instances will be opened (for inside cluster communication).
 To make such deployment secure, communication between etcd instances is authorized using SSL.
 -->
-
 ### etcd 集群

 为了允许 etcd 组建集群，需开放 etcd 实例之间通信所需的端口（用于集群内部通信）。
@@ -338,9 +325,7 @@ To make such deployment secure, communication between etcd instances is authoriz

 [Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
 -->
-
 ## 拓展阅读

 [自动化高可用集群部署 - 设计文档](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)

-
@@ -12,7 +12,7 @@ content_type: task
 <!--
 This example demonstrates an easy way to limit the amount of storage consumed in a namespace.
 -->
-此示例演示了一种限制命名空间中存储使用量的简便方法。
+此示例演示了一种限制名字空间中存储使用量的简便方法。

 <!--
 The following resources are used in the demonstration: [ResourceQuota](/docs/concepts/policy/resource-quotas/),
@@ -21,8 +21,7 @@ and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/).
 -->
 演示中用到了以下资源：[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)，
 [LimitRange](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) 和
-[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/)。
-
+[PersistentVolumeClaim](/zh/docs/concepts/storage/persistent-volumes/)。

 ## {{% heading "prerequisites" %}}

@@ -51,9 +50,9 @@ The admin would like to limit:
 2. The amount of storage each claim can request
 3. The amount of cumulative storage the namespace can have
 -->
-1. 命名空间中持久卷申领（persistent volume claims）的数量
+1. 名字空间中持久卷申领（persistent volume claims）的数量
 2. 每个申领（claim）可以请求的存储量
-3. 命名空间可以具有的累计存储量
+3. 名字空间可以具有的累计存储量

 <!--
 ## LimitRange to limit requests for storage
@@ -63,7 +62,9 @@ The admin would like to limit:
 <!--
 Adding a `LimitRange` to a namespace enforces storage request sizes to a minimum and maximum. Storage is requested via `PersistentVolumeClaim`. The admission controller that enforces limit ranges will reject any PVC that is above or below the values set by the admin.
 -->
-将 `LimitRange` 添加到命名空间会为存储请求大小强制设置最小值和最大值。存储是通过 `PersistentVolumeClaim` 来发起请求的。执行限制范围控制的准入控制器会拒绝任何高于或低于管理员所设阈值的 PVC。
+将 `LimitRange` 添加到名字空间会为存储请求大小强制设置最小值和最大值。
+存储是通过 `PersistentVolumeClaim` 来发起请求的。
+执行限制范围控制的准入控制器会拒绝任何高于或低于管理员所设阈值的 PVC。

 <!--
 In this example, a PVC requesting 10Gi of storage would be rejected because it exceeds the 2Gi max.
@@ -88,7 +89,8 @@ spec:
 Minimum storage requests are used when the underlying storage provider requires certain minimums. For example,
 AWS EBS volumes have a 1Gi minimum requirement.
 -->
-当底层存储提供程序需要某些最小值时，将会用到所设置最小存储请求值。例如，AWS EBS volumes 的最低要求为 1Gi。
+当底层存储提供程序需要某些最小值时，将会用到所设置最小存储请求值。
+例如，AWS EBS volumes 的最低要求为 1Gi。

 <!--
 ## StorageQuota to limit PVC count and cumulative storage capacity
@@ -99,14 +101,18 @@ AWS EBS volumes have a 1Gi minimum requirement.
 Admins can limit the number of PVCs in a namespace as well as the cumulative capacity of those PVCs. New PVCs that exceed
 either maximum value will be rejected.
 -->
-管理员可以限制某个命名空间中的 PVCs 个数以及这些 PVCs 的累计容量。新 PVCs 请求如果超过任一上限值将被拒绝。
+管理员可以限制某个名字空间中的 PVCs 个数以及这些 PVCs 的累计容量。
+新 PVCs 请求如果超过任一上限值将被拒绝。

 <!--
 In this example, a 6th PVC in the namespace would be rejected because it exceeds the maximum count of 5. Alternatively,
 a 5Gi maximum quota when combined with the 2Gi max limit above, cannot have 3 PVCs where each has 2Gi. That would be 6Gi requested
 for a namespace capped at 5Gi.
 -->
-在此示例中，命名空间中的第 6 个 PVC 将被拒绝，因为它超过了最大计数 5。或者，当与上面的 2Gi 最大容量限制结合在一起时，意味着 5Gi 的最大配额不能支持 3 个都是 2Gi 的 PVC。后者实际上是向命名空间请求 6Gi 容量，而该命令空间已经设置上限为 5Gi。
+在此示例中，名字空间中的第 6 个 PVC 将被拒绝，因为它超过了最大计数 5。
+或者，当与上面的 2Gi 最大容量限制结合在一起时，意味着 5Gi 的最大配额
+不能支持 3 个都是 2Gi 的 PVC。
+后者实际上是向名字空间请求 6Gi 容量，而该命令空间已经设置上限为 5Gi。

 ```
 apiVersion: v1
@@ -119,18 +125,17 @@ spec:
    requests.storage: "5Gi"
 ```

-
-
 <!-- discussion -->

 <!--
 ## Summary
-->
-## 小结

-<!--
 A limit range can put a ceiling on how much storage is requested while a resource quota can effectively cap the storage consumed by a namespace through claim counts and cumulative storage capacity. The allows a cluster-admin to plan their
 cluster's storage budget without risk of any one project going over their allotment.
 -->
-限制范围对象可以用来设置可请求的存储量上限，而资源配额对象则可以通过申领计数和累计存储容量有效地限制命名空间耗用的存储量。这两种机制使得集群管理员能够规划其集群存储预算而不会发生任一项目超量分配的风险。
+## 小结
+
+限制范围对象可以用来设置可请求的存储量上限，而资源配额对象则可以通过申领计数和
+累计存储容量有效地限制名字空间耗用的存储量。
+这两种机制使得集群管理员能够规划其集群存储预算而不会发生任一项目超量分配的风险。

@@ -92,7 +92,7 @@ Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` me
 Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
 -->
 安装 Weave Net 插件后，你可以参考
-[声明网络策略](/zh/docs/tasks/administration-cluster/declare-network-policy/)
+[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
 来试用 Kubernetes NetworkPolicy。
 如果你有任何疑问，请通过
 [Slack 上的 #weave-community 频道或者 Weave 用户组](https://github.com/weaveworks/weave#getting-help)
@@ -16,11 +16,13 @@ content_type: task
 <!-- 
 This page shows how to safely drain a node, respecting the PodDisruptionBudget you have defined.
 -->
-本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个{{< glossary_tooltip text="节点" term_id="node" >}}。
+本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个
+{{< glossary_tooltip text="节点" term_id="node" >}}。

 ## {{% heading "prerequisites" %}}

 {{% version-check %}}
+
 <!-- 
 This task assumes that you have met the following prerequisites:

@@ -37,7 +39,8 @@ This task assumes that you have met the following prerequisites:
 * 使用的 Kubernetes 版本 >= 1.5。
 * 以下两项，具备其一：
  1. 在节点清空期间，不要求应用程序具有高可用性
-  1. 你已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)，并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。
+  1. 你已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)，
+     并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。

 <!-- steps -->

@@ -144,7 +147,8 @@ replicas to fall below the specified budget are blocked.
 并设置了一个 `PodDisruptionBudget`，指定 `minAvailable: 2`。
 如果所有的三个 Pod 均就绪，并且你并行地发出多个 drain 命令，
 那么 `kubectl drain` 只会从 StatefulSet 中逐出一个 Pod，
-因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用（最多不可用 Pod 个数的计算方法：`replicas - minAvailable`）。
+因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用
+（最多不可用 Pod 个数的计算方法：`replicas - minAvailable`）。
 任何会导致就绪副本数量低于指定预算的清空操作都将被阻止。

 <!-- 
@@ -156,7 +160,7 @@ eviction process), you can also programmatically cause evictions using the evict
 -->
 ## 驱逐 API {#the-eviction-api}
 如果你不喜欢使用
-[kubectl drain](/zh/docs/reference/generated/kubectl/kubectl-commands/#drain)
+[kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
 （比如避免调用外部命令，或者更细化地控制 pod 驱逐过程），
 你也可以用驱逐 API 通过编程的方式达到驱逐的效果。

@@ -172,7 +176,8 @@ itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
 [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)。

 Pod 的 Eviction 子资源可以看作是一种策略控制的 DELETE 操作，作用于 Pod 本身。
-要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST 发出所尝试的操作。这里有一个例子：
+要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST
+发出所尝试的操作。这里有一个例子：

 ```json
 {
@@ -254,7 +259,8 @@ application owners and cluster owners to establish an agreement on behavior in t
 ## 驱逐阻塞

 在某些情况下，应用程序可能会到达一个中断状态，除了 429 或 500 之外，它将永远不会返回任何内容。
-例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个 Pod 有很长的终止宽限期，就会发生这种情况。
+例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个
+Pod 有很长的终止宽限期，就会发生这种情况。

 在这种情况下，有两种可能的解决方案：

@@ -266,12 +272,9 @@ Kubernetes 并没有具体说明在这种情况下应该采取什么行为，

 ## {{% heading "whatsnext" %}}

-
 <!-- 
 * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
-* Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node).
 -->
-* 跟随以下步骤保护应用程序：[配置 Pod 中断预算](/zh/docs/tasks/run-application/configure-pdb/)。
-* 进一步了解[节点维护](/zh/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node)。
-
+* 执行[配置 PDB](/zh/docs/tasks/run-application/configure-pdb/)中的各个步骤，
+  保护你的应用