Deployment 是 Kubernetes 中管理无状态应用的核心资源对象，本质上通过控制 ReplicaSet 持续将 Pod 副本数维持在预期状态，同时支持滚动更新、版本回滚与弹性伸缩；在实际使用中要特别注意 selector 与 template 中的标签必须完全一致。项目落地时，通常更推荐使用 YAML 配置文件方式创建 Deployment，并配合 Service 一起完成应用发布与访问。
Deployment 是 Kubernetes 里最常见、最实用的应用部署方式之一。它通过声明式配置定义 Pod 的目标状态，再由控制器自动完成 Pod 的创建、更新、调度维护以及副本数量保持，适合大多数无状态服务的部署场景。
Deployment 的核心作用
Deployment 并不是直接管理 Pod，而是先管理 ReplicaSet，再由 ReplicaSet 负责控制 Pod 的生命周期。因此，Deployment 天然具备滚动更新、版本回滚、扩容缩容等能力，是 Kubernetes 部署无状态应用的标准方案。
- 确保指定数量的 Pod 副本持续稳定运行，例如
replicas: 3 - 支持平滑滚动升级：新版本 Pod 逐步替换旧版本，尽量避免服务中断
- 保留历史版本记录，方便在发布异常时快速执行回滚
- 可与 Service 配合使用，实现稳定的服务发现、负载分发和访问入口
两种常用创建方式
创建 Kubernetes Deployment 时，既可以通过命令行快速生成，也可以编写 YAML 文件进行更细致的配置管理。
- 命令行一键创建：适合临时测试、学习演示或简单部署场景
kubectl create deployment nginx-app --image=nginx:1.27 --replicas=2 - YAML 文件定义：更推荐用于生产环境，便于版本控制、团队协作和重复复用
编写deploy.yaml，其中包含 apiVersion、kind、metadata、spec（如 replicas、selector、template）等关键字段；然后执行kubectl apply -f deploy.yaml
关键配置要点
一份可正常运行的 Deployment YAML，至少要满足“标签匹配一致”和“Pod 模板配置正确”这两个关键要求，否则部署应用时很容易出现关联失败或创建异常。
- selector.matchLabels 必须与 template.metadata.labels 完全一致，否则 Deployment 无法正确关联和管理对应的 Pod
- replicas 用于指定期望运行的 Pod 数量，Kubernetes 会持续对比实际状态并自动修复副本偏差
- containerPort 表示容器内部监听端口，主要用于声明，不会自动将服务暴露到集群外部
- 如果需要对外提供访问能力，还必须额外创建 Service，例如 ClusterIP、NodePort 等类型
后续常用操作
Deployment 部署完成后，可以通过常见的 kubectl 命令查看运行状态、更新镜像版本、调整副本数并执行回滚维护。
- 查看状态：
kubectl get deploy、kubectl get pods -l app=xxx - 更新镜像：
kubectl set image deploy/nginx-app nginx=nginx:1.28 --record - 扩缩容：
kubectl scale deploy/nginx-app --replicas=4 - 回滚：
kubectl rollout undo deploy/nginx-app或指定版本--to-revision=2
从操作流程来看，Kubernetes Deployment 部署应用并不算复杂，真正容易出问题的往往是一些细节配置。比如 selector 和 template 的标签一旦不一致，Deployment 就可能无法正确匹配 Pod，最终导致应用实例创建失败，但表面上未必会出现特别直观的错误提示。YAML 编写完成后，建议先使用 kubectl apply --dry-run=client -o yaml 进行预检，把格式、字段和逻辑关系提前校验清楚，这样能明显减少上线时的排错成本。
