使用 kubectl 创建 Deployment 部署应用的具体步骤是什么？

把一个容器化应用部署到 Kubernetes 集群上，最常规的做法就是创建一个 Deployment。Deployment 负责维护一组相同的 Pod 副本，并在 Pod 挂掉时自动拉起新实例，同时支持滚动更新和版本回滚。kubectl 作为操作 Kubernetes 的命令行工具，提供了命令式和声明式两种创建 Deployment 的途径，本文把两种方式都拆开讲清楚，并附上部署后的验证、扩缩容与回滚操作。

一、用 kubectl run 和 create 命令快速创建

最直接的方式是使用 kubectl create deployment 命令。例如要部署一个 nginx 应用并指定副本数为 3，执行下面这条命令即可：

kubectl create deployment nginx-app --image=nginx:1.25 --replicas=3

这条命令会在当前命名空间创建一个名为 nginx-app 的 Deployment，镜像使用 nginx:1.25，并维护 3 个 Pod 副本。如果你希望把它部署到指定命名空间，可以加 -n 参数，例如 -n production；如果命名空间还不存在，先用 kubectl create namespace production 创建。

还有一种更简短的方式是 kubectl run，例如：

kubectl run nginx-app --image=nginx:1.25 --replicas=3

不过需要注意，在新版本 Kubernetes 中，kubectl run 默认只会创建单个 Pod 而不是 Deployment，除非显式加上 --restart=Always 等参数。因此在生产实践中，更推荐使用 kubectl create deployment 或者直接编写 YAML 文件，语义更明确，也不容易踩坑。

命令式创建的优点是快，适合临时验证、本地测试。缺点是所有配置散落在命令参数里，没有留存的配置文件，后期审计、复现和版本管理都不方便。一旦命令敲完，这个部署就没有可以追溯的源头文件了。

二、编写 YAML 资源清单做声明式部署

声明式方式是先把期望状态写成 YAML 文件，再交给 kubectl apply 应用到集群。一个最小可用的 Deployment 配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi

这里有几个关键字段必须理解清楚。spec.selector.matchLabels 声明了这个 Deployment 管理哪些 Pod，它必须和 spec.template.metadata.labels 匹配，否则创建时会直接报错，这是新手最常遇到的问题之一。replicas 指定期望副本数，template 定义 Pod 模板，包含容器镜像、端口和资源限制。

把上面的内容保存为 deployment.yaml，然后执行：

kubectl apply -f deployment.yaml

声明式方式的核心优势在于可重复执行。kubectl apply 是幂等的，配置文件改了之后再执行一次即可完成增量更新，集群状态会向文件中声明的期望状态收敛。整个部署过程有文件留档，可以放进 Git 做版本管理，这就是常说的 GitOps 基础实践。团队协作、生产环境部署，都应该优先采用这种方式。

还有一个实用技巧：如果想基于现有运行中的命令式创建结果反向生成 YAML，可以用 kubectl create deployment nginx-app --image=nginx:1.25 --dry-run=client -o yaml > deployment.yaml，先生成模板再手工调整字段，比从零手写效率高，也不容易漏掉必填项。

三、验证部署状态与后续运维操作

创建完成后，第一步是确认 Deployment 是否就绪：

kubectl get deployments
kubectl get pods -l app=nginx
kubectl describe deployment nginx-app

关注 READY 列，格式为就绪副本数/期望副本数。如果长时间停留在 0/3，用 kubectl describe pod 和 kubectl logs 排查，常见原因包括镜像拉取失败、资源配额不足、端口冲突等。还可以用 kubectl rollout status deployment/nginx-app 盯住滚动过程，直到输出 successfully rolled out。

扩缩容只需要一条命令：

kubectl scale deployment nginx-app --replicas=5

更新镜像则使用 kubectl set image deployment/nginx-app nginx=nginx:1.26，Kubernetes 会按 RollingUpdate 策略逐个替换 Pod，保证服务不中断。如果新版本有问题，回滚同样简单：

kubectl rollout history deployment/nginx-app
kubectl rollout undo deployment/nginx-app

第一条命令查看历史版本记录，第二条回滚到上一版本，也可以加 --to-revision 回到指定版本。这种版本管理能力正是 Deployment 相比直接管理 Pod 的核心价值所在：它把发布、回滚变成了可编排、可审计的标准动作，而不是手工删 Pod 再重建的野蛮操作。

总结一下，临时验证用命令式创建足够快，正式环境请坚持 YAML 加 kubectl apply 的声明式路线，再配合 rollout 系列命令管理版本，一套完整的部署流程就成型了。

kubectlDeploymentKubernetes部署修改时间：2026-09-07 05:14:27