* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
2. Run `kubectl get deployments` to check if the Deployment was created. If the Deployment is still being created, the output is similar to the following:
-->
2. 运行 `kubectl get deployments` 以检查 Deployment 是否已创建。如果仍在创建 Deployment ，则输出以下内容：
@@ -202,11 +214,12 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
```
<!--
<!--
When you inspect the Deployments in your cluster, the following fields are displayed:
-->
检查集群中的 Deployments 时，将显示以下字段：
<!--
<!--
* `NAME` lists the names of the Deployments in the cluster.
* `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
* `CURRENT` displays how many replicas are currently running.
@@ -221,12 +234,12 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
* `AVAILABLE`显示应用程序可供用户使用的副本数。
* `AGE` 显示应用程序运行的时间量。
<!--
<!--
Notice how the number of desired replicas is 3 according to `.spec.replicas` field.
-->
请注意，根据`.spec.replicas`副本字段，所需副本的数量为 3。
<!--
<!--
3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. The output is similar to this:
-->
3. 要查看 Deployment 展开状态，运行 `kubectl rollout status deployment.v1.apps/nginx-deployment`。输出：
@@ -235,7 +248,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
deployment.apps/nginx-deployment successfully rolled out
```
<!--
<!--
4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this:
-->
4. 几秒钟后再次运行 `kubectl get deployments`。输出：
@@ -243,12 +256,12 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s
```
<!--
<!--
Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
-->
请注意， Deployment 已创建所有三个副本，并且所有副本都是最新的（它们包含最新的 Pod 模板）并且可用。
<!--
<!--
5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
-->
5. 要查看 Deployment 创建的 ReplicaSet （`rs`），运行 `kubectl get rs`。输出：
@@ -256,13 +269,13 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
<!--
<!--
Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is
randomly generated and uses the pod-template-hash as a seed.
The created ReplicaSet ensures that there are three `nginx` Pods.
-->
创建的复制集可确保有三个 `nginx` Pods。
{{< note >}}
<!--
<!--
You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
`app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
-->
@@ -334,7 +348,7 @@ is changed, for example if the labels or container images of the template are up
```shell
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
```
<!--
<!--
The output is similar to this:
-->
输出：
@@ -342,7 +356,7 @@ is changed, for example if the labels or container images of the template are up
deployment.apps/nginx-deployment image updated
```
<!--
<!--
Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:
Deployment also ensures that only a certain number of Pods are created above the desired number of Pods.
By default, it ensures that at most 25% of the desired number of Pods are up (25% max surge).
-->
@@ -471,7 +485,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
```shell
kubectl describe deployments
```
<!--
<!--
The output is similar to this:
-->
输出：
@@ -513,7 +527,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3
Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
```
<!--
<!--
Here you see that when you first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211)
and scaled it up to 3 replicas directly. When you updated the Deployment, it created a new ReplicaSet
(nginx-deployment-1564180365) and scaled it up to 1 and then scaled down the old ReplicaSet to 2, so that at
@@ -618,7 +632,7 @@ rolled back.
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
```
<!--
<!--
The output is similar to this:
-->
输出：
@@ -635,7 +649,7 @@ rolled back.
kubectl rollout status deployment.v1.apps/nginx-deployment
```
<!--
<!--
The output is similar to this:
-->
输出：
@@ -660,7 +674,7 @@ rolled back.
kubectl get rs
```
<!--
<!--
The output is similar to this:
-->
输出：
@@ -680,7 +694,7 @@ rolled back.
kubectl get pods
```
<!--
<!--
The output is similar to this:
-->
输出：
@@ -693,7 +707,7 @@ rolled back.
```
{{< note >}}
<!--
<!--
The Deployment controller stops the bad rollout automatically, and stops scaling up the new
ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
Kubernetes by default sets the value to 25%.
@@ -709,7 +723,7 @@ rolled back.
kubectl describe deployment
```
<!--
<!--
The output is similar to this:
-->
输出：
@@ -753,7 +767,7 @@ rolled back.
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
```
<!--
<!--
To fix this, you need to rollback to a previous revision of Deployment that is stable.
-->
要解决此问题，需要回滚到以前稳定的 Deployment 版本。
@@ -775,7 +789,7 @@ rolled back.
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment
```
<!--
<!--
The output is similar to this:
-->
输出：
@@ -787,12 +801,12 @@ rolled back.
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
```
<!--
<!--
`CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You can specify the`CHANGE-CAUSE` message by:
Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following
attributes to the Deployment's `.status.conditions`:
@@ -1480,6 +1510,7 @@ insufficient quota. If you describe the Deployment you will notice the following
```shell
kubectl describe deployment nginx-deployment
```
<!--
The output is similar to this:
-->
@@ -1846,6 +1877,7 @@ a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/
Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used.
* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale) - Set a new size for a Deployment, ReplicaSet, Replication Controller, or Job
* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set) - Set specific features on objects
@@ -44,18 +44,21 @@ ip-masq-agent 配置 iptables 规则以隐藏位于集群节点 IP 地址后面
-->
* **NAT (网络地址解析)**
是一种通过修改 IP 地址头中的源和/或目标地址信息将一个 IP 地址重新映射到另一个 IP 地址的方法。通常由执行 IP 路由的设备执行。
<!--
* **Masquerading**
A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
-->
* **伪装**
NAT 的一种形式，通常用于执行多对一地址转换，其中多个源 IP 地址被隐藏在单个地址后面，该地址通常是执行 IP 路由的设备。在 Kubernetes 中，这是节点的 IP 地址。
<!--
* **CIDR (Classless Inter-Domain Routing)**
Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
-->
* **CIDR (无类别域间路由)**
基于可变长度子网掩码，允许指定任意长度的前缀。CIDR 引入了一种新的 IP 地址表示方法，现在通常称为**CIDR表示法**，其中地址或路由前缀后添加一个后缀，用来表示前缀的位数，例如 192.168.2.0/24。
<!--
* **Link Local**
A link-local address is a network address that is valid only for communications within the network segment or the broadcast domain that the host is connected to. Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16 in CIDR notation.
@@ -79,10 +82,12 @@ The agent configuration file must be written in YAML or JSON syntax, and may con
* **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
@@ -120,6 +120,7 @@ This works for e2e clusters created on GCE. On all other environments, the follo
* A yaml similar to [this](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml) can be applied using `kubectl create -f` command.
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
Reference in New Issue
Block a user
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.
xieyanker