9.3 使用 Deployment 声明式地升级应用

Deployment 是更高阶的资源, ReplicatioinController 和 ReplicaSet 是更底层的概念.

Deployment 依赖 ReplicaSet:

9.3.1 创建一个 Deployment

创建一个 Deployment Manifest

创建 Deployment 资源

删除所有 ReplicationController:

$ kubectl delete rc --all

创建 Deployment:

• --record 记录历史版本号

$ kubectl create -f kubia-deployment-v1.yaml --record

展示 Deployment 滚动过程中的状态

专门用于查看部署状态的命令:

$ kubectl rollout status deployment kubia

了解 Deployment 如何创建 ReplicaSet 以及 pod

• NAME 中的数字是 pod 模板的 hash

通过 Service 访问 pod

9.3.2 升级 Deployment

修改 Deployment 的 pod 模板中的 tag.

不同的 Deployment 升级策略

• RollingUpdate: 执行滚动更新 (默认)
• Recreate: 删除所有旧 pod, 再创建新 pod

演示如何减慢滚动升级速度

• miniReadySeconds 属性

触发滚动升级

在另一个终端中运行 curl 循环:

指定新镜像:

• nodejs 是 Deployment 中 pod 模板指定的名称

Deployment 的优点

9.3.3 回滚 Deployment

创建 v3 版本的应用程序

引入一个 bug 来测试回滚.

部署 v3 版本

观察升级过程:

cur 返回错误:

回滚升级

取消最后一次部署:

• 可以在滚动升级过程中使用

显示 Deployment 的滚动升级历史

历史版本信息就是旧的 ReplicaSet.

查看历史:

回滚到一个特定的 Deployment 版本

需要指定版本号, 上图中 REVISION 列:

• 不应该手动删除 ReplicaSet

• revisionHistoryLimit 属性用于限制历史版本数

9.3.4 控制滚动升级速率

介绍滚动升级策略的 maxSurge 和 maxUnavailable 属性

决定一次替换多少个 pod:

含义:

数量变化:

了解 maxUnavailable 属性

• maxSurge=1
• maxUnavailable=1

注意, maxUnavailable 的值用于计算至少要保持的 pod 个数, 实际上不可用的 pod 可以超过 maxUnavailable

9.3.5 暂停滚动升级

暂停期间可以查看业务是否正常.

暂停滚动升级

使用 v4 pod 滚动升级, 并暂停:

恢复滚动升级

使用暂停功能来停止滚动升级

• 阻止更新 Deployment 而自动触发的滚动升级过程
• 在恢复部署之前, 撤销命令不会撤销它

9.3.6 阻止出错版本的滚动升级

了解 minReadySeconds 的用处

• 指定新创建的 pod 至少要成功运行多久之后, 才能将其视为可用
• maxUnavailable
• 就绪探针

pod 变为就绪态后, 那么应该持续运行 minReadySeconds 时间才继续滚动升级.

所以可以达到减缓滚动升级的目的.

配置就绪探针来阻止全部 v3 版本的滚动部署

使用 kubectl apply 升级 Deployment

• 不需要更改的字段, 不要在配置写明

查看升级过程:

并没有请求切换到 v3:

列出 pod:

就绪探针如何阻止出错版本的滚动升级

就绪探针失败的 pod 会从 Service 的 endpoint 中移除:

• curl 不会访问到不健康的 pod

为滚动升级配置 deadline

查看部署状态:

• ProgressDeadlineExceeded
• progressDeadlineSeconds: 指定超时时间

取消出错版本的滚动升级

取消滚动升级: