一、Pod 调度与运行时问题#

Pod 一直卡在 Pending 状态，是大多数人遇到的第一个 Kubernetes 故障。调度失败的原因看起来很多，资源不足、亲和性冲突、污点不匹配、拓扑约束，但它们的共同特征只有一个：调度器找不到一个愿意接纳这个 Pod 的节点。理解这一点，排查就有了方向：不是去猜原因，而是去问调度器”你为什么拒绝了”。

调度器拒绝一个 Pod 时，会在 Event 中写下理由。kubectl describe pod <pod-name> 的 Events 段是最直接的诊断入口，常见的事件类型包括 FailedScheduling（调度失败）、NetworkNotReady（网络未就绪）、FailedMount（挂载失败）。这些事件不是装饰性的，它们就是调度器的”拒信”，里面写明了拒绝原因。

1
# 查看 Pod 调度事件
2
kubectl describe pod <pod-name> | grep -A 10 "Events:"
3

4
# 查看调度器日志（控制平面层面）
5
journalctl -u kube-scheduler -n 100
6

7
# 模拟调度：在目标节点上启动一个调试 Pod 验证环境是否就绪
8
kubectl debug node/<node-name> -it --image=busybox

资源不足是最常见的调度失败原因。这里的”不足”指的是节点上已被 requests 占用的资源，而不是实际使用量，Kubernetes 调度器看的是 requests 而非 usage，即使一个 Pod 实际只用了 100Mi 内存，如果它 requests 了 2Gi，调度器也会认为那 2Gi 已被占满。这是很多人困惑的根源：节点明明还有空闲内存，为什么调度不过去？因为调度器不信任运行时用量，它只信任声明值。这个设计选择有明确的工程理由：运行时用量是波动的，如果调度器基于瞬时用量做决策，刚调度完一个 Pod，另一个 Pod 的用量突然上升，节点就会超载。requests 是静态契约，调度器基于契约做决策，才能保证不超卖。

污点（Taint）和容忍（Toleration）是另一类常见的调度障碍。节点被打上污点后，只有声明了对应容忍的 Pod 才能被调度上去，这个机制的初衷是把专用节点（如 GPU 节点、Master 节点）隔离出来，但如果忘记给 Pod 添加容忍，或者污点打错了 key，就会导致调度失败。亲和性和拓扑分布约束的逻辑更复杂，但排查方法相同：读 Events。

当集群资源确实不足时，优先级抢占（PriorityClass）可以让高优先级工作负载驱逐低优先级工作负载。这不是一个应该随意使用的机制，每次抢占都会导致被驱逐的 Pod 中断服务，但在资源紧张的场景下，它保证了关键路径不被阻塞。

1
# 优先级调度
2
apiVersion: scheduling.k8s.io/v1
3
kind: PriorityClass
4
metadata:
5
  name: high-priority
6
value: 100000
7
globalDefault: false
8
description: "高优先级任务"
9

10
---
11

12
apiVersion: v1
13
kind: Pod
14
metadata:
15
  name: high-priority-app
16
spec:
17
  priorityClassName: high-priority
18
  containers:
19
    - name: app
20
      image: my-app

二、网络问题排查#

Kubernetes 网络问题的排查难度在于故障点太多：Pod 内部、Pod 到 Service、Service 到 Endpoints、跨 Namespace、跨 Node、出集群，每一层都有自己的故障模式。与其逐层枚举命令，不如建立一个从内到外的诊断流程：先确认 Pod 自身的网络栈是否正常，再查 Service 路由是否生效，最后看 NetworkPolicy 或外部网关是否阻断了流量。

第一步：确认 Pod 网络栈。进入 Pod 的网络命名空间，检查网络接口和路由表。如果 ip addr 显示网卡没分配到 IP，问题出在 CNI 插件，而不是应用；如果 ip route 缺少默认路由，Pod 连网关都到不了。CNI 插件负责为 Pod 分配 IP 和配置路由，如果 CNI Pod 本身异常（比如 Calico 的 calico-node 或 Cilium 的 Agent 崩溃），新创建的 Pod 就拿不到网络配置。

1
# 进入 Pod 网络空间
2
kubectl exec -it <pod-name> -- sh
3

4
# 检查网络接口和路由
5
ip addr
6
ip route
7

8
# 测试基本连通性
9
ping <target-ip>
10
curl -v <service-name>

