Merge branch 'master' into dev-1.18

2020-02-25 12:37:49 -08:00
parent 613e67c26e 3f020e5f5c
commit 78193337e4
45 changed files with 1034 additions and 57 deletions
@@ -45,7 +45,7 @@ By convention, the names of Kubernetes resources should be up to maximum length
 For example, here’s the configuration file with a Pod name as `nginx-demo` and a Container name as `nginx`:
 -->

-例如，下面是一个配置文件，Pod 名为 `nginx demo`，容器名为 `nginx`：
+例如，下面是一个配置文件，Pod 名为 `nginx-demo`，容器名为 `nginx`：

 ```yaml
 apiVersion: v1
@@ -82,8 +82,8 @@ The following manifest creates a storage class "slow" which provisions standard
 disk-like persistent disks.
 -->
 要启用动态供应功能，集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。
-`StorageClass` 对象定义在进行动态卷供应时应使用哪个卷供应商，以及应该将哪些参数传递给该供应商。
-以下清单创建了一个存储类 "slow"，它提供类似标准磁盘的永久磁盘。
+`StorageClass` 对象定义当动态供应被调用时，哪一个驱动将被使用和哪些参数将被传递给驱动。
+以下清单创建了一个 `StorageClass` 存储类 "slow"，它提供类似标准磁盘的永久磁盘。

 ```yaml
 apiVersion: storage.k8s.io/v1
@@ -25,7 +25,7 @@ how many volumes can be attached to a Node. It is important for Kubernetes to
 respect those limits. Otherwise, Pods scheduled on a Node could get stuck
 waiting for volumes to attach. -->

-谷歌、亚马逊和微软等云供应商通常对可以关联到节点的卷数量进行限制。 
+谷歌、亚马逊和微软等云供应商通常对可以关联到节点的卷数量进行限制。
 Kubernetes 需要尊重这些限制。 否则，在节点上调度的 Pod 可能会卡住去等待卷的关联。


@@ -135,7 +135,7 @@ Refer to the [CSI specifications](https://github.com/container-storage-interface

 * 在
 <a href="https://cloud.google.com/compute/">Google Compute Engine</a>环境中,
-[根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将128个卷关联到节点。
+[根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将127个卷关联到节点。

 * 对于 M5、C5、R5、T3 和 Z1D 类型实例的 Amazon EBS 磁盘，Kubernetes 仅允许 25 个卷关联到节点。
 对于 ec2 上的其他实例类型
@@ -141,7 +141,7 @@ While a snapshot is being taken of a PersistentVolumeClaim, that PersistentVolum
 -->
 如果一个 PVC 正在被快照用来作为源进行快照创建，则该 PVC 是使用中的。如果用户删除正作为快照源的 PVC API 对象，则 PVC 对象不会立即被删除掉。相反，PVC 对象的删除将推迟到任何快照不在主动使用它为止。当快照的 `Status` 中的 `ReadyToUse`值为 `true` 时，PVC 将不再用作快照源。

-当从 `PersistentVolumeClaim` 中生成快照时，`PersistentVolumeClaim` 就在被使用了。如果删除一个作为快照源的 `PersistentVolumeClaim` 对象，这个 `PersistentVolumeClaim` 对象不会立即被删除的。相反，在快照可以被使用或者被放弃之后，才会执行删除 `PersistentVolumeClaim` 对象的动作。
+当从 `PersistentVolumeClaim` 中生成快照时，`PersistentVolumeClaim` 就在被使用了。如果删除一个作为快照源的 `PersistentVolumeClaim` 对象，这个 `PersistentVolumeClaim` 对象不会立即被删除的。相反，删除 `PersistentVolumeClaim` 对象的动作会被放弃，或者推迟到快照的 Status 为 ReadyToUse时再执行。

 <!--
 ### Delete
@@ -358,8 +358,8 @@ kubectl get events --sort-by=.metadata.creationTimestamp
 <!-- ## Updating Resources -->
 ## 更新资源

-<!-- As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)), use `rollout` instead. -->
-从版本 1.11 开始，`rolling-update` 已被弃用（参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md))，请使用 `rollout` 代替。
+<!-- As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), use `rollout` instead. -->
+从版本 1.11 开始，`rolling-update` 已被弃用（参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))，请使用 `rollout` 代替。

 <!-- ```bash
 kubectl set image deployment/frontend www=image:v2               # Rolling update "www" containers of "frontend" deployment, updating the image
@@ -25,8 +25,8 @@ kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群
 * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用 kubeadm v1.7.x 或者更低版本，你需要对你的集群做一些配置以便使用 `kubeadm upgrade` 命令
 <!-- * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` -->
 * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 使用 `kubeadm join` 来管理令牌
-<!-- * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` -->
-* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 使用 `kubeadm init` 或者  `kubeadm join` 来恢复对节点的改变
+<!-- * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` --> 
+* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原之前使用 `kubeadm init` 或者 `kubeadm join` 对节点产生的改变
 <!-- * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version -->
 * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印出 kubeadm 版本
 <!-- * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community -->
@@ -57,14 +57,14 @@ The upgrade workflow at high level is the following:
 - You need to have a kubeadm Kubernetes cluster running version 1.16.0 or later.
 - [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
 - The cluster should use a static control plane and etcd pods or external etcd.
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md) carefully.
+- Make sure you read the [release notes]({{< latest-release-notes >}}) carefully.
 - Make sure to back up any important components, such as app-level state stored in a database.
  `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
 -->
 - 您需要有一个由 `kubeadm` 创建并运行着 1.16.0 或更高版本的 Kubernetes 集群。
 - [禁用 Swap](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux)。
 - 集群应使用静态的控制平面和 etcd pod 或者 外部 etcd。
- 务必仔细认真阅读[发行说明](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md)。
+- 务必仔细认真阅读[发行说明]({{< latest-release-notes >}})。
 - 务必备份所有重要组件，例如存储在数据库中应用层面的状态。
  `kubeadm upgrade` 不会影响您的工作负载，只会涉及 Kubernetes 内部的组件，但备份终究是好的。

@@ -666,4 +666,4 @@ To recover from a bad state, you can also run `kubeadm upgrade --force` without
 `kubeadm upgrade node experimental-control-plane` 在其他控制平面节点上执行以下操作：
 - 从集群中获取 kubeadm `ClusterConfiguration`。
 - 可选地备份 kube-apiserver 证书。
- 升级控制平面组件的静态 Pod 清单。
+- 升级控制平面组件的静态 Pod 清单。