kubectl get pods -o wide 是查看 Pod 所在节点的首选方式，因其直接显示真实调度结果的 NODE 列，不依赖调度策略生效与否，且比 describe 更快、适合批量操作。
直接用 kubectl get pods -o wide 就能看到 Pod 所在的节点主机名，这是最常用也最可靠的方式。
为什么 -o wide 是首选
默认 kubectl get pods 只显示名称、状态、重启次数等基础字段，不包含节点信息。加上 -o wide 后会额外输出 NODE 列，值就是该 Pod 实际运行的 Node 名称（即 spec.nodeName 字段值）。
- 这个值是调度器最终写入 Pod 对象的，真实反映运行位置，不是推测或标签匹配结果
- 不依赖
nodeSelector或亲和性配置是否生效，哪怕调度失败处于Pending状态，只要已分配节点，NODE列就非空 - 比
kubectl describe pod更快，适合批量查看或脚本解析
kubectl describe pod 查看详细调度信息
当需要确认调度原因、失败细节或验证 nodeSelector 是否匹配成功时，describe 更有用。
- 运行
kubectl describe pod，在Events区域可看到类似Scheduled Successfully assigned default/demo-pod-1 to k8s-node1的日志 - 若 Pod 卡在
Pending，Events里通常会明确提示原因，比如0/3 nodes are available: 3 node(s) didn't match node selector. -
Node:行显示当前绑定的节点（与-o wide一致），Node-Selectors:行则列出 Pod 定义中要求的标签条件
节点名称 vs 物理机 IP 或主机名
kubectl get nodes -o wide 返回的 INTERNAL-IP 和 EXTERNAL-IP 才对应物理网络地址，而 get pods -o wide 中的 NODE 列只是节点对象的 metadata.name —— 它可能和主机名一致，也可能被手动设为别名（如 k8s-worker-01）。
- 要查某节点的真实 IP，执行
kubectl get node-o wide - 如果 Pod 调度到了
k8s-node1，但你想知道它背后是哪台服务器，就得结合get node的输出或集群部署文档 - 不要假设
NODE列等于hostname；Kubernetes 不强制二者一致，尤其在云厂商托管集群中常见差异
注意 nodeName 字段绕过调度器的特殊情况
如果 Pod YAML 中显式写了 nodeName: xxx，那它根本不会经过 kube-scheduler，而是直接绑定到指定节点。此时 get pods -o wide 显示的节点名就是硬编码值，即使该节点当前不可达或不存在，Pod 状态也会卡在 ContainerCreating 或报错 FailedScheduling（取决于节点是否真的离线）。
- 这种写法无法 fallback，也不检查资源是否足够，仅适用于调试或极简单节点环境
-
nodeSelector则仍走调度流程，会做标签匹配 + 资源评估，失败时留有排查空间 - 生产环境强烈建议用
nodeSelector或nodeAffinity替代nodeName，避免因节点名变更或下线导致 Pod 永久 Pending
