The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG/README.md), as well as the version specific upgrade notes prior to upgrading their clusters.
Upgrades on open source Google Compute Engine (GCE) clusters are controlled by the `cluster/gce/upgrade.sh` script.
Get its usage by running `cluster/gce/upgrade.sh -h`.
For example, to upgrade just your master to a specific version (v1.0.2):
-->
开源 Google Compute Engine (GCE) 集群上的升级过程由 `cluster/gce/upgrade.sh` 脚本控制。
运行 `cluster/gce/upgrade.sh -h` 获取使用说明。
例如，只将主控节点升级到一个指定的版本（v1.0.2）：
```shell
cluster/gce/upgrade.sh -M v1.0.2
```
<!--
Alternatively, to upgrade your entire cluster to the latest stable release:
-->
或者，将整个集群升级到最新的稳定版本：
```shell
cluster/gce/upgrade.sh release/stable
```
<!--
### Upgrading Google Kubernetes Engine clusters
Google Kubernetes Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest version. It also handles upgrading the operating system and other components that the master runs on.
-->
### 升级 Google Kubernetes Engine 集群
Google Kubernetes Engine 自动升级主控节点组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。
它还负责主控节点运行的操作系统和其它组件的升级。
<!--
The node upgrade process is user-initiated and is described in the [Google Kubernetes Engine documentation](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade).
Amazon EKS cluster's master components can be upgraded by using eksctl, AWS Management Console, or AWS CLI. The process is user-initiated and is described in the [Amazon EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).
### Upgrading an Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) cluster
Oracle creates and manages a set of master nodes in the Oracle control plane on your behalf (and associated Kubernetes infrastructure such as etcd nodes) to ensure you have a highly available managed Kubernetes control plane. You can also seamlessly upgrade these master nodes to new versions of Kubernetes with zero downtime. These actions are described in the [OKE documentation](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm).
**Cluster autoscaler expects that nodes have not been manually modified (e.g. by adding labels via kubectl) as those properties would not be propagated to the new nodes within the same instance group.**
For more details about how the cluster autoscaler decides whether, when and how
to scale a cluster, please refer to the [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
如果存在对应的 ReplicaSet（或者 ReplicationController），则将在另一个节点上启动 Pod 的新副本。
所以，如果所有的 Pod 都是多副本的，那么在不是所有节点都同时停机的前提下，升级可以在不需要特殊
调整情况下完成。
<!--
If you want more control over the upgrading process, you may use the following workflow:
Use `kubectl drain` to gracefully terminate all pods on the node while marking the node as unschedulable:
-->
如果你希望对升级过程有更多的控制，可以使用下面的工作流程：
使用 `kubectl drain` 体面地结束节点上的所有 Pod 并同时标记节点为不可调度：
```shell
kubectl drain $NODENAME
```
<!--
This keeps new pods from landing on the node while you are trying to get them off.
For pods with a replica set, the pod will be replaced by a new pod which will be scheduled to a new node. Additionally, if the pod is part of a service, then clients will automatically be redirected to the new pod.
-->
在你试图使节点离线时，这样做将阻止新的 Pod 落到它们上面。
对于有 ReplicaSet 的 Pod 来说，它们将会被新的 Pod 替换并且将被调度到一个新的节点。
此外，如果 Pod 是一个 Service 的一部分，则客户端将被自动重定向到新的 Pod。
<!--
For pods with no replica set, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.
Perform maintenance work on the node.
Make the node schedulable again:
-->
对于没有 ReplicaSet 的 Pod，你需要手动启动 Pod 的新副本，并且
如果它不是 Service 的一部分，你需要手动将客户端重定向到这个 Pod。
在节点上执行维护工作。
重新使节点可调度：
```shell
kubectl uncordon $NODENAME
```
<!--
If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
be created automatically (if you're using a cloud provider that supports
node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register).
See [Node](/docs/concepts/architecture/nodes/) for more details.
-->
如果删除了节点的虚拟机实例并重新创建，那么一个新的可调度节点资源将被自动创建
（只在你使用支持节点发现的云服务提供商时；当前只有 Google Compute Engine，
不包括在 Google Compute Engine 上使用 kube-register 的 CoreOS）。
When a new API version is released, you may need to upgrade a cluster to support the new API version (e.g. switching from 'v1' to 'v2' when 'v2' is launched).
-->
## 高级主题
### 升级到不同的 API 版本
当新的 API 版本发布时，你可能需要升级集群支持新的 API 版本
（例如当 'v2' 发布时从 'v1' 切换到 'v2'）。
<!--
This is an infrequent event, but it requires careful management. There is a sequence of steps to upgrade to a new API version.
1. Turn on the new API version.
1. Upgrade the cluster's storage to use the new version.
1. Upgrade all config files. Identify users of the old API version endpoints.
1. Update existing objects in the storage to new version by running `cluster/update-storage-objects.sh`.
### Turn on or off an API version for your cluster
Specific API versions can be turned on or off by passing `-runtime-config=api/<version>` flag while bringing up the API server. For example: to turn off v1 API, pass `--runtime-config=api/v1=false`.
runtime-config also supports 2 special keys: api/all and api/legacy to control all and legacy APIs respectively.
For example, for turning off all API versions except v1, pass `--runtime-config=api/all=false,api/v1=true`.
For the purposes of these flags, _legacy_ APIs are those APIs which have been explicitly deprecated (e.g. `v1beta3`).
-->
### 打开或关闭集群的 API 版本
可以在启动 API 服务器时传递 `--runtime-config=api/<version>` 标志来打开或关闭特定的 API 版本。
例如要关闭除 v1 外全部 API 版本，请传递 `--runtime-config=api/all=false,api/v1=true`。
对于这些标志来说，_遗留（Legacy）_ API 指的是那些被显式废弃的 API（例如 `v1beta3`）。
<!--
### Switching your cluster's storage API version
The objects that are stored to disk for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API.
When the supported API changes, these objects may need to be rewritten in the newer API. Failure to do this will eventually result in resources that are no longer decodable or usable
by the Kubernetes API server.
-->
### 切换集群存储的 API 版本
存储于磁盘中、用于在集群内部代表 Kubernetes 活跃资源的对象使用特定的 API 版本表达。
当所支持的 API 改变时，这些对象可能需要使用更新的 API 重写。
重写失败将最终导致资源不再能够被 Kubernetes API server 解析或使用。
<!--
### Switching your config files to a new API version
You can use `kubectl convert` command to convert config files between different API versions.
-->
### 切换配置文件到新 API 版本
你可以使用 `kubectl convert` 命令对不同 API 版本的配置文件进行转换。
```shell
kubectl convert -f pod.yaml --output-version v1
```
<!--
For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command.
The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
-->
{{< note >}}
以上列表是根据产品名称按字母顺序排序，而不是按推荐或偏好排序。
下面示例对于使用了上面任何提供商的 Kubernetes 集群都是有效的
{{< /note >}}
<!-- steps -->
<!--
@@ -74,7 +68,7 @@ Expose the Deployment through a Service called `nginx`.
-->
将此 Deployment 以名为 `nginx` 的 Service 暴露出来：
```console
```shell
kubectl expose deployment nginx --port=80
```
@@ -89,7 +83,7 @@ The above commands create a Deployment with an nginx Pod and expose the Deployme
Service 暴露出来。名为 `nginx` 的 Pod 和 Deployment 都位于 `default`
名字空间内。
```console
```shell
kubectl get svc,pod
```
```none
@@ -111,7 +105,7 @@ You should be able to access the new `nginx` service from other Pods. To access
你应该可以从其它的 Pod 访问这个新的 `nginx` 服务。
要从 default 命名空间中的其它s Pod 来访问该服务。可以启动一个 busybox 容器：
```console
```shell
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
@@ -167,7 +161,7 @@ Use kubectl to create a NetworkPolicy from the above `nginx-policy.yaml` file:
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Kubernetes Prow Robot