—record
的 flag 设置为 true
可以在 annotation 中记录当前命令创建或者升级了该资源。这在未来会很有用,例如,查看在每个 Deployment revision 中执行了哪些命令。get
将获得如下结果:.spec.replicas
配置)当前 replica 数( .status.replicas
)是 0, 最新的 replica 数(.status.updatedReplicas
)是 0,可用的 replica 数(.status.availableReplicas
)是 0。get
命令,将获得如下输出:.spec.minReadySeconds
声明,处于已就绪状态的 pod 的最少个数)。执行 kubectl get rs
和 kubectl get pods
会显示 Replica Set(RS)和 Pod 已创建。<Deployment 的名字>-<pod template 的 hash 值 >
。app = nginx
),不要跟其他的 controller 搞混了(包括 Deployment、Replica Set、Replication Controller 等)。Kubernetes 本身不会阻止你这么做 ,如果你真的这么做了,这些 controller 之间会相互打架,并可能导致不正确的行为。.spec.template
)中的 label 更新或者镜像更改时被触发。其他更新,例如扩容 Deployment 不会触发 rollout。nginx:1.9.1
的镜像来代替原来的 nginx:1.7.9
的镜像。edit
命令来编辑 Deployment,修改 .spec.template.spec.containers[0].image
,将 nginx:1.7.9
改写成 nginx:1.9.1
。get
Deployment:kubectl get rs
可以看到 Deployment 更新了 Pod,通过创建一个新的 Replica Set 并扩容了 3 个 replica,同时将原来的 Replica Set 缩容到了 0 个 replica。get pods
只会看到当前的新的 pod:.spec.selector
但是 template 跟 .spec.template
不匹配的 Pod 缩容。最终,新的 Replica Set 将会扩容出 .spec.replicas
指定数目的 Pod,旧的 Replica Set 会缩容到 0。niginx:1.7.9
replica 的 Deployment,但是当还只有 3 个 nginx:1.7.9
的 replica 创建出来的时候你就开始更新含有 5 个 nginx:1.9.1
replica 的 Deployment。在这种情况下,Deployment 会立即杀掉已创建的 3 个 nginx:1.7.9
的 Pod,并开始创建 nginx:1.9.1
的 Pod。它不会等到所有的 5 个 nginx:1.7.9
的 Pod 都创建完成后才开始执行滚动更新。revision history limit
来更改保存的 revision 数)。.spec.template
)被更改,例如更新 template 中的 label 和容器镜像时,就会创建出一个新的 revision。nginx:1.91
,而正确的名字应该是 nginx:1.9.1
:—recored
参数可以记录命令,我们可以很方便的查看每次 revison 的变化。--to-revision
参数指定某个历史版本:DeploymentRollback
的 event。.spec.revisonHistoryLimit
项来指定 deployment 最多保留多少 revison 历史记录。默认的会保留所有的 revision;如果将该项设置为 0,Deployment 就不允许回退了。kubectl rollout status
命令监控 Deployment 的进度。kubectl rollout status
命令查看 Deployment 是否完成。如果 rollout 成功完成,kubectl rollout status
将返回一个 0 值的 Exit Code。spec.progressDeadlineSeconds
。spec.progressDeadlineSeconds
表示 Deployment controller 等待多少秒才能确定(通过 Deployment status)Deployment 进程是卡住的。kubectl
命令设置 progressDeadlineSeconds
使 controller 在 Deployment 在进度卡住 10 分钟后报告:status.conditions
中增加一条 DeploymentCondition,它包括如下属性:Reason=ProgressDeadlineExceeded
状态信息外不会对卡住的 Deployment 做任何操作。更高层次的协调器可以利用它并采取相应行动,例如,回滚 Deployment 到之前的版本。kubectl get deployment nginx-deployment -o yaml
,Deployement 的状态可能看起来像这个样子:Status=True
并且 Reason=NewReplicaSetAvailable
)。Type=Available
、 Status=True
意味着你的 Deployment 有最小可用性。 最小可用性是在 Deployment 策略中指定的参数。 Type=Progressing
、 Status=True
意味着你的 Deployment 或者在部署过程中,或者已经成功部署,达到了期望的最少的可用 replica 数量(查看特定状态的 Reason——在我们的例子中 Reason=NewReplicaSetAvailable
意味着 Deployment 已经完成)。kubectl rollout status
命令查看 Deployment 进程是否失败。当 Deployment 过程超过了 deadline,kubectl rollout status
将返回非 0 的 exit code。.spec.revisionHistoryLimit
项来指定保留多少旧的 ReplicaSet。 余下的将在后台被当作垃圾收集。默认的,所有的 revision 历史都会被保留。在未来的版本中,将会更改为 2。apiVersion
,kind
和 metadata
这些配置项。配置文件的通用使用说明查看 部署应用,配置容器,和使用 kubeclt 管理资源 文档。.spec.template
是 .spec
中唯一要求的字段。.spec.replicas
是可以选字段,指定期望的 pod 数量,默认是 1。.spec.selector
必须匹配 .spec.template.metadata.labels
,否则它将被 API 拒绝。如果 .spec.selector
没有被指定, .spec.selector.matchLabels
默认是 .spec.template.metadata.labels
。.spec.template
不同或者数量超过了 .spec.replicas
规定的数量的情况下,Deployment 会杀掉 label 跟 selector 不同的 Pod。.spec.strategy
指定新的 Pod 替换旧的 Pod 的策略。 .spec.strategy.type
可以是 "Recreate" 或者是 "RollingUpdate"。"RollingUpdate" 是默认值。.spec.strategy.type==Recreate
时,在创建出新的 Pod 之前会先杀掉所有已存在的 Pod。.spec.strategy.type==RollingUpdate
时,Deployment 使用 rolling update 的方式更新 Pod 。你可以指定 maxUnavailable
和 maxSurge
来控制 rolling update 进程。.spec.strategy.rollingUpdate.maxUnavailable
是可选配置项,用来指定在升级过程中不可用 Pod 的最大数量。该值可以是一个绝对值(例如 5),也可以是期望 Pod 数量的百分比(例如 10%)。通过计算百分比的绝对值向下取整。如果 .spec.strategy.rollingUpdate.maxSurge
为 0 时,这个值不可以为 0。默认值是 1。.spec.strategy.rollingUpdate.maxSurge
是可选配置项,用来指定可以超过期望的 Pod 数量的最大个数。该值可以是一个绝对值(例如 5)或者是期望的 Pod 数量的百分比(例如 10%)。当 MaxUnavailable
为 0 时该值不可以为 0。通过百分比计算的绝对值向上取整。默认值是 1。.spec.progressDeadlineSeconds
是可选配置项,用来指定在系统报告 Deployment 的 failed progressing ——表现为 resource 的状态中 type=Progressing
、Status=False
、 Reason=ProgressDeadlineExceeded
前可以等待的 Deployment 进行的秒数。Deployment controller 会继续重试该 Deployment。未来,在实现了自动回滚后, deployment controller 在观察到这种状态时就会自动回滚。.spec.minReadySeconds
。.spec.minReadySeconds
是一个可选配置项,用来指定没有任何容器 crash 的 Pod 并被认为是可用状态的最小秒数。默认是 0(Pod 在 ready 后就会被认为是可用状态)。进一步了解什么时候 Pod 会被认为是 ready 状态,参阅 Container Probes。.spec.rollbackTo
是一个可以选配置项,用来配置 Deployment 回退的配置。设置该参数将触发回退操作,每次回退完成后,该值就会被清除。.spec.rollbackTo.revision
是一个可选配置项,用来指定回退到的 revision。默认是 0,意味着回退到上一个 revision。.spec.revisionHistoryLimit
是一个可选配置项,用来指定可以保留的旧的 ReplicaSet 数量。该理想值取决于新 Deployment 的频率和稳定性。如果该值没有设置的话,默认所有旧的 Replicaset 或会被保留,将资源存储在 etcd 中,使用 kubectl get rs
查看输出。每个 Deployment 的该配置都保存在 ReplicaSet 中,然而,一旦你删除的旧的 RepelicaSet,你的 Deployment 就无法再回退到那个 revison 了。.spec.paused
是可选配置项,boolean 值。用来指定暂停和恢复 Deployment。Paused 和非 paused 的 Deployment 之间的唯一区别就是,所有对 paused deployment 中的 PodTemplateSpec 的修改都不会触发新的 rollout。Deployment 被创建之后默认是非 paused。