Kubernetes入门：用kubectl创建并查看第一个Deployment

执行前确认集群上下文和命名空间

在创建资源前，务必确认当前操作的环境。执行 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 都达到预期后，才可以把该资源记为创建成功。