Kubernetes v1.29 Deployment 滚动更新与更新策略笔记
一、前置内容提及
视频开头提及后续实验安排：将先部署集群监控服务，通过Metrics Server为Kubernetes API提供资源指标接口，后续将演示通过调整Pod副本数实现自动扩容（HPA）的实验，当前先跳过该部分内容。
二、Deployment 镜像更新与滚动更新实操演示
1. 初始环境初始化
先清理历史实验资源，重新创建Nginx Deployment，初始配置为副本数3、容器镜像为myapp 1.0版本，通过kubectl get pods -o wide查看初始Pod状态，确认当前Pod镜像版本为3.0，无异常。
2. 镜像更新操作演示
演示两种Deployment镜像更新的实现方式：
- 方式1：直接修改Deployment YAML文件，调整副本数为10、镜像版本改回1.0，重新创建Deployment后，确认所有Pod版本均为1.0，运行正常。
- 方式2：使用
kubectl set image命令直接修改运行中Deployment的容器镜像版本：由于Pod是容器组，若Deployment下包含多个容器，必须指定目标容器的名称，否则无法确定需要更新的对象。本次将Nginx Deployment的容器镜像版本从1.0修改为2.0。
3. 滚动更新过程观察
执行更新命令后，通过kubectl get pods观察Pod状态变化，可看到四类典型状态：
- Pending：Pod已成功创建，但尚未调度到可用节点
- ContainerCreating：容器正在拉取镜像、完成初始化配置
- Running：新版本容器已正常运行，可承接业务请求
- Terminating：旧版本Pod正在被逐步销毁
核心观察结论：滚动更新不会一次性销毁所有旧版本Pod，而是分批销毁旧Pod、创建新Pod，逐步完成全量版本替换，避免业务完全中断。
4. 滚动更新过程中的服务可用性验证
- 提前创建对应Service：类型为ClusterIP，名称为nginx-deployment，匹配标签
app=nginx-deployment，配置集群端口80映射到Pod端口80，实现负载均衡。 - 通过
curl循环访问Service的ClusterIP，初始返回1.0版本的响应。 - 执行
kubectl set image将镜像版本修改为nginx:3.0后，访问过程中会出现短暂卡顿：原因是请求被分发到正在终止的旧Pod，等待响应超时，中断后重新访问即可恢复。随着更新推进，返回3.0版本的响应占比逐渐升高，直至全量切换为3.0。 - 进一步将镜像版本修改为nginx:4.0（未提前拉取的镜像），新Pod创建速度变慢（需要先拉取镜像资源），但滚动更新的逐步替换逻辑不变，最终全量切换为4.0。
该滚动更新逻辑是行业中常见的渐进式发布（灰度发布）思路。
三、滚动更新策略核心原理与控制参数
1. 更新策略类型对比
Deployment支持两种更新策略，适用场景不同：
- Recreate（重建策略）：先销毁所有旧版本Pod，再创建新版本Pod，更新速度快，但会中断业务，适合无用户访问的低峰期更新。
- RollingUpdate（滚动更新策略）：Deployment默认策略，逐步替换旧版本Pod，更新过程中旧版本Pod逐步销毁、新版本Pod逐步创建并接入服务，保证业务持续可用，适合业务运行期间的版本升级。
2. 核心控制参数
滚动更新的批次大小、影响范围通过maxSurge和maxUnavailable两个参数控制，二者并行生效：
- maxUnavailable：允许更新过程中不可用的Pod的最大数量/比例，核心控制业务中断的上限。
- 默认值：Kubernetes v1.29版本中，通过Apps API组创建的Deployment默认值为25%；该默认值从Kubernetes v1.16版本开始生效，早期通过Extensions API组创建的Deployment默认值为1（即最多允许1个Pod不可用）。
- 示例：若Deployment期望副本数为10，默认maxUnavailable为25%，则更新过程中最少需要保持7个可用Pod，最多允许3个Pod处于不可用状态。
- maxSurge：允许更新过程中超过期望副本数的最大Pod数量/比例，核心控制更新速度的上限。
- 默认值：Kubernetes v1.29版本中，通过Apps API组创建的Deployment默认值为25%；早期通过Extensions API组创建的Deployment默认值为1（即最多允许额外创建1个Pod）。
- 示例：若Deployment期望副本数为10，默认maxSurge为25%，则更新过程中最多可以存在12个Pod（10个期望副本+2个超额副本）。
3. 参数设置的权衡逻辑
- 滚动比例越小（maxSurge和maxUnavailable设置越小）：更新过程中对用户的影响越小，业务稳定性越高，但更新总耗时越长。
- 滚动比例越大：更新速度越快，但更新过程中业务中断、请求失败的风险越高。
- 极端限制场景：若同时设置
maxUnavailable=0（不允许减少副本数）和maxSurge=0（不允许增加副本数），滚动更新无法执行，因为无法同时保留旧Pod和创建新Pod完成版本替换。
4. 滚动更新执行逻辑示例（讲师以10副本Deployment为例说明）
默认参数下（maxUnavailable=25%、maxSurge=25%），滚动更新执行流程为：
- 第一批：先创建2个新版本Pod，此时总Pod数为12，再销毁2个旧版本Pod，总Pod数回到10，完成2个Pod的版本替换。
- 后续批次重复该逻辑，逐步完成全量10个Pod的版本替换，过程中总Pod数始终在8~12之间波动，不会出现全量业务中断。
四、后续实验预告
后续将结合部署好的监控服务，演示通过调整Deployment副本数实现Pod自动扩容（HPA）的实验，验证监控指标与自动扩缩容的联动逻辑。
AI 总结
本段视频围绕Kubernetes v1.29中Deployment的滚动更新机制展开，首先通过实操演示完整验证了滚动更新的执行流程：从镜像更新触发、Pod状态变化，到服务可用性的影响，直观展示了滚动更新逐步替换、业务不中断的核心特性；其次深入讲解了滚动更新的核心控制参数maxSurge、maxUnavailable的默认值、作用逻辑与版本差异，以及不同参数设置对更新速度、业务稳定性的权衡关系，同时对比了滚动更新与重建策略的适用场景；最后预告了后续结合监控服务的自动扩容实验，帮助学习者完整掌握Pod控制器的核心能力。