文章目录
- Deployment‑核心操作完整版（修正踩坑点 + 实操优化 + 生产规范）
- 一、本次实操踩坑核心问题（必须牢记）
- 解决方案二选一
- 方案1：修正yaml资源名称（推荐，文件名称与内部资源名统一，杜绝混淆）
- 方案2：命令行快速更新镜像（最简单，不受yaml名称坑干扰）
- 第四部分 Deployment 核心生产级操作（优化修订版）
- 前置说明
- 1、副本弹性伸缩 scale
- 2、滚动更新 Rolling‑Update（三种标准更新方式）
- 方式1：修改YAML清单（生产环境首选，配置可留存、可版本管理）
- 方式2：set‑image 单行快速更新镜像（测试环境快速调试）
- 方式3：kubectl edit 在线编辑资源
- 3. 监控滚动更新全过程
- 4. 校验镜像是否真正生效（三步校验）
- 3、查看发布历史 rollout history
- 4、故障回滚 Rollback（生产故障应急必备）
- 5、滚动更新暂停、批量修改配置再一次性发布
- 6、滚动更新高级策略（生产环境配置，写入yaml）
- 7、强制重建全部Pod（镜像拉取策略IfNotPresent场景）
- 生产环境重点避坑清单（优化补充）
Deployment‑核心操作完整版（修正踩坑点 + 实操优化 + 生产规范）
先对你刚才实操出现的致命问题做根源复盘，之后整理一份无坑、适合授课、企业落地的全套操作文档
一、本次实操踩坑核心问题（必须牢记）
kubectl apply -f xxx.yaml读取 yaml内部metadata.name定位K8s资源，和本地文件名字毫无关系
- 本地文件名称：
nginx‑deploy.yaml - yaml清单内部定义名称：
nginx‑web - 你日常操作的工作负载：
nginx‑deploy
所以你修改镜像、执行apply只会更新nginx‑web，nginx‑deploy 完全不受改动，镜像依旧是 stable‑alpine，并不会升级为1.25.3‑alpine。
