在 Kubernetes 中，执行创建命令并不等于服务已就绪。本文演示如何创建一个最小化的 nginx Deployment，并通过检查 Deployment 的 READY 与 AVAILABLE 字段，以及 Pod 的 Running 状态来确认工作负载是否真正可用。当遇到 Pending 或 CrashLoopBackOff 等异常时，可通过查看事件和日志快速定位是调度、镜像拉取还是应用启动阶段的问题。
执行前确认集群上下文和命名空间
在创建资源前，务必确认当前操作的环境。执行 kubectl config current-context 确认当前操作的集群，再用 kubectl get namespace 检查目标命名空间。公司或共享集群上，请先确认你有权创建 Deployment；本地 minikube、kind 或测试集群则更适合第一次练习。
不要把命名空间省略当成理所当然。省略 -n 时通常使用当前上下文的默认命名空间；如果稍后查询时切换了命名空间，就会出现“刚创建的资源不见了”的假象。
创建一个单副本 nginx Deployment
第1步：使用明确的名称和镜像
在测试命名空间执行 kubectl create deployment nginx-demo --image=nginx。nginx-demo 是 Kubernetes 资源名，nginx 是容器镜像。实际项目应根据组织要求固定镜像标签，避免漂移版本导致后续执行结果不一致。
命令返回 deployment.apps/nginx-demo created 后不要立即结束。Deployment 控制器还需要创建 ReplicaSet 和 Pod，节点也需要拉取镜像并启动容器。第一次拉取镜像的时间会受网络和节点缓存影响，不应假设固定秒数内完成。
用 READY 和 AVAILABLE 完成双层验收
第2步：查看 Deployment 汇总状态
执行 kubectl get deployment nginx-demo。单副本练习中，READY 最终应为 1/1，UP-TO-DATE 与 AVAILABLE 应为 1。如果 READY 暂时为 0/1，先查看 Pod 状态，不要反复执行创建命令造成同名冲突。
第3步：检查 Pod 是否进入 Running
执行 kubectl get pods -l app=nginx-demo。-l 用标签筛选与当前 Deployment 相关的 Pod，避免在资源较多的命名空间中看错对象。目标状态是 READY 1/1、STATUS Running，并且 RESTARTS 没有持续增长。
查看 Pod 详细状态时识别所属对象
第4步：通过标签与所有者定位资源关系
需要进一步确认时，可对具体 Pod 执行 kubectl get pod POD_NAME -o yaml，或使用 kubectl describe pod POD_NAME。重点核对标签、ownerReferences、容器镜像与事件，这些信息能回答“该 Pod 由谁管理”以及“为什么还没有就绪”。
根据 Pod 状态选择排错入口
当 Pod 未进入 Running 状态时，可根据具体状态选择排查方向：
- Pending：通常先查看调度事件，确认节点资源、污点或持久卷等条件。
- ImagePullBackOff：检查镜像名、标签、网络与私有仓库凭据。
- CrashLoopBackOff：查看容器日志和启动命令，不要只删除 Pod，因为控制器会按原配置再创建一个。
READY 长时间为 0/1：如果状态已是 Running，继续检查就绪探针和容器内部应用；不要把 Running 等同于业务已可用。本练习使用官方 nginx 镜像作为最小示例，真实服务还应配置资源限制、探针和发布策略。
总结 Deployment 的最小完成闭环
正确的入门顺序是：确认集群上下文和命名空间，创建名称明确的 Deployment，再分别查看 Deployment 汇总状态和 Pod 运行状态。READY、AVAILABLE 与 Running 都达到预期后，才可以把该资源记为创建成功。
