Deployment怎么用？K8s应用部署与副本管理

Deployment是Kubernetes中最常用的应用部署资源。对于无状态服务，团队通常不会直接创建Pod，而是通过Deployment声明镜像版本、副本数量、标签选择器、更新策略和Pod模板。Deployment再管理ReplicaSet，由ReplicaSet维护Pod副本数量。这个分层模型让K8s应用部署具备可重复、可回滚和可持续交付的基础。

如果说Pod是应用运行实例，那么Deployment就是应用发布意图。它回答的是：我希望这个应用用哪个版本运行、需要几个副本、如何升级、失败后如何恢复。理解Deployment怎么用，是从“能把容器跑起来”走向“能稳定发布应用”的关键一步。

Deployment、ReplicaSet与Pod的关系

Deployment不直接承载业务流量，它管理ReplicaSet；ReplicaSet不负责发布策略，它负责让指定数量的Pod持续存在；Pod才是实际运行应用容器的地方。当Deployment模板发生变化，例如镜像版本从1.0升级到1.1，Kubernetes会创建新的ReplicaSet，并按策略逐步增加新Pod、减少旧Pod。

这种设计把职责拆开了。Deployment关注版本与发布，ReplicaSet关注副本数量，Pod关注运行实例。排障时也要顺着这条链路：先看Deployment是否可用，再看ReplicaSet是否创建，再看Pod是否调度和启动成功。

在Kubernetes实践中，Deployment通常与Service、Ingress、ConfigMap、Secret和监控告警一起使用，构成一套完整的应用上线单元。对初学者而言，先掌握Deployment和Service的配合，再扩展到配置、安全和流量治理，会更容易形成体系。

一个基础Deployment长什么样

下面是一个简化示例，展示无状态Web服务的基本部署方式：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-demo
  template:
    metadata:
      labels:
        app: web-demo
    spec:
      containers:
        - name: web
          image: example/web-demo:1.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080

这个配置包含几个关键点。replicas表示期望副本数；selector用于关联ReplicaSet与Pod模板，必须与模板标签匹配；template描述Pod内容；readinessProbe用于判断Pod是否能接收流量。生产环境还应补充资源请求、限制、livenessProbe、镜像拉取策略和安全上下文。

副本管理如何保障可用性

Deployment通过ReplicaSet实现副本管理。假设期望副本数为3，如果某个Pod异常退出或所在节点不可用，ReplicaSet会发现实际副本少于期望值，并创建新的Pod补齐。这个过程体现了Kubernetes的期望状态模型。

副本数不是越多越好。它应结合业务并发、单实例容量、节点资源、可用区分布和发布策略评估。对于核心服务，至少要避免单副本成为故障点；对于资源密集型任务，则要防止盲目扩容导致节点资源耗尽。

常用操作包括：

kubectl scale deployment web-demo --replicas=5 -n production
kubectl get deployment web-demo -n production
kubectl get pods -l app=web-demo -n production

如果业务流量变化明显，可以进一步结合水平自动扩缩容，但前提是应用具备无状态扩展能力，并且资源指标、监控链路和容量基线相对可靠。

滚动更新与回滚怎么理解

Deployment默认使用RollingUpdate策略。升级镜像时，Kubernetes不会一次性删除所有旧Pod，而是按maxSurge和maxUnavailable控制新旧副本切换。maxSurge表示更新过程中可额外创建的Pod数量，maxUnavailable表示允许不可用的Pod数量。合理配置这两个参数，可以在资源占用和服务可用性之间取得平衡。

例如，副本数为4、maxSurge为1、maxUnavailable为1时，更新过程中最多可以临时存在5个Pod，同时最多允许1个不可用。新Pod通过readinessProbe后，旧Pod才会逐步退出。如果新版本无法就绪，滚动更新会停滞，避免继续扩大影响面。

常用发布和回滚命令如下：

kubectl set image deployment/web-demo web=example/web-demo:1.1 -n production
kubectl rollout status deployment/web-demo -n production
kubectl rollout undo deployment/web-demo -n production

需要注意，回滚依赖Deployment历史记录，但回滚不应替代发布前验证。镜像标签、配置变更、数据库迁移和依赖服务都可能影响回滚效果。生产发布应结合灰度策略、监控告警和变更窗口综合设计。

Deployment与Service如何配合

Deployment负责创建和维护Pod，Service负责为Pod提供稳定访问入口。由于Pod会重建，IP会变化，调用方不能直接依赖Pod地址。Service通过标签选择器匹配一组Pod，并提供稳定的ClusterIP或外部入口。

这也意味着Deployment的标签设计必须谨慎。selector一旦创建后不宜频繁修改，否则可能导致ReplicaSet无法正确关联Pod，Service也可能选不中目标实例。建议至少区分app、component、version、environment等维度，但不要过度复杂化。

如果应用涉及入口流量，还需要配合Ingress或网关。如果涉及东西向访问、服务发现和网络隔离，则要结合容器网络与Kubernetes容器专题继续完善。

生产环境配置检查清单

Deployment能否稳定运行，往往取决于细节。下面这些配置不一定每个场景都完全相同，但应在上线前逐项评估。

资源与调度

为容器设置requests和limits，让调度器知道应用需要多少资源，也让节点在资源压力下有清晰边界。核心服务还可以结合节点亲和性、拓扑分布约束和Pod反亲和，降低多个副本集中在同一故障域的风险。

健康检查

readinessProbe决定Pod是否接收流量，livenessProbe决定容器是否需要重启，startupProbe适合启动慢的服务。探针路径应反映应用真实可用性，不能只检查进程是否存在。

发布策略

根据业务可用性要求配置maxSurge和maxUnavailable。高可用服务通常需要保证更新期间仍有足够副本可用；资源紧张场景则要控制额外副本带来的节点压力。

配置与密钥

不要把环境差异写死在镜像中。普通配置放入ConfigMap，敏感信息放入Secret，并结合权限控制和变更审计。配置更新是否触发Pod重启，也要有明确策略。

常见问题与排查思路

如果Deployment显示不可用，先查看状态条件，确认是ProgressDeadlineExceeded、MinimumReplicasUnavailable还是ReplicaFailure。然后查看ReplicaSet和Pod事件，判断是否为镜像拉取失败、资源不足、探针失败或调度失败。

如果滚动更新卡住，重点检查新Pod是否Ready。常见原因包括新版本启动失败、readinessProbe路径错误、依赖服务不可达、配置缺失或端口变更。此时不要急于删除旧Pod，应先保留现场，通过describe和logs定位。

如果Service访问不到Deployment创建的Pod，检查Service selector是否与Pod labels一致，再检查targetPort是否匹配容器端口。很多访问问题并不是Deployment本身异常，而是标签、端口或网络策略不一致。

总结：Deployment是K8s应用发布的主入口

Deployment是K8s无状态应用部署的核心资源，它通过ReplicaSet维护Pod副本，通过滚动更新控制版本切换，通过回滚能力降低发布风险。掌握Deployment怎么用，不只是会写YAML，更重要的是理解副本、标签、探针、资源、Service和发布策略之间的关系。

在生产环境中，建议把Deployment配置纳入代码仓库和发布流水线，结合评审、测试、监控和告警形成闭环。这样，K8s应用部署才能从一次性上线动作，演进为可治理、可追踪、可恢复的持续交付能力。