目录
Deployment 用于管理运行一个应用负载的一组 Pod，通常适用于不保持状态的负载。
一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力。
你负责描述 Deployment 中的目标状态，而 Deployment 控制器（Controller） 以受控速率更改实际状态， 使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment， 并通过新的 Deployment 收养其资源。
创建Deployment
以下是一个 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 nginx Pod：
vi nginx-deployment.yaml
内容如下
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80开始之前，请确保的 Kubernetes 集群已启动并运行。
按照以下步骤创建上述 Deployment ：
-
通过运行以下命令创建 Deployment ：
kubectl apply -f nginx-deployment.yaml
-
运行
kubectl get deployments检查 Deployment 是否已创建。 如果仍在创建 Deployment，则输出类似于：NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 0/3 0 0 1s
在检查集群中的 Deployment 时，所显示的字段有：
-
NAME列出了名字空间中 Deployment 的名称。 -
READY显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”。 -
UP-TO-DATE显示为了达到期望状态已经更新的副本数。 -
AVAILABLE显示应用可供用户使用的副本数。 -
AGE显示应用程序运行的时间。
请注意期望副本数是根据
.spec.replicas字段设置 3。 -
-
要查看 Deployment 上线状态，运行
kubectl rollout status deployment/nginx-deployment。rollout的含义为展开、铺开
输出类似于：
Waiting for rollout to finish: 2 out of 3 new replicas have been updated... deployment "nginx-deployment" successfully rolled out
-
等待Deployment准备就绪后，再次运行
kubectl get deployments。输出类似于：NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 18s
注意 Deployment 已创建全部三个副本，并且所有副本都是最新的（它们包含最新的 Pod 模板） 并且可用。
-
要查看 Deployment 创建的 ReplicaSet（
rs），运行kubectl get rs。 输出类似于：NAME DESIRED CURRENT READY AGE nginx-deployment-75675f5897 3 3 3 18s
ReplicaSet 输出中包含以下字段：
-
NAME列出名字空间中 ReplicaSet 的名称； -
DESIRED显示应用的期望副本个数，即在创建 Deployment 时所定义的值。 此为期望状态； -
CURRENT显示当前运行状态中的副本个数； -
READY显示应用中有多少副本可以为用户提供服务； -
AGE显示应用已经运行的时间长度。
注意 ReplicaSet 的名称格式始终为
[Deployment 名称]-[哈希]。 该名称将成为所创建的 Pod 的命名基础。 其中的哈希字符串与 ReplicaSet 上的pod-template-hash标签一致。 -
-
要查看每个 Pod 自动生成的标签，运行
kubectl get pods --show-labels。 输出类似于：NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897 nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897 nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897
所创建的 ReplicaSet 确保总是存在三个
nginxPod。
必须在 Deployment 中指定适当的选择算符和 Pod 模板标签（在本例中为 app: nginx）。 标签或者选择算符不要与其他控制器（包括其他 Deployment 和 StatefulSet）重叠。 Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的选择算符， 它们可能会发生冲突执行难以预料的操作。
更新 Deployment
仅当 Deployment Pod 模板（即 .spec.template）发生改变时，例如模板的标签或容器镜像被更新， 才会触发 Deployment 上线。其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。
按照以下步骤更新 Deployment：
-
先来更新 nginx Pod 以使用
nginx:1.16.1镜像，而不是nginx:1.14.2镜像。kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
或者使用下面的命令：
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
在这里，
deployment/nginx-deployment表明 Deployment 的名称，nginx表明需要进行更新的容器， 而nginx:1.16.1则表示镜像的新版本以及它的标签。输出类似于：
deployment.apps/nginx-deployment image updated
或者，可以对 Deployment 执行
edit操作并将.spec.template.spec.containers[0].image从nginx:1.14.2更改至nginx:1.16.1。kubectl edit deployment/nginx-deployment
输出类似于：
deployment.apps/nginx-deployment edited
-
要查看上线状态，运行：
kubectl rollout status deployment/nginx-deployment
输出类似于：
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
或者
deployment "nginx-deployment" successfully rolled out
获取关于已更新的 Deployment 的更多信息：
-
在上线成功后，可以通过运行
kubectl get deployments来查看 Deployment： 输出类似于：NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 36s
-
运行
kubectl get rs以查看 Deployment 通过创建新的 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
-
现在运行
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 模板即可。
Deployment 可确保在更新时仅关闭一定数量的 Pod。默认情况下，它确保至少所需 Pod 的 75% 处于运行状态（最大不可用比例为 25%）。
Deployment 还确保仅所创建 Pod 数量只可能比期望 Pod 数高一点点。 默认情况下，它可确保启动的 Pod 个数比期望个数最多多出 125%（最大峰值 25%）。
例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除旧的 Pod， 并创建了新的 Pod。它不会杀死旧 Pod，直到有足够数量的新 Pod 已经出现。 在足够数量的旧 Pod 被杀死前并没有创建新 Pod。它确保至少 3 个 Pod 可用， 同时最多总共 4 个 Pod 可用。 当 Deployment 设置为 4 个副本时，Pod 的个数会介于 3 和 5 之间。
-
获取 Deployment 的更多信息
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.16.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
可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（
nginx-deployment-2035384211） 并将其直接扩容至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet （nginx-deployment-1564180365），并将其扩容为 1，等待其就绪；然后将旧 ReplicaSet 缩容到 2， 将新的 ReplicaSet 扩容到 2 以便至少有 3 个 Pod 可用且最多创建 4 个 Pod。 然后，它使用相同的滚动更新策略继续对新的 ReplicaSet 扩容并对旧的 ReplicaSet 缩容。 最后，你将有 3 个可用的副本在新的 ReplicaSet 中，旧 ReplicaSet 将缩容到 0。
给更新添加注释
# 给部署添加注释 [root@k8s-master01 1]# kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1" deployment.apps/nginx-deployment annotated # 查看历史版本，CHANGE-CAUSE就是上一步annotate得到的 [root@k8s-master01 1]# kubectl rollout history deployment/nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 1 <none> 2 image updated to 1.16.1
Kubernetes 在计算 availableReplicas 数值时不考虑终止过程中的 Pod， availableReplicas 的值一定介于 replicas - maxUnavailable 和 replicas + maxSurge 之间。 因此，你可能在上线期间看到 Pod 个数比预期的多，Deployment 所消耗的总的资源也大于 replicas + maxSurge 个 Pod 所用的资源，直到被终止的 Pod 所设置的 terminationGracePeriodSeconds 到期为止。
翻转（多 Deployment 动态更新）
Deployment 控制器每次注意到新的 Deployment 时，都会创建一个 ReplicaSet 以启动所需的 Pod。 如果更新了 Deployment，则控制标签匹配 .spec.selector 但模板不匹配 .spec.template 的 Pod 的现有 ReplicaSet 被缩容。 最终，新的 ReplicaSet 缩放为 .spec.replicas 个副本， 所有旧 ReplicaSet 缩放为 0 个副本。
当 Deployment 正在上线时被更新，Deployment 会针对更新创建一个新的 ReplicaSet 并开始对其扩容，之前正在被扩容的 ReplicaSet 会被翻转，添加到旧 ReplicaSet 列表 并开始缩容。
例如，假定你在创建一个 Deployment 以生成 nginx:1.14.2 的 5 个副本，但接下来 更新 Deployment 以创建 5 个 nginx:1.16.1 的副本，而此时只有 3 个 nginx:1.14.2 副本已创建。在这种情况下，Deployment 会立即开始杀死 3 个 nginx:1.14.2 Pod， 并开始创建 nginx:1.16.1 Pod。它不会等待 nginx:1.14.2 的 5 个副本都创建完成后才开始执行变更动作。
更改标签选择算符
通常不鼓励更新标签选择算符。建议你提前规划选择算符。 在任何情况下，如果需要更新标签选择算符，请格外小心， 并确保自己了解这背后可能发生的所有事情。
在 API 版本 apps/v1 中，Deployment 标签选择算符在创建后是不可变的。
-
添加选择算符时要求使用新标签更新 Deployment 规约中的 Pod 模板标签，否则将返回验证错误。 此更改是非重叠的，也就是说新的选择算符不会选择使用旧选择算符所创建的 ReplicaSet 和 Pod， 这会导致创建新的 ReplicaSet 时所有旧 ReplicaSet 都会被孤立。
-
选择算符的更新如果更改了某个算符的键名，这会导致与添加算符时相同的行为。
-
删除选择算符的操作会删除从 Deployment 选择算符中删除现有算符。 此操作不需要更改 Pod 模板标签。现有 ReplicaSet 不会被孤立，也不会因此创建新的 ReplicaSet， 但请注意已删除的标签仍然存在于现有的 Pod 和 ReplicaSet 中。
回滚 Deployment
有时，你可能想要回滚 Deployment；例如，当 Deployment 不稳定时（例如进入反复崩溃状态）。 默认情况下，Deployment 的所有上线记录都保留在系统中，以便可以随时回滚 （你可以通过修改修订历史记录限制来更改这一约束）。
Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版本。 这意味着仅当 Deployment 的 Pod 模板（.spec.template）发生更改时，才会创建新修订版本 -- 例如，模板的标签或容器镜像发生变化。 其他更新，如 Deployment 的扩缩容操作不会创建 Deployment 修订版本。 这是为了方便同时执行手动缩放或自动缩放。 换言之，当你回滚到较早的修订版本时，只有 Deployment 的 Pod 模板部分会被回滚。
-
假设你在更新 Deployment 时犯了一个拼写错误，将镜像名称命名设置为
nginx:1.161而不是nginx:1.16.1：kubectl set image deployment/nginx-deployment nginx=nginx:1.161
输出类似于：
deployment.apps/nginx-deployment image updated
-
此上线进程会出现停滞。你可以通过检查上线状态来验证：
kubectl rollout status deployment/nginx-deployment
输出类似于：
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
-
按 Ctrl-C 停止上述上线状态观测。有关上线停滞的详细信息，参考这里。
-
你可以看到旧的副本（算上来自
nginx-deployment-1564180365和nginx-deployment-2035384211的副本）有 3 个， 新的副本（来自nginx-deployment-3066724191）有 1 个：kubectl get rs
输出类似于：
NAME DESIRED CURRENT READY AGE nginx-deployment-1564180365 3 3 3 25s nginx-deployment-2035384211 0 0 0 36s nginx-deployment-3066724191 1 1 0 6s
-
查看所创建的 Pod，你会注意到新 ReplicaSet 所创建的 1 个 Pod 卡顿在镜像拉取循环中。
kubectl get pods
输出类似于：
NAME READY STATUS RESTARTS AGE nginx-deployment-1564180365-70iae 1/1 Running 0 25s nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s nginx-deployment-1564180365-hysrc 1/1 Running 0 25s nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
Deployment 控制器自动停止有问题的上线过程，并停止对新的 ReplicaSet 扩容。 这行为取决于所指定的 rollingUpdate 参数（具体为
maxUnavailable）。 默认情况下，Kubernetes 将此值设置为 25%。 -
获取 Deployment 描述信息：
kubectl describe deployment
输出类似于：
Name: nginx-deployment Namespace: default CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 Labels: app=nginx Selector: app=nginx Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge Pod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.161 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True ReplicaSetUpdated OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1要解决此问题，需要回滚到以前稳定的 Deployment 版本。
检查 Deployment 上线历史
按照如下步骤检查回滚历史：
-
首先，检查 Deployment 修订历史：
kubectl rollout history deployment/nginx-deployment
输出类似于：
deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml 2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161
CHANGE-CAUSE的内容是从 Deployment 的kubernetes.io/change-cause注解复制过来的。 复制动作发生在修订版本创建时。你可以通过以下方式设置CHANGE-CAUSE消息：-
使用
kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"为 Deployment 添加注解。 -
手动编辑资源的清单。
-
-
要查看修订历史的详细信息，运行：
kubectl rollout history deployment/nginx-deployment --revision=2
revision含义修订、修改
输出类似于：
deployments "nginx-deployment" revision 2 Labels: app=nginx pod-template-hash=1159050644 Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 Containers: nginx: Image: nginx:1.16.1 Port: 80/TCP QoS Tier: cpu: BestEffort memory: BestEffort Environment Variables: <none> No volumes.
回滚到之前的修订版本
按照下面给出的步骤将 Deployment 从当前版本回滚到以前的版本（即版本 2）。
-
假定现在你已决定撤消当前上线并回滚到以前的修订版本：
kubectl rollout undo deployment/nginx-deployment
输出类似于：
deployment.apps/nginx-deployment rolled back
或者，你也可以通过使用
--to-revision来回滚到特定修订版本：kubectl rollout undo deployment/nginx-deployment --to-revision=2
输出类似于：
deployment.apps/nginx-deployment rolled back
与回滚相关的指令的更详细信息，请参考 kubectl rollout。
现在，Deployment 正在回滚到以前的稳定版本。正如你所看到的，Deployment 控制器生成了回滚到修订版本 2 的
DeploymentRollback事件。 -
检查回滚是否成功以及 Deployment 是否正在运行，运行：
kubectl get deployment nginx-deployment
输出类似于：
NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 30m
-
获取 Deployment 描述信息：
kubectl describe deployment nginx-deployment
输出类似于：
Name: nginx-deployment Namespace: default CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 Labels: app=nginx Annotations: deployment.kubernetes.io/revision=4 kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 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.16.1 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3 Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1 Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2 Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2 Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1 Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3 Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0 Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1 Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2 Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0
缩放 Deployment
你可以使用如下指令缩放 Deployment：
kubectl scale deployment/nginx-deployment --replicas=10
输出类似于：
deployment.apps/nginx-deployment scaled
查看pod，有10个pod
[root@k8s-master01 deployment]# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-7dbfbc79cf-2669j 1/1 Running 0 8m46s nginx-deployment-7dbfbc79cf-2fh9d 1/1 Running 0 12s nginx-deployment-7dbfbc79cf-7d7mh 1/1 Running 0 12s nginx-deployment-7dbfbc79cf-9zrbk 1/1 Running 0 12s nginx-deployment-7dbfbc79cf-dzmn7 1/1 Running 0 12s nginx-deployment-7dbfbc79cf-fbp96 1/1 Running 0 8m45s nginx-deployment-7dbfbc79cf-gh5st 1/1 Running 0 8m47s nginx-deployment-7dbfbc79cf-hzch9 1/1 Running 0 12s nginx-deployment-7dbfbc79cf-jwfqd 1/1 Running 0 12s nginx-deployment-7dbfbc79cf-mnnsp 1/1 Running 0 12s
假设集群启用了Pod 的水平自动缩放， 你可以为 Deployment 设置自动缩放器，并基于现有 Pod 的 CPU 利用率选择要运行的 Pod 个数下限和上限。
kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
输出类似于：
deployment.apps/nginx-deployment scaled
比例缩放
RollingUpdate 的 Deployment 支持同时运行应用程序的多个版本。 当自动缩放器缩放处于上线进程（仍在进行中或暂停）中的 RollingUpdate Deployment 时， Deployment 控制器会平衡现有的活跃状态的 ReplicaSet（含 Pod 的 ReplicaSet）中的额外副本， 以降低风险。这称为 比例缩放（Proportional Scaling）。
例如，你正在运行一个 10 个副本的 Deployment，其 maxSurge=3，maxUnavailable=2。
-
确保 Deployment 的这 10 个副本都在运行。
kubectl get deploy
输出类似于：
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 10 10 10 10 50s
-
更新 Deployment 使用新镜像，碰巧该镜像无法从集群内部解析。
kubectl set image deployment/nginx-deployment nginx=nginx:sometag
输出类似于：
deployment.apps/nginx-deployment image updated
-
镜像更新使用 ReplicaSet
nginx-deployment-1989198191启动新的上线过程， 但由于上面提到的maxUnavailable要求，该进程被阻塞了。检查上线状态：kubectl get rs
输出类似于：
NAME DESIRED CURRENT READY AGE nginx-deployment-1989198191 5 5 0 9s nginx-deployment-618515232 8 8 8 1m
-
然后，出现了新的 Deployment 扩缩请求。自动缩放器将 Deployment 副本增加到 15。 Deployment 控制器需要决定在何处添加 5 个新副本。如果未使用比例缩放，所有 5 个副本 都将添加到新的 ReplicaSet 中。使用比例缩放时，可以将额外的副本分布到所有 ReplicaSet。 较大比例的副本会被添加到拥有最多副本的 ReplicaSet，而较低比例的副本会进入到 副本较少的 ReplicaSet。所有剩下的副本都会添加到副本最多的 ReplicaSet。 具有零副本的 ReplicaSet 不会被扩容。
在上面的示例中，3 个副本被添加到旧 ReplicaSet 中，2 个副本被添加到新 ReplicaSet。 假定新的副本都很健康，上线过程最终应将所有副本迁移到新的 ReplicaSet 中。 要确认这一点，请运行：
kubectl get deploy
输出类似于：
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 15 18 7 8 7m
上线状态确认了副本是如何被添加到每个 ReplicaSet 的。
kubectl get rs
输出类似于：
NAME DESIRED CURRENT READY AGE nginx-deployment-1989198191 7 7 0 7m nginx-deployment-618515232 11 11 11 7m
暂停、恢复 Deployment 的上线过程
在你更新一个 Deployment 的时候，或者计划更新它的时候， 你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。 当你准备应用这些变更时，你可以重新恢复 Deployment 上线过程。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。
-
例如，对于一个刚刚创建的 Deployment：
获取该 Deployment 信息：
kubectl get deploy
输出类似于：
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx 3 3 3 3 1m
获取上线状态：
kubectl get rs
输出类似于：
NAME DESIRED CURRENT READY AGE nginx-2142116321 3 3 3 1m
-
使用如下指令暂停上线：
kubectl rollout pause deployment/nginx-deployment
输出类似于：
deployment.apps/nginx-deployment paused
-
接下来更新 Deployment 镜像：
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
输出类似于：
deployment.apps/nginx-deployment image updated
-
注意没有新的上线被触发：
kubectl rollout history deployment/nginx-deployment
输出类似于：
deployments "nginx" REVISION CHANGE-CAUSE 1 <none>
-
获取上线状态验证现有的 ReplicaSet 没有被更改：
kubectl get rs
输出类似于：
NAME DESIRED CURRENT READY AGE nginx-2142116321 3 3 3 2m
-
你可以根据需要执行很多更新操作，例如，可以要使用的资源：
kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
输出类似于：
deployment.apps/nginx-deployment resource requirements updated
暂停 Deployment 上线之前的初始状态将继续发挥作用，但新的更新在 Deployment 上线被暂停期间不会产生任何效果。
-
最终，恢复 Deployment 上线并观察新的 ReplicaSet 的创建过程，其中包含了所应用的所有更新：
kubectl rollout resume deployment/nginx-deployment
输出类似于这样：
deployment.apps/nginx-deployment resumed
-
监视上线的状态，直到完成。
kubectl get rs --watch
输出类似于：
NAME DESIRED CURRENT READY AGE nginx-2142116321 2 2 2 2m nginx-3926361531 2 2 0 6s nginx-3926361531 2 2 1 18s nginx-2142116321 1 2 2 2m nginx-2142116321 1 2 2 2m nginx-3926361531 3 2 1 18s nginx-3926361531 3 2 1 18s nginx-2142116321 1 1 1 2m nginx-3926361531 3 3 1 18s nginx-3926361531 3 3 2 19s nginx-2142116321 0 1 1 2m nginx-2142116321 0 1 1 2m nginx-2142116321 0 0 0 2m nginx-3926361531 3 3 3 20s
-
获取最近上线的状态：
kubectl get rs
输出类似于：
NAME DESIRED CURRENT READY AGE nginx-2142116321 0 0 0 2m nginx-3926361531 3 3 3 28s
注意：不可以回滚处于暂停状态的 Deployment，除非先恢复其执行状态。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
