Pod是Kubernetes最小可调度单元，由一个或多个共享网络、存储和生命周期的容器组成；其状态包括Pending、Running、Succeeded、Failed、Unknown；常用操作有kubectl run、exec、logs、delete；调度受nodeSelector、affinity、taints/tolerations、resources影响；排查启动失败需先kubectl describe查看Events，再检查镜像、资源、配置及日志。
Kubernetes 中 Pod 是最小的可调度单元，管理好 Pod 是集群稳定运行的基础。 它不是独立运行的进程，而是由一个或多个紧密关联的容器组成的逻辑主机，共享网络、存储和生命周期。理解 Pod 的创建、状态、调度机制和常见问题处理方式，是日常运维和应用部署的核心能力。
Pod 的生命周期与状态解析
Pod 从创建到终止会经历多个阶段，Kubelet 持续监控并上报其状态。常用状态包括：
- Pending：已提交但尚未被调度（如资源不足、镜像拉取中、节点未就绪）
- Running：已绑定到节点，且至少一个容器正在运行（含初始化容器完成）
- Succeeded：所有容器成功退出且不会重启（多见于 Job）
- Failed：至少一个容器以非零码退出，且不满足重启策略
- Unknown：节点失联或状态无法获取（需检查 kubelet 或网络）
通过 kubectl get pods 查看简略状态，用 kubectl describe pod <name></name> 查看事件（Events）和容器详细状态，这是定位启动失败最直接的方式。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
手动管理 Pod 的常用操作
虽然生产环境推荐使用控制器（如 Deployment）管理 Pod，但调试和临时任务仍需直接操作：
- 创建临时 Pod：
kubectl run debug-pod --image=busybox:1.35 -- sleep 3600 - 进入容器执行命令：
kubectl exec -it debug-pod -- sh（注意指定容器名若 Pod 含多个容器） - 查看日志：
kubectl logs debug-pod；查看前 10 行：kubectl logs debug-pod --tail=10；跟踪实时日志：kubectl logs -f debug-pod - 删除 Pod：
kubectl delete pod debug-pod（控制器会自动重建，除非是裸 Pod）
影响 Pod 调度的关键配置
Kubernetes 默认使用默认调度器将 Pod 分配到合适节点，但可通过以下方式干预调度行为：
-
节点选择器（nodeSelector）：要求 Pod 只能运行在带指定 label 的节点上，例如
disktype: ssd - 亲和性与反亲和性（affinity）：比 nodeSelector 更灵活，支持软硬约束，比如“尽量和某类服务部署在同一可用区”或“避免和数据库 Pod 同节点”
- Taints 和 Tolerations：给节点打“污点”，只有带对应“容忍”的 Pod 才能调度上去，常用于专用节点（如 GPU 节点、系统组件节点）
- 资源请求（requests）与限制（limits）：决定 Pod 是否能被调度（requests 影响调度决策）、是否会被 OOMKilled（limits 影响 cgroup 限制）
排查 Pod 启动失败的典型路径
当 Pod 卡在 Pending 或 CrashLoopBackOff，按顺序检查：
- 运行
kubectl describe pod <name></name>，重点看 Events 区域（如 “FailedScheduling”、“ImagePullBackOff”、“Failed to pull image”） - 确认镜像名称是否正确、仓库是否可达、是否需要 secret 拉取私有镜像
- 检查节点资源是否充足（
kubectl describe nodes查看 Allocatable 和 Used） - 验证容器启动命令和参数是否合法（如 CMD 不存在、挂载路径错误、权限不足）
- 若为 CrashLoopBackOff，先查日志：
kubectl logs <pod> --previous</pod>（上一次崩溃的日志）
