一、Deployment 核心特性与基础概念
- 支持声明式表达：通过YAML文件声明期望的部署状态，无需关注具体执行过程
- 原生支持滚动更新（Rolling Update）与回滚（Rollback）能力，是Kubernetes中最常用的Pod控制器之一
- 实现原理：Deployment控制器管理不同的ReplicaSet（RS），RS负责管控Pod的副本数量，通过多版本RS的交替实现滚动更新与回滚
二、Deployment 滚动更新与回滚官方命令详解
1. --record 参数说明
- 作用：记录每次滚动更新的执行命令，保存到Deployment的Revision历史记录中，方便后续追溯变更内容
- 使用规范：所有
kubectl rollout相关的更新命令后必须追加--record参数，避免历史记录与实际操作不匹配 - 异常场景：如果某次更新时忘记添加
--record，系统会自动继承上一条命令的record记录，导致该版本的历史记录显示为上一次的操作命令，干扰问题排查，因此操作时需刻意养成添加--record的习惯
2. 核心rollout子命令
- 查看更新历史：
kubectl rollout history deployment/<deployment名称>，可查看所有历史版本的版本号、对应变更命令（若添加了--record） - 回滚到上一个版本：
kubectl rollout undo deployment/<deployment名称> - 回滚到指定版本：
kubectl rollout undo deployment/<deployment名称> --to-revision=<目标版本号>- 目标版本号需通过
rollout history命令提前确认，版本号不一定是连续整数，可能是任意数字，若曾回滚过版本，版本号可能不是初始的1，需注意校验
- 目标版本号需通过
- 暂停滚动更新：
kubectl rollout pause deployment/<deployment名称>，暂停后对Deployment的修改不会立即触发滚动更新，直到执行resume命令 - 恢复滚动更新：
kubectl rollout resume deployment/<deployment名称>，恢复后暂停期间的修改会触发滚动更新
3. 历史版本数量限制（revisionHistoryLimit）
- 配置位置：Deployment的
spec.revisionHistoryLimit字段 - 默认行为：默认保留所有历史版本的Revision记录，存储在etcd中
- 设置为0的效果：Deployment不再保留任何历史Revision记录，同时禁止使用
rollout undo命令进行回滚，此时仅能通过本地备份的YAML资源清单完成版本回退 - 注意事项：若将
revisionHistoryLimit设置为0，必须提前备份所有历史版本的完整Deployment YAML文件，仅靠Git等版本管理工具不足够，因为可能修改了副本数、标签、环境变量等非镜像版本参数，需要对应版本的完整YAML才能保证回滚后服务正常
三、自定义版本管理方案（本地文件备份式）
- 设计背景：官方rollout命令的历史记录机制存在缺陷，且历史版本存储在etcd中会占用集群资源，参考Nginx等传统服务的配置管理思路，可实现更轻量、更可控的版本管理
- 核心思路：每次修改Deployment前，先备份当前版本的完整YAML文件，文件名包含时间、修改人、版本号、修改说明等信息，修改后通过
kubectl apply应用新版本，回滚时直接应用对应历史版本的YAML文件即可 - 操作示例：
- 初始创建Deployment后，备份YAML文件为
deployment-20241010-v1.yaml，镜像版本为v1.0 - 更新到v2.0时，复制v1.0的YAML文件为
deployment-20241010-v2.yaml，修改镜像版本为v2.0后执行kubectl apply -f deployment-20241010-v2.yaml，触发滚动更新，过程中可观察到Pod处于部分创建、部分移除、部分运行的状态，属于正常的滚动更新过程 - 后续更新到v3.0同理，备份对应YAML文件后修改应用
- 需要回滚到v1.0时，直接执行
kubectl apply -f deployment-20241010-v1.yaml即可完成回滚
- 初始创建Deployment后，备份YAML文件为
- 优势：历史版本存储在本地磁盘，单个Deployment YAML文件仅约4KB，即使存储大量历史版本也不会占用过多资源，比存储在etcd中更轻量；操作逻辑符合传统运维习惯，无需记忆复杂的rollout子命令，可控性更高，未使用上层图形化管理工具的场景下比官方命令更实用
四、多并行Rollout的处理逻辑
- 场景定义：当Deployment正在执行滚动更新（如v1→v2）的过程中，又发起了新的更新请求（如v2→v3），系统有两种可选处理策略：
- 串行策略：先完成当前正在进行的v1→v2的全部滚动过程，再执行v2→v3的滚动更新
- 并行策略：直接终止当前正在进行的v1→v2更新，将所有现有Pod直接切换到v3版本，无需完成中间版本的更新
- Kubernetes官方采用策略：并行策略
- 设计类比：现实场景中，原本计划开车去A地，中途改变主意去B地，会直接掉头去B地，而不是先开到A地再折返，逻辑更高效
- 策略优势：避免无效的中间版本更新，提升更新效率，符合实际运维场景的需求
AI 总结
本视频围绕Kubernetes Deployment控制器的版本管理展开，首先详细讲解了官方rollout系列命令的使用方法、--record参数的作用与常见坑点、revisionHistoryLimit的配置对历史记录和回滚能力的影响；其次提出了一种基于本地YAML文件备份的自定义版本管理方案，解决了官方历史记录机制不完善、etcd存储占用过高的问题，操作逻辑更符合传统运维习惯；最后解释了Kubernetes多并行Rollout的并行处理策略及其现实类比，帮助学员更灵活、高效地管理Deployment的版本迭代与回滚，提升生产环境运维的可靠性。