kubectl create deployment 适合快速验证，但生产环境必须用 YAML：它支持版本管理、滚动更新、回滚及完整资源配置（如 Service、探针、资源限制），而命令行方式生成的无状态资源缺乏可维护性与可复现性。
直接用 kubectl create deployment 最快，但生产环境必须写 YAML；跳过 YAML 直接命令行部署，后续无法做版本管理、滚动更新或回滚。
用 kubectl create deployment 快速验证
适合本地开发或临时测试，不涉及 Service、ConfigMap 等复杂依赖时可用：
- 执行
kubectl create deployment nginx --image=nginx:alpine会自动创建 Deployment + ReplicaSet + Pod - 默认只起 1 个副本，不暴露端口，不能从外部访问
- 它生成的是“无状态”资源，没有
selector或template.labels的显式定义，kubectl 内部帮你补全了，但你没法查或改 - 后续想加 Service？得手动
kubectl expose deployment nginx --port=80 --type=NodePort，不能和 Deployment 绑定管理
必须写 YAML：Deployment + Service 是最小完整单元
线上或可复现环境，YAML 是唯一可靠方式。两个文件缺一不可：
-
deployment.yaml定义应用副本、镜像、健康检查（livenessProbe）、资源限制（resources.requests）等 -
service.yaml定义如何访问——用ClusterIP（集群内）还是NodePort（宿主机端口映射），别漏掉selector，必须和 Deployment 的spec.selector.matchLabels完全一致 - 示例关键字段对齐：
deployment.spec.template.metadata.labels.app: myapp→service.spec.selector.app: myapp，错一个字母就找不到后端 - 不写
imagePullSecrets却拉私有仓库镜像？Pod 会卡在ImagePullBackOff
部署后卡在 Pending 或 ContainerCreating？先看这三处
不是配置写错，就是底层资源或权限没到位：
- 运行
kubectl describe pod <pod-name>，重点看 Events 区域：FailedScheduling表示节点没资源或亲和性不满足；FailedMount多半是 Secret/ConfigMap 名字拼错或没创建 - 节点磁盘满、inodes 耗尽、或者
docker/containerd进程僵死，都会让 Pod 卡在ContainerCreating，用kubectl get nodes -o wide看STATUS和AGE，再登录节点查df -h和systemctl status containerd - Pod 启动后立即 Crash？用
kubectl logs <pod-name> --previous查上一轮日志，常见原因是容器启动命令失败、端口被占、或环境变量缺失导致进程退出
真正麻烦的从来不是写几行 YAML，而是 label 对不上、selector 漏配、namespace 没指定、或者节点根本没准备好——这些地方不报语法错误，但整个链路就断了。