第二步：检查 DNS 解析。Kubernetes 集群内部的服务发现依赖 CoreDNS。如果 nslookup <service-name> 返回 NXDOMAIN，问题可能出在 CoreDNS 本身（检查 kube-system 命名空间下 CoreDNS Pod 的状态），也可能出在 Pod 的 /etc/resolv.conf 配置，特别是 ndots 设置导致的过度搜索域查询，会让每次解析都尝试多个后缀，拖慢 DNS 响应甚至超时。ndots: 5 是默认值，意味着任何包含少于 5 个点的主机名（比如 backend、backend.default）都会依次尝试追加 backend.default.svc.cluster.local、backend.default.svc.cluster.local.<节点域> 等后缀，直到匹配或全部失败。对于短名称来说，前几次尝试必然失败，白白增加了延迟。

1
# 检查 DNS 解析
2
nslookup <service-name>
3
cat /etc/resolv.conf

第三步：Service 和 Endpoints。Service 本身不转发流量，它只是 iptables/IPVS 规则的入口。流量能否到达后端 Pod，取决于 Endpoints 是否健康。kubectl get endpoints <service-name> 如果显示空列表，说明没有 Pod 匹配 Service 的 Selector，这是最常见的 Service 故障，通常是因为标签拼写错误或 Pod 还没 Ready。

1
# 检查 Endpoints
2
kubectl get endpoints <service-name>
3

4
# 检查 Selector 匹配的 Pod
5
kubectl get pods -l app=<selector> --show-labels
6

7
# 查看 Service 详情
8
kubectl describe svc <service-name>
9

10
# 临时起一个调试 Pod 测试 Service 连通性
11
kubectl run curl --image=curlimages/curl -it --rm -- \
12
    curl -v http://<service-name>:<port>

第四步：NetworkPolicy。如果 Endpoints 健康但流量仍然不通，NetworkPolicy 是最可能的拦截者。NetworkPolicy 默认允许所有流量，一旦任何 Namespace 中存在针对某个 Pod 的 Policy，该 Pod 的入站或出站流量就必须被显式允许，这是一条容易被忽视的规则。排查时先确认是否有 Policy 存在，再检查 Policy 的 podSelector 和 ingress/egress 规则是否覆盖了你的流量路径。

1
# 检查 NetworkPolicy
2
kubectl get networkpolicy
3
kubectl describe networkpolicy <policy-name>
4

5
# 在 frontend Pod 内测试到 backend 的连通性
6
kubectl exec -it frontend -- curl -v http://backend:80

三、存储问题排查#

存储问题的表象通常很统一：Pod 启动失败或挂载卷报错。但底层原因差异很大，PVC Pending 意味着没有可用的 PV，PVC Lost 意味着绑定的 PV 被删除了，而 PVC Bound 但 Pod 无法挂载则指向 CSI 驱动或节点层面的故障。这三者的排查路径完全不同，不能一概而论。

PVC 处于 Pending 状态，首先要看的是 kubectl describe pvc 输出中的 Event。最常见的两个原因是 StorageClass 不存在（拼写错误或未安装）和 PV 不足（静态供给场景下没有可用 PV，动态供给场景下底层存储后端资源不足）。如果是动态供给，还要检查 CSI 驱动是否正常运行，驱动 Pod 挂了，Provisioner 就无法创建 PV。

1
# 查看 PVC 状态和详情
2
kubectl get pvc
3
kubectl describe pvc <pvc-name>
4

5
# 常见 PVC 状态含义
6
# Pending: StorageClass 不存在或 PV 不足
7
# Lost: PV 被意外删除
8
# Bound: PVC 已绑定，但 Pod 仍可能挂载失败

PVC Bound 但 Pod 报 FailedMount，问题出在节点层面。CSI 驱动需要在目标节点上运行 Node Plugin，负责执行实际的挂载操作。如果 Node Plugin 未运行或与存储后端的通信异常，挂载就会失败。此时需要检查 CSI 驱动 Pod 的日志，而不是继续在 PVC 上打转。

1
# 检查 StorageClass 和 PV
2
kubectl get storageclass
3
kubectl get pv
4

5
# 检查 CSI 驱动状态
6
kubectl get csidriver
7
kubectl logs -n kube-system -l app=csi-driver

四、性能分析与优化#

性能问题很少以”慢”这种清晰的方式出现，更多时候它伪装成 Pod 重启、请求超时、调度延迟等现象。定位性能瓶颈的第一步不是找优化手段，而是确认瓶颈到底在哪一层：CPU、内存、磁盘 I/O 还是网络。不同瓶颈的优化方向完全不同，搞错了方向只会浪费时间。

