K8s高频运维命令速查表：节点Pod网络存储排查

发布人：发布时间：5 天前阅读量：36

Kubernetes 日常运维中，真正消耗时间的往往不是“会不会”，而是“命令记不记得住”。同一类故障，有经验的工程师会按固定顺序抓取信息：先看节点状态，再看 Pod 生命周期，接着查网络连通性，最后落到存储与事件日志。本文按这个排查链条，把高频使用的 kubectl 与相关命令做分类汇总，便于在故障现场快速定位，也适合作为团队内部的运维速查参考。

一、节点排查：先确认“地基”是否稳固

节点异常会直接表现为 Pod 调度失败、驱逐或大面积不可用。排查时应先确认节点是否 Ready，以及资源压力、污点和标签情况。

常用命令

查看节点总览：kubectl get nodes -o wide，关注 STATUS、VERSION、内网 IP 与容器运行时。
查看节点详情：kubectl describe node ，重点看 Conditions、Taints、Allocatable 与已分配资源。
实时查看节点资源：kubectl top node，需要集群已部署 metrics-server。
查看节点事件：kubectl get events -A --field-selector involvedObject.name=，用于定位 DiskPressure、MemoryPressure 等。
查看污点与标签：kubectl get node -o jsonpath='{.spec.taints}'，排查 Pod 无法调度时的常见原因。
节点隔离与恢复：kubectl cordon 停止调度新 Pod，kubectl drain --ignore-daemonsets --delete-emptydir-data 安全驱逐，维护完成后 kubectl uncordon 恢复。

若节点状态长时间为 NotReady，除了 describe 节点外，还需登录节点检查 kubelet 与容器运行时状态，这一步属于节点侧排障，不能仅依赖 kubectl。

二、Pod 排查：从生命周期到容器内部

Pod 是运维中最常打交道的对象。建议固定顺序：状态 → 详情 → 事件 → 日志 → 进入容器。

状态与详情

kubectl get pods -n -o wide：查看状态、重启次数、所在节点。
kubectl get pods -A --field-selector status.phase!=Running：快速筛出非 Running 的 Pod。
kubectl describe pod -n ：Events 段通常直接给出 ImagePullBackOff、CrashLoopBackOff、调度失败等原因。
kubectl get pod -o yaml：查看完整 spec、状态与最后终止原因。

日志与执行

kubectl logs -n -c ：多容器 Pod 需指定容器。
kubectl logs --previous：查看上一次崩溃容器的日志，排查重启原因的关键命令。
kubectl logs -f --tail=200：实时跟踪，限制行数避免刷屏。
kubectl exec -it -n -- sh：进入容器内部验证配置与连通性。
kubectl debug -it --image= --target=：临时容器调试，适合镜像精简无常用工具的场景。

工作负载与扩缩

kubectl rollout status deployment/ -n ：观察发布进度。
kubectl rollout history deployment/ -n 与 kubectl rollout undo deployment/ --to-revision=：查看与回滚版本。
kubectl scale deployment/ --replicas= -n ：手动扩缩容。
kubectl top pod -n --containers：查看各容器资源占用，辅助判断 OOM 与资源不足。

三、网络排查：Service、DNS 与连通性

网络问题的表象常是“服务访问不通”，但原因可能出在 Service 选择器、端点、DNS、NetworkPolicy 或宿主机转发规则。建议自内向外逐层验证。

Service 与 Endpoint

kubectl get svc,endpoints -n ：确认 Service 是否有对应的 Endpoints。
kubectl describe svc -n ：核对 Selector、Port、TargetPort 与 Endpoints 列表。
kubectl get endpointslices -n ：在较新版本中替代 Endpoints 排查后端地址。
kubectl get ingress -A 与 kubectl describe ingress -n ：检查域名、路径与后端 Service 映射。

DNS 与连通性验证

kubectl run dnstest --rm -it --image= -- nslookup .：验证集群 DNS 解析。
在业务 Pod 内执行 curl -v .: 或 nc -zv ，区分解析失败与端口不通。
kubectl get networkpolicy -n ：确认是否存在限制流量的策略。
kubectl get pods -n kube-system：检查 CoreDNS、网络插件（CNI）组件是否正常。

若 Pod 内部正常、跨节点异常，通常需要进一步检查 CNI 插件日志与节点转发规则；此类问题已超出 kubectl 单工具范围，应结合节点侧网络诊断命令判断。

四、存储排查：PV、PVC 与挂载失败

存储类故障多表现为 Pod 处于 Pending、ContainerCreating，或容器启动后读写报错。

kubectl get pv,pvc -A：查看存储卷与声明的状态、容量与绑定关系。
kubectl describe pvc -n ：Events 中常出现等待绑定、StorageClass 不存在、动态供给失败等提示。
kubectl get storageclass：确认 StorageClass 是否存在、是否为默认。
kubectl get pod -o jsonpath='{.spec.volumes}'：核对卷定义与挂载路径。
进入容器执行 df -h、mount，确认挂载是否生效及剩余空间。
查看存储插件控制器日志，例如 kubectl logs -n kube-system ，定位后端存储侧错误。

需要区分的是：PVC 一直 Pending 多为供给或调度问题；Pod 卡在 ContainerCreating 多为挂载未就绪；容器内读写失败则可能是权限、文件系统或后端存储异常。

五、事件、日志与全局视角

前四类排查都绕不开事件与日志。养成先看 Events 的习惯，能显著缩短定位时间。

kubectl get events -A --sort-by=.lastTimestamp：按时间排序查看全集群事件。
kubectl get events -n --field-selector type=Warning：只看告警事件。
kubectl get all -n ：快速了解命名空间内资源全貌。
kubectl api-resources 与 kubectl explain .：确认资源类型与字段含义。
kubectl config view 与 kubectl config current-context：确认当前集群与上下文，避免误操作。
kubectl -n get pod -o jsonpath='{.status.containerStatuses[*].restartCount}'：精确获取重启次数。