5分钟全面认识 K8s：Deployment 详解

在前一篇里，我们已经了解了 Pod 是 K8s 的最小调度单元。

这一篇我们继续往下走，看看 Deployment 为什么几乎是生产环境里最常用的工作负载对象。 $1$ $3$ $4$

Deployment 的核心作用是：声明你想要多少个 Pod、如何更新、如何回滚，以及在异常时如何保持应用稳定。 $1$ $3$ $4$

一、Deployment 是什么

Deployment 是 Kubernetes 中用于管理无状态应用的工作负载对象。 $1$ $3$ $4$

你可以通过它声明应用副本数、镜像版本、更新策略等，Kubernetes 会根据这些声明自动创建和维护底层 Pod。 $1$ $3$ $4$ 简单说：

● 你写的是 Deployment

● K8s 实际管理的是它背后的 ReplicaSet 和 Pod

● 你关心的是 应用是否按预期运行 $1$ $3$ $4$

二、为什么需要 Deployment

如果你直接创建 Pod，Pod 挂了之后通常不会自动补回来，也很难方便地做滚动更新和回滚。 $1$ $3$ $4$

Deployment 解决的正是这个问题：它让你不需要手工盯着 Pod 的生命周期，而是通过声明式方式持续维护目标状态。 $1$ $3$ $4$ 它带来的能力主要有：

● 副本管理

● 滚动更新

● 版本回滚

● 弹性扩缩容

● 自我修复 $1$ $3$ $4$

三、Deployment 和 ReplicaSet 的关系

Deployment 并不直接管理 Pod，而是通过 ReplicaSet 间接管理 Pod。 $1$ $3$ $4$

Deployment 负责描述"我要什么样的应用状态"，ReplicaSet 负责保证指定数量的 Pod 一直存在。 $1$ $3$ $4$ 你可以把它们理解成：

● Deployment：总指挥

● ReplicaSet：执行副本维护

● Pod：真正跑应用的实例 $1$ $3$ $4$

当你更新 Deployment 时，Kubernetes 通常会创建一个新的 ReplicaSet，再逐步替换旧 Pod，这就是滚动更新的基础。 $1$ $3$ $4$

四、Deployment 的核心字段

一个 Deployment 的 YAML 里，最重要的字段一般包括：

● metadata：名称、标签、命名空间等

● spec.replicas：副本数

● spec.selector：选择哪些 Pod 归它管理

● spec.template：Pod 模板

● spec.strategy：更新策略 $1$ $3$ $4$

其中最关键的是 template。

因为 Deployment 本质上不是"一个容器配置"，而是"一个创建 Pod 的模板"。 $1$ $3$ $4$ **

五、Deployment 是怎么工作的**

当你提交一个 Deployment 资源后，Kubernetes 会执行一套持续调谐流程。 $1$ $3$ $4$

大致过程是：

● API Server 接收 Deployment 配置

● 配置被保存到集群状态中

● 控制器发现新的 Deployment

● 创建对应的 ReplicaSet

● ReplicaSet 根据副本数创建 Pod

● Scheduler 为 Pod 选择节点

● kubelet 在节点上拉起容器 $1$ $3$ $4$

这个过程不是一次性的，而是持续运行的。

只要实际状态和你定义的期望状态不一致，控制器就会继续修正。 $1$ $3$ $4$ **

六、Deployment 的滚动更新**

Deployment 最常用的能力之一就是滚动更新。 $1$ $3$ $4$

当你把镜像版本从 v1 改成 v2，Kubernetes 不会把旧版本全部停掉再一次性启动新版本，而是按策略逐步替换，尽量保证服务可用。 $1$ $3$ $4$

滚动更新的好处是：

● 降低停机风险

● 支持平滑升级

● 出问题时更容易回滚 $1$ $3$ $4$

常见更新参数包括：

● maxUnavailable：更新过程中最多允许多少 Pod 不可用

● maxSurge：更新过程中最多允许额外新增多少 Pod $1$ $3$ $4$

这两个参数决定了升级过程是"更稳"还是"更快"。

七、Deployment 的回滚

如果新版本有问题，Deployment 允许你回滚到旧版本。 $1$ $3$ $4$

这是生产环境特别重要的能力，因为它可以把故障恢复时间压缩得很短。 $1$ $3$ $4$ 回滚的本质，是让 Deployment 再次把期望状态切回旧的配置。

**Kubernetes 会根据历史版本记录重新恢复之前的 ReplicaSet 和 Pod 状态。 $1$ $3$ $4$ **八、Deployment 的扩缩容

Deployment 也负责扩缩容。 $1$ $3$ $4$

你可以手动修改副本数，也可以结合 HPA 让系统根据 CPU、内存或自定义指标自动伸缩。 $1$ $3$ $4$ 例如：

● 流量上来时扩容

● 流量下降时缩容

这让应用具备更好的资源利用率和弹性。 $1$ $3$ $4$

九、Deployment 适合什么场景

Deployment 主要适合无状态应用。 $1$ $3$ $4$

也就是那种 Pod 之间可以相互替换、状态不依赖本地磁盘、任意实例都能处理请求的应用。常见例子包括：

● Web 服务

● API 服务

● 后台无状态任务

● 前端服务 $1$ $3$ $4$

如果应用需要稳定身份、固定存储、稳定网络标识，通常就更适合看 StatefulSet，而不是 Deployment。 $1$ $3$ $4$

十、Deployment 和直接创建 Pod 的区别

对比项	直接创建 Pod	使用 Deployment
副本管理	需要手动处理	自动维护
故障恢复	能力弱	支持自愈
滚动更新	不方便	原生支持
回滚	不方便	原生支持
生产可用性	较弱	更适合生产

Deployment 的价值就在于：

它不是只创建一个 Pod，而是持续保证一组 Pod 的目标状态。 $1$ $3$ $4$

十一、你可以怎么理解 Deployment

你可以把 Deployment 理解成"应用的长期管理器"。

● 它不关心某一个 Pod 具体是谁，而是关心：你要几个实例

● 你要什么版本

● 更新时怎么切换

● 出问题时怎么恢复 $1$ $3$ $4$

这就是 Kubernetes 的声明式管理哲学：

不是你去盯容器，而是系统按照你的目标去维持容器。 $1$ $3$ $4$

十二、这一篇最值得记住的三句话

● Deployment 是管理无状态应用的核心对象

● Deployment 通过 ReplicaSet 间接管理 Pod

● 滚动更新、回滚、扩缩容，都是 Deployment 的典型能力 $1$ $3$ $4$

下一篇我们就讲：Service 详解，看看 K8s 是怎么解决 Pod IP 不稳定、服务发现和流量转发问题的。