kubectl top 是最快的资源概览工具。但要注意，它显示的是实际使用量，而调度决策基于 requests，两者之间的差距才是性能问题的温床。一个 Pod 实际 CPU 使用 100m 但 requests 声明了 2000m，它在调度层面浪费了 1900m 的配额；反过来，实际使用 2000m 但 limits 只有 1000m，就会触发 CPU throttling，导致应用响应变慢，而 kubectl top 显示的 CPU 使用率可能并不直观地反映这一点。

1
# 查看资源使用概览
2
kubectl top nodes
3
kubectl top pods
4

5
# 按命名空间查看
6
kubectl top pods -n <namespace>
7

8
# 查看节点级别的资源分配（requests vs allocatable）
9
kubectl describe node <node-name> | grep -A 10 "Allocated resources"

CPU throttling 是一个尤其隐蔽的问题。Linux CFS 调度器通过 CFS quota 机制实现 CPU 限流：当一个容器在 quota 周期内用完了配额，它会被 throttled 直到下一个周期。这意味着即使节点 CPU 空闲，容器也会被限流，limits 是硬天花板，跟节点负载无关。很多团队发现应用延迟抖动，排查了一圈网络和依赖，最后才发现是 limits 设置过低导致的周期性 throttling。这也是为什么有些团队选择在生产环境中不设 CPU limits，让容器在节点空闲时能借用多余 CPU，只在节点资源紧张时由 CFS 自然调度。这个做法有争议（不设 limits 意味着单个容器可能独占节点 CPU），但对于延迟敏感型工作负载，它比 throttling 带来的影响更小。

内存瓶颈的表现更粗暴：直接 OOMKilled。Linux 内核在物理内存不足时触发 OOM Killer，选择占用内存最多的进程杀掉。Kubernetes 通过 limits.memory 设置容器的内存上限，容器的 memory.limit_in_bytes cgroup 参数被设为此值，超过就会被杀。和 CPU throttling 不同，内存没有”借用”机制，超了就是超了，没有缓冲期。这也是为什么内存 limits 通常需要比 CPU limits 更保守地设置：CPU throttling 只是变慢，OOMKill 是直接死亡，后者没有恢复机会。

资源请求和限制的设置没有万能公式，但有一个原则：requests 应该接近实际稳态用量，limits 应该覆盖峰值。如果 requests 过高，浪费调度空间；如果 limits 过低，运行时被限流或杀掉。很多集群的问题不是资源不够，而是资源分配不合理。确定合理值的方法是观察：用 kubectl top 收集一周的实际用量数据，P99 作为 limits 的起点，P50 作为 requests 的起点，再根据应用特性微调。

1
# 资源请求与限制：requests 看稳态，limits 看峰值
2
apiVersion: v1
3
kind: Pod
4
spec:
5
  containers:
6
    - name: app
7
      resources:
8
        requests:
9
          cpu: "500m"
10
          memory: "512Mi"
11
        limits:
12
          cpu: "2000m"
13
          memory: "2Gi"

五、应用层调试与监控联动#

集群层面的排查工具（kubectl describe、kubectl top）能定位”Pod 为什么不正常”，但无法回答”应用内部哪里出了问题”。应用层调试需要进入容器内部，使用语言特定的诊断工具。这是从运维视角切换到开发视角的转折点。

最基础的调试手段是启动一个临时工具 Pod。busybox 适合快速网络诊断，nicolaka/netshoot 则是一个功能更全的网络诊断工具箱，内置了 tcpdump、conntrack、nslookup 等常用工具。选择哪个取决于问题的复杂度，如果只是 ping 一下，busybox 就够了；如果需要抓包分析，就得用 netshoot。

1
# 轻量调试：busybox
2
kubectl run debug --image=busybox --rm -it -- sh
3

4
# 网络诊断工具箱：netshoot
5
kubectl run netshoot --rm -it --image=nicolaka/netshoot -- bash
6

7
# 常用诊断命令
8
ip link        # 网络接口
9
ip addr       # IP 地址
10
ss -tulpn    # 端口监听
11
conntrack -L  # 连接跟踪
12
tcpdump       # 抓包

对于 Go 应用，如果启动时开启了 net/http/pprof，可以直接通过 HTTP 端点获取 CPU profile 和 goroutine 堆栈。Java 应用则可以通过 jstack 获取线程堆栈、jmap 获取内存映射。这些工具的使用方式与在物理机上无异，区别在于你需要先 kubectl exec 进入容器，前提是容器镜像里包含这些工具，或者你可以用 kubectl debug 附带一个 sidecar 容器来注入调试工具。

1
# 进入目标 Pod
2
kubectl exec -it <pod-name> -- sh
3

4
# Go 应用：pprof
5
curl http://localhost:6060/debug/pprof/profile        # CPU profile
6
curl http://localhost:6060/debug/pprof/goroutine?debug=1  # goroutine 堆栈
7

