Update Deployment
注意：仅当
.spec.template
更改部署的Pod模板（即）（例如，模板的标签或容器映像已更新）时，才会触发部署的推出。其他更新，例如扩展部署，不会触发部署。
请按照下面给出的步骤更新您的部署：
让我们更新nginx Pods以使用
nginx:1.9.1
图像而不是nginx:1.7.9
图像。kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1或简单地使用以下命令：
kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record输出类似于以下内容：
deployment.apps/nginx-deployment image updated或者，您可以
edit
部署并.spec.template.spec.containers[0].image
从更改nginx:1.7.9
为nginx:1.9.1
：kubectl edit deployment.v1.apps/nginx-deployment输出类似于以下内容：
deployment.apps/nginx-deployment edited要查看部署状态，请运行：
kubectl rollout status deployment.v1.apps/nginx-deployment输出类似于以下内容：
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...要么
deployment.apps/nginx-deployment successfully rolled out
获取有关更新的部署的更多详细信息：
部署成功后，您可以通过运行查看部署
kubectl get deployments
。输出类似于以下内容：NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 36s运行
kubectl get rs
以查看部署通过创建新的ReplicaSet并将其缩放到3个副本，以及将旧的ReplicaSet缩小到0个副本来更新Pod。kubectl get rs输出类似于以下内容：
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 6s
nginx-deployment-2035384211 0 0 0 36s运行kubectl get pods
， 应该只显示新的Pod：kubectl get pods输出类似于以下内容：
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-khku8 1/1 Running 0 14s
nginx-deployment-1564180365-nacti 1/1 Running 0 14s
nginx-deployment-1564180365-z9gth 1/1 Running 0 14s下次您要更新这些Pod时，只需再次更新Deployment的Pod模板。
部署可确保仅在更新某些Pod时将它们关闭。默认情况下，它确保至少有期望数量的Pod的75％可用（最大不可用25％）。
部署还可以确保仅在所需数量的Pod之上创建一定数量的Pod。默认情况下，它确保最多容纳所需数量的Pod的125％（最大浪涌为25％）。
例如，如果您仔细查看上述部署，您将看到它首先创建了一个新的Pod，然后删除了一些旧的Pod，然后创建了新的Pod。在足够数量的新Pod出现之前，它不会杀死旧Pod；在足够数量的老Pod被杀死之前，它不会创建新Pod。确保至少有2个Pod可用，最多总共有4个Pod可用。
获取有关部署的详细信息：
kubectl describe deployments输出类似于以下内容：
Name: nginx-deployment
Namespace: default
CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=2
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3
Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1
Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2
Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2
Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1
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在这里，您看到当您首次创建部署时，它创建了一个ReplicaSet（nginx-deployment-2035384211）并将其直接扩展到最多3个副本。更新部署时，它会创建一个新的ReplicaSet（nginx-deployment-1564180365），并将其缩放到1，然后将旧的ReplicaSet缩小到2，这样至少有2个Pod可用，最多创建了4个Pod。一直。然后，它使用相同的滚动更新策略继续按比例缩放新的和旧的ReplicaSet。最后，新的ReplicaSet中将有3个可用副本，而旧的ReplicaSet将缩小为0。
过渡（又名进行中的多个更新）
每次由Deployment控制器观察到新的Deployment时，都会创建一个ReplicaSet来调出所需的Pod。如果部署已更新，则控制标签匹配.spec.selector
但模板不匹配的Pod的现有ReplicaSet将按.spec.template
比例缩小。最终，新的ReplicaSet缩放为.spec.replicas
，所有旧的ReplicaSet缩放为0。
如果在进行现有部署时更新部署，则部署会根据更新创建一个新的ReplicaSet并开始进行扩展，然后将其先前扩展的ReplicaSet进行滚动-它将添加到其旧列表中复制集并开始按比例缩小。
例如，假设您创建了一个Deployment来创建5个的副本nginx:1.7.9
，但是nginx:1.9.1
当只创建了3个副本时，更新了Deployment以创建5个的副本nginx:1.7.9
。在这种情况下，部署会立即开始杀死nginx:1.7.9
已创建的3个Pod，然后开始创建 nginx:1.9.1
Pod。nginx:1.7.9
更改路线之前，它不等待创建5个副本。
标签选择器更新
通常不建议更新标签选择器，建议您预先计划选择器。无论如何，如果您需要执行标签选择器更新，请格外小心，并确保您已掌握所有含义。
注意：在API版本中
apps/v1
，部署的标签选择器在创建后是不可变的。
选择器的添加也需要使用新标签来更新Deployment规范中的Pod模板标签，否则将返回验证错误。此更改是不重叠的更改，这意味着新选择器不会选择使用旧选择器创建的副本集和Pod，从而导致所有旧副本集孤立，并创建新的副本集。
选择器更新会更改选择器键中的现有值-产生与添加相同的行为。
选择器的删除会从“部署”选择器中删除现有的密钥-不需要对Pod模板标签进行任何更改。现有的副本集不会被孤立，也不会创建新的副本集，但是请注意，已删除的标签仍然存在于任何现有的Pods和副本集中。
