Deployment-001篇

文章目录

• 第一部分：为什么必须要有 Deployment？
• • • 1. 自主式 Pod 的痛点（生产环境的灾难）
    • 2. Deployment 的解决方案
• 第二部分：Deployment 的架构层级
• 第三部分：你的第一个 Deployment（动手）
• • • 1. 编写 YAML 文件
    • 2. 执行命令
    • 3. 验证自愈能力（重点实验）
• 第四部分：Deployment 的核心操作（生产必备）
• • • 1. 弹性伸缩（Scale）
    • 2. 滚动更新（Rolling Update）
    • • 方法一：修改 YAML（推荐，可追溯）
      • 方法二：直接 set 命令（快捷）
      • 观察更新过程：
    • 3. 检查更新历史
    • 4. 回滚（Rollback）
    • 5. 暂停与恢复发布
• 第五部分：滚动更新策略详解（企业调优）
• 第六部分：常见故障排查命令
• 总结：从 Pod 到 Deployment 的思维转变

太棒了，这是从**“玩具”迈向“生产”最关键的一步**。

在前面我们讲的 Pod，叫做自主式 Pod（Static Pod）。这种 Pod 最大的问题是：一旦宿主机宕机或者进程崩溃，它就彻底没了，不会在任何地方重生。

而Deployment是 Kubernetes 中最常用的控制器（Controller），它的核心使命就是：

确保集群中始终运行着你所期望数量的、健康的 Pod 副本。

如果说 Pod 是“棋子”，那 Deployment 就是“棋手”。

---

第一部分：为什么必须要有 Deployment？

1. 自主式 Pod 的痛点（生产环境的灾难）

1. 无法自愈：Node 挂了，Pod 就消失了。
2. 无法扩容：流量大了，你只能手动kubectl apply再创几个 Pod。
3. 无法更新：你想换一个新版本的镜像，只能先删旧 Pod，再创新 Pod，期间服务会中断。
4. 无法回滚：更新搞挂了，没法一键回到上一个版本。