8
# Java 应用
9
jstack <pid>       # 线程堆栈
10
jmap -heap <pid>   # 内存映射

前面所有排查手段都是事后响应式的，出问题了再查。在规模较大的集群中，靠人工巡检发现问题的效率极低，故障往往在造成影响后才被注意到。监控体系的价值在于缩短从故障发生到被发现的时间窗口。

不同故障类型对应不同的关键指标。调度失败关注 kube_pod_status_pending，OOMKilled 关注 container_memory_working_set_bytes，网络问题关注 container_network_receive_bytes_total 的异常变化，存储问题关注 kube_persistentvolumeclaim_status。这些指标不是孤立的，一个指标异常往往是另一个指标异常的原因或结果，关联分析才能还原完整的故障链。比如 kube_pod_status_pending 上升的同时 kube_node_status_allocatable 下降，说明是节点资源不足导致调度失败；如果 kube_pod_status_pending 上升但节点资源充足，就要去看污点和亲和性相关的指标。

六、故障案例：从症状到根因#

前面的章节按问题类型分类讨论了排查方法，但真实故障很少乖乖地待在某个类别里。这一节通过三个实际案例，展示从症状到根因的完整诊断过程。

Case 1: Pod 一直 Pending。一个名叫 my-app 的 Pod 部署后始终处于 Pending 状态。kubectl describe pod my-app 的 Events 段显示 0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had taints that the pod didn't tolerate。这条信息同时给出了两个原因：一个节点 CPU 不足，两个节点有未被容忍的污点。进一步检查 kubectl get nodes -o json | jq '.items[].spec.taints' 发现那两个节点被打了 dedicated=special-user:NoSchedule 污点，这是运维为专用工作负载预留的节点。解决方案取决于业务需求：如果 my-app 确实需要跑在这些节点上，就添加对应的 Toleration；如果不需要，就增加普通节点的资源或降低 Pod 的 requests。这里的关键不是选哪个方案，而是理解调度器已经告诉你原因了，Events 就是第一手诊断信息，不需要猜测。

1
# 检查节点污点
2
kubectl get nodes -o json | jq '.items[].spec.taints'
3

4
# 如果需要，移除污点（通常不推荐在生产环境中这样做）
5
kubectl taint node <node> dedicated=special-user:NoSchedule-

Case 2: Service 无法访问。前端 Pod 通过 curl backend:80 访问后端服务，返回 Connection timed out。按照网络排查流程，第一步检查 Endpoints：kubectl get endpoints backend 返回空列表。Endpoints 为空意味着 Service 的 Selector 没有匹配到任何 Pod。kubectl get pods -l app=backend --show-labels 发现 Pod 的标签是 app=backend-api，而 Service 的 Selector 写的是 app=backend，一个后缀差异导致了路由断裂。修复 Selector 后 Endpoints 自动填充，流量恢复。这个案例说明，网络问题不一定在网络层，很多时候只是配置不匹配。排查时先查 Endpoints 再查 NetworkPolicy，能避免在错误的方向上浪费时间。

1
# 排查步骤
2
kubectl get endpoints backend         # 空 → Selector 没匹配到 Pod
3
kubectl get pods -l app=backend --show-labels  # 发现标签不匹配
4
kubectl get networkpolicy             # 确认 NetworkPolicy 没有额外阻断

Case 3: Pod 被 OOMKilled。Pod my-app 不断重启，kubectl get pods 显示 RESTARTS: 3，状态 OOMKilled。kubectl top pod my-app 显示实际内存使用接近 limits 设置值。这里有两条可能的路径：一是应用存在内存泄漏，使用量随时间增长最终触顶；二是 limits 设置本身偏低，正常峰值就超过了限制。区分两者的方法是在调高 limits 后观察：如果内存使用持续增长不回落，是泄漏，需要修代码；如果稳定在新水平线上，是 limits 太紧，调整资源配额即可。这个区分方法看似简单，但在实际操作中经常被跳过，很多人看到 OOMKilled 就直接调大 limits，如果真是泄漏，调大只是推迟了崩溃时间。

1
# 查看重启状态
2
kubectl get pods
3
# NAME     READY   STATUS      RESTARTS   AGE
4
# my-app   0/1     OOMKilled   3          10m
5

6
# 查看实际内存使用
7
kubectl top pod my-app
8

9
# 临时调高内存限制以区分"泄漏"和"配额不足"
10
kubectl patch pod my-app -p '{"spec":{"containers":[{"name":"app","resources":{"limits":{"memory":"2Gi"}}}]}}'