Kubernetes生产运维01：告警来了先别急着重启，生产故障如何一步步缩小范围

写在前面

凌晨收到一条接口超时告警，值班群里很快出现几个方向：有人怀疑Redis，有人准备重启Pod，还有人认为刚完成的发布应该立即回滚。

这时最危险的并不是暂时不知道根因，而是每个人根据第一印象同时执行不同操作。Pod被删掉以后，previous日志可能丢失；工作负载被整体重启以后，异常节点上的连接状态被改变；多个变量一起变化，即使业务恢复，也很难确认究竟是哪一步起了作用。

生产故障排查不能依赖一次猜中。更可靠的方式是：

先判断影响和恢复优先级
→ 保存容易消失的现场
→ 从服务、Pod、Node和依赖多个维度确认范围
→ 写出可以被验证的假设
→ 用正常与异常对象做对照
→ 每次只改变一个主要变量
→ 恢复后继续确认根因并补上治理措施

本文会用一次真实的Redis偶发超时事件贯穿整个过程。案例中的故障现象、关键指标、根因和修复结果来自A级脱敏生产经验；相对时间、资源名称和终端输出为了讲清排查方法进行了脱敏重建，不是原始生产记录。

---

一、第一分钟不是敲命令，而是确认事故状态

Kubernetes告警经常从一个技术对象开始，例如Pod重启、探针失败或节点指标异常。但值班人员首先要回答的是业务问题。

可以先建立一张事件卡：

事件名称：
首次告警时间：
用户现象：
受影响服务：
受影响区域或集群：
全部失败还是部分失败：
当前错误率、延迟和流量变化：
健康副本是否还能承接：
影响是否仍在扩大：
最近一次应用、配置或基础设施变更：
当前可用的回滚、切流或降级手段：
事件负责人：
记录人：

这张卡不是形式主义。它决定接下来是先恢复，还是先保存现场。

当前状态	建议优先级	原因
核心业务大面积不可用，影响仍在扩大	优先执行已验证的回滚、切流或降级	用户影响高于取证完整性
部分请求失败，但有健康实例承接	恢复和取证并行	既要控制影响，也有条件保留现场
单个实例异常，业务无明显影响	优先取证和验证	可以利用冗余寻找根因
只有潜在风险，没有用户影响	按计划分析和治理	避免临时操作制造新故障

Pod为Running，为什么业务仍可能失败

Running只表示Pod已经绑定到节点，并且至少有一个容器正在运行、启动或重启。它不能证明下面这些事情：

• 应用业务接口返回正常
• Readiness探针通过
• Service存在可用EndpointSlice
• 请求经过Ingress和Service后能够到达容器
• 容器到Redis、数据库或外部API的调用正常
• 所在节点没有局部网络或内核资源问题

因此，看到Pod为Running以后直接说Kubernetes正常，证据是不够的。

---

二、变更前先保存容易消失的现场

如果当前有冗余承接，或者恢复动作允许延迟几十秒，先保存以下信息。

NS=<namespace>
POD=<pod-name>
DEPLOY=<deployment-name>
OUT="incident-$(date +%Y%m%d-%H%M%S)"

mkdir -p "$OUT"

kubectl get pod "$POD" -n "$NS" -o yaml \
  > "$OUT/pod.yaml"

kubectl describe pod "$POD" -n "$NS" \
  > "$OUT/pod-describe.txt"

kubectl logs "$POD" -n "$NS" --all-containers --timestamps \
  > "$OUT/pod-current.log" 2>&1 || true

kubectl logs "$POD" -n "$NS" --all-containers --previous --timestamps \
  > "$OUT/pod-previous.log" 2>&1 || true

kubectl get events -n "$NS" \
  --field-selector involvedObject.name="$POD" \
  --sort-by='.lastTimestamp' \
  > "$OUT/pod-events.txt"

kubectl get deployment "$DEPLOY" -n "$NS" -o yaml \
  > "$OUT/deployment.yaml"

kubectl rollout history deployment/"$DEPLOY" -n "$NS" \
  > "$OUT/rollout-history.txt"

这里需要注意四点：

1. --previous只有容器存在上一次终止实例时才有内容，命令失败不代表集群异常。
2. Events有保留周期，且不同版本字段可能存在差异，应尽早保存。
3. 当前日志未必包含崩溃前信息，应用日志还可能位于独立平台。
4. YAML中可能包含环境变量、镜像地址和Secret引用，归档与分享前必须脱敏。

如果核心业务已经大面积中断，不应为了跑完整脚本而延迟恢复。最低限度保存当前版本、Pod分布、关键Events和监控截图，然后执行已有Runbook中的低风险恢复动作。

---

三、先确认故障范围，再讨论故障原因

范围判断比原因枚举更有价值。一个超时可以有几十种原因，但如果异常只发生在同一台Node，很多方向会立刻降低优先级。

3.1 从四个维度做第一轮切分

维度	需要回答的问题	常见指向
工作负载	单个Pod、同一Deployment还是多个服务	容器、发布、公共依赖
节点	异常是否集中在同一Node或同一节点池	kubelet、运行时、内核、网络
时间	是否与发布、配置或节点操作同步	变更关联，但仍需验证
请求	全部请求还是特定接口、租户或依赖	业务路径、数据或下游服务

先查看工作负载和节点分布：

kubectl get deployment,pod -n <namespace> -o wide

kubectl get pod -n <namespace> \
  -l app=<app-label> \
  -o custom-columns='NAME:.metadata.name,READY:.status.containerStatuses[*].ready,PHASE:.status.phase,NODE:.spec.nodeName,POD_IP:.status.podIP'

重点不是把输出贴进群里，而是进行分组：

异常Pod是否属于同一版本
异常Pod是否集中在同一Node
同一Node上的其他服务是否也有异常
正常Pod和异常Pod访问的是不是同一依赖
异常开始时间是否一致

3.2 检查Service后端，但不要过早深入组件内部

kubectl get service <service-name> -n <namespace> -o yaml

kubectl get endpointslice -n <namespace> \
  -l kubernetes.io/service-name=<service-name> \
  -o wide

关注以下内容：

• Service的selector是否能匹配目标Pod标签
• port和targetPort是否与应用实际监听一致
• EndpointSlice中是否存在后端地址
• Endpoint的ready状态是否为true
• 异常是否只发生在某个后端或某台Node

判断分支如下：

EndpointSlice为空
→ 检查Selector、Pod Label和Readiness

Endpoint存在但只有部分后端异常
→ 对比Pod版本、日志、Node和依赖调用

所有后端都正常，Service访问仍失败
→ 分别验证Pod直连与Service访问，再检查网络策略、代理链路或节点网络

第01篇只说明如何选择方向。Service、EndpointSlice和网络链路的具体诊断会在第06篇展开。

---

四、建立相对时间线，但不要把最近变更直接当根因

下面是一条为了说明方法而重建的相对时间线，不代表原事故的精确时间：

T-30分钟  应用完成常规发布
T+00分钟  Redis超时告警首次出现
T+03分钟  多个微服务出现零星超时日志
T+08分钟  确认Redis服务端指标没有同步恶化
T+15分钟  发现异常Pod集中在部分Node
T+22分钟  对比发现异常Node的TCP分配连接持续增长
T+35分钟  受控迁移一个工作负载实例并观察
T+50分钟  排查方向转向公共Redis客户端依赖
后续        开发确认连接释放问题，升级依赖后持续观察未再复现

时间接近只能提高某个假设的优先级。例如，发布发生在故障前，不等于新版本一定是根因。至少还要继续问：

• 新旧版本是否都出现异常
• 异常是否与Node分布更相关
• 回滚以后指标是否按预期恢复
• 发布内容是否涉及连接池、依赖版本或网络调用
• 同一公共依赖的其他服务是否出现类似现象

一个高质量时间线应该同时放入告警、变更、证据和操作，而不是只记录运维执行了哪些命令。

---

五、用假设表控制排查方向

排障过程中最容易发生的是，先认定Redis有问题，然后只收集Redis异常的证据。更稳妥的方式是把支持和矛盾证据同时写下来。

当前假设	支持证据	矛盾证据	下一项验证	风险
Redis服务端负载异常	应用日志报Redis超时	Redis资源和服务端连接状态未见同步异常	对齐服务端指标与超时窗口	只读
Pod到Redis网络不通	超时发生在连接阶段	Pod内基础连通测试可以成功，且不是所有Pod都异常	比较正常与异常Pod的节点分布和TCP调用	只读
部分Node存在连接资源异常	异常集中在部分Node	Node仍为Ready	对比节点sockstat、ss -s和应用分布	只读
公共客户端依赖未正确释放连接	多服务共用依赖，异常Node连接分配持续上涨	暂无代码层直接证据	开发检查连接生命周期，并升级依赖做受控验证	需要发布

这个表格有三个作用：

1. 把事实和推测分开。
2. 强迫排障者寻找反证。
3. 让下一位接手的人知道为什么要执行下一条命令。

---

六、真实案例：Redis超时如何收敛到Node层

6.1 已确认的生产事实

这次事件中可以确认的事实是：

• 部分微服务偶发Redis连接超时
• Redis服务端运行正常
• 从Pod进行基础网络检查可以连通
• 异常并非同时发生在所有Pod
• 异常Pod所在的部分Node上，node_sockstat_TCP_alloc持续增长
• 正常Pod所在Node的同一指标保持稳定
• 多个微服务使用统一的Redis客户端依赖
• 开发最终确认底层网络调用存在连接未正确释放的问题
• 升级公共依赖后，超时问题未再出现
• 运维补充了节点TCP分配连接及增长趋势监控

为了避免过度推断，还要明确三件事：

• 基础网络可以连通，不代表长连接使用过程没有间歇性问题。
• Node为Ready，不代表该节点上的每条应用网络连接都健康。
• node_sockstat_TCP_alloc上涨是一条重要线索，不能单独证明客户端代码存在Bug。

6.2 为什么先排查Redis服务端

应用日志明确指向Redis超时，先验证服务端是合理的，但验证目标应该具体：

超时窗口内，Redis是否发生资源饱和
连接数是否接近限制
服务端延迟是否同步升高
拒绝连接、阻塞客户端或错误日志是否增加
主从切换、网络抖动或维护事件是否发生

如果服务端指标与应用超时在时间上没有对应关系，就要降低Redis服务端故障的优先级，而不是继续重复查看同一批日志。

这里没有给出固定CPU、连接数或延迟阈值，因为阈值取决于实例规格、客户端数量和业务基线。生产判断应比较故障前基线、故障窗口和正常时段。

6.3 为什么基础连通成功仍不能结束网络排查

ping验证的是ICMP可达性，不能证明Redis TCP端口和应用协议正常。更有意义的是从正常Pod和异常Pod分别执行相同的TCP或协议级检查。

# TCP端口检查，需要容器中存在nc
nc -vz -w 3 <redis-host> 6379

# 协议级检查，需要容器中存在redis-cli并使用合规凭据
redis-cli -h <redis-host> -p 6379 PING

命令成功只能证明测试时刻的一次连接成功，不能排除偶发超时。还需要把测试结果与以下维度关联：

• Pod所在Node
• 请求发生时间
• 客户端连接池状态
• 超时类型是建立连接、读取还是写入
• 正常Pod与异常Pod是否使用同一配置和版本

6.4 从Pod分布发现Node差异

kubectl get pod -n <namespace> \
  -l app=<app-label> \
  -o custom-columns='POD:.metadata.name,NODE:.spec.nodeName,POD_IP:.status.podIP,READY:.status.containerStatuses[*].ready'

kubectl get pod -A \
  --field-selector spec.nodeName=<suspected-node> \
  -o wide

第一条命令用于对比同一应用的正常与异常Pod。第二条命令用于确认疑似Node上是否还有其他工作负载出现相似现象。

如果不同应用只要落到同一批Node就更容易超时，排查重点应该从单个Deployment转向Node、内核网络状态和公共依赖。如果异常仍然只跟某个应用版本相关，则应返回发布和代码路径。

6.5 对比Node的TCP状态

Node Exporter的sockstat采集器从Linux procfs socket统计中导出node_sockstat_TCP_alloc，其指标HELP文本将它描述为TCP socket处于alloc统计项的数量。Linux节点可通过/proc/net/sockstat核对原始字段。它是Gauge，不等同于ESTABLISHED连接数，也不等同于conntrack表使用量。

还可以先从Node Exporter端点确认当前版本实际暴露的指标定义：

curl -s http://<node-exporter-address>:9100/metrics \
  | grep -E '^# (HELP|TYPE) node_sockstat_TCP_alloc|^node_sockstat_TCP_alloc'

不同Node Exporter版本、操作系统和采集器配置可能影响指标是否存在，应以目标环境的/metrics输出为准。

先在Prometheus中比较节点：

node_sockstat_TCP_alloc

观察趋势时可以使用：

deriv(node_sockstat_TCP_alloc[30m])

deriv用于观察一段窗口内Gauge的线性变化趋势。这里的30分钟只是查询示例，生产窗口应根据故障速度和抓取间隔调整，不能把deriv > 0直接做成所有环境通用的告警。

在获得授权并能够登录Node时，可以进一步交叉验证：

cat /proc/net/sockstat
ss -s
ss -tan state established | wc -l
ss -tan state time-wait | wc -l

说明性输出示例：

TCP: inuse 1840 orphan 12 tw 920 alloc 3860 mem 510

这不是原事故输出。读取时要关注各字段是否随时间持续变化，并将异常Node与同节点池的正常Node做对照：

• alloc上涨但established不同比例上涨，需要继续检查连接生命周期和socket状态分布
• time-wait大量增加，要结合短连接创建速度、端口范围和应用行为分析
• orphan异常，要继续检查内核日志、连接关闭行为和资源压力
• 如果所有Node同步上涨，优先检查全局流量变化或公共发布，而不是单台Node故障

如果怀疑conntrack耗尽，需要单独检查，不能拿sockstat代替：

sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

部分环境没有加载对应模块或没有该路径，云厂商托管节点的可见性也可能不同。

6.6 如何做受控迁移验证

将Pod迁移到其他Node后恢复，可以增强Node关联假设，但这是变更操作，不应直接在生产环境批量执行。

操作前至少确认：

kubectl get deployment <deployment-name> -n <namespace>
kubectl get pdb -n <namespace>
kubectl top nodes
kubectl get pod -A --field-selector spec.nodeName=<suspected-node> -o wide

需要确认：

• Deployment有多个健康副本
• Readiness能够正确摘除未就绪实例
• PDB允许当前驱逐
• 其他Node有足够容量
• Pod没有不可丢失的本地数据
• 当前操作不会同时影响多个关键服务

一种较小影响的验证方式是：先将疑似Node标记为不可调度，再只删除一个由控制器管理且有健康冗余的异常Pod，观察新Pod调度到其他Node后的表现。

kubectl cordon <suspected-node>

kubectl delete pod <one-managed-pod> -n <namespace>

kubectl get pod -n <namespace> -w -o wide

风险说明：

• cordon只阻止新Pod调度，不会迁移已有Pod。
• delete pod会改变现场，只适用于控制器管理、有冗余且确认可重建的Pod。
• 不要一次删除全部异常Pod，否则会同时改变多个变量并可能造成容量问题。
• 验证完成且节点允许继续使用时，可执行kubectl uncordon <suspected-node>回退调度状态。

kubectl drain会驱逐节点上的多个工作负载，影响范围更大。本案例的方法论不把它作为首轮验证动作。需要维护节点时，应单独检查DaemonSet、PDB、本地数据、关键单副本服务和集群剩余容量。

6.7 从Node证据回到公共代码依赖

异常Node上的TCP socket持续增长，说明排查方向已经从Redis服务端缩小到客户端侧连接行为，但还没有完成根因证明。

下一步需要应用与开发团队共同回答：

哪些服务使用同一个Redis客户端或公共jar包
连接池是否按预期复用连接
异常、超时和取消路径是否执行关闭逻辑
最近是否升级过客户端、网络库或公共框架
连接创建速率与关闭速率是否匹配
依赖升级后，应用错误和Node socket趋势是否同时恢复

最终，开发确认公共依赖的底层网络调用没有正确释放连接。升级依赖后持续观察，Redis超时不再出现，节点TCP分配连接趋势也恢复正常。这时，代码确认、修复动作和修复后观察共同组成了比单一指标更完整的证据链。

---

七、修复要区分六个层次

层次	本案例中的处理	边界
应急止损	将受影响工作负载受控迁离异常Node	只能降低当前影响
现场取证	保存Pod分布、日志、事件和节点指标	不能替代根因分析
根因验证	对比正常与异常Node，并由开发检查连接生命周期	需要基础设施与代码证据配合
永久修复	升级公共Redis客户端依赖	必须经过发布验证和持续观察
监控预防	增加TCP分配连接及增长趋势监控	阈值需要按节点基线确定
运行治理	将Node对照和socket检查加入超时Runbook	后续仍需定期演练

这里最容易误写的是：迁移Pod后恢复，所以根因是Node网络故障。

准确的表述应该是：迁移后的结果支持问题与原Node状态相关；Node指标对照进一步指向客户端TCP连接行为；最终由代码分析、依赖升级和修复后观察确认连接释放问题。

---

八、监控如何从单点指标升级为可行动告警

只给node_sockstat_TCP_alloc设置一个固定阈值，容易产生两类问题：大规格节点正常连接多而误报，小规格节点已经异常却没有达到统一阈值。

更实用的设计应结合：

1. 当前值是否明显偏离该Node的历史基线
2. 是否在连续窗口内持续上涨
3. 同节点池其他Node是否保持稳定
4. 应用连接超时或错误率是否同步升高
5. established、time-wait、conntrack和端口使用是否出现对应变化

查询示例：

node_sockstat_TCP_alloc

max_over_time(node_sockstat_TCP_alloc[30m])
-
min_over_time(node_sockstat_TCP_alloc[30m])

第二个表达式观察窗口内波动范围，但它也不能直接代表泄漏。生产告警可以先以较低等级触发调查，并在Runbook中要求同时检查应用错误和socket状态，而不是自动隔离Node。

一份可行动的告警说明至少应包含：

告警对象：哪个Node
持续时间：增长了多久
当前值与基线：偏离程度
关联业务：该Node上有哪些关键Pod
第一轮检查：sockstat、ss、应用错误率和Pod分布
升级条件：是否伴随用户影响或连接失败
禁止动作：未经容量与PDB检查不得直接drain

---

九、常见误区以及为什么不可靠

误区1：看到Redis超时就认定Redis故障

超时只描述客户端观察到的结果。服务端、客户端连接池、Node、网络路径和DNS都可能参与。

误区2：Pod为Running就排除Kubernetes和Node

Running的语义有限。必须继续检查Ready、Endpoint、节点分布和业务指标。

误区3：一次连通测试成功就排除网络

一次测试只证明测试时刻和测试路径成功，不能覆盖间歇性连接问题。

误区4：指标上涨就直接命名为连接泄漏

指标是线索。还要查看socket状态、正常对照、应用行为和代码路径。

误区5：上来就重启全部Pod或drain节点

这会改变现场、扩大影响，并让验证失去单变量条件。

误区6：服务恢复后停止分析

恢复只解决当前影响。没有永久修复和监控，下次仍会以同样方式发生。

---

十、可直接使用的首轮排障清单

影响与组织
[ ] 确认用户现象、受影响服务和事件等级
[ ] 确认影响是否仍在扩大，健康副本是否承接
[ ] 指定事件负责人和记录人
[ ] 决定先止损、并行处理还是先取证

现场与变更
[ ] 保存Pod YAML、describe、当前日志和previous日志
[ ] 保存Events、工作负载版本和发布历史
[ ] 对齐应用、配置、节点和云基础设施变更
[ ] 标注哪些时间和输出是原始记录

范围收敛
[ ] 确认异常是单Pod、单工作负载还是多个服务
[ ] 对比正常与异常Pod的版本、Node和可用区
[ ] 检查Service、EndpointSlice和Readiness
[ ] 检查同一Node上的其他工作负载
[ ] 对齐外部依赖指标与故障窗口

假设与验证
[ ] 写出当前假设、支持证据和矛盾证据
[ ] 选择最能区分假设的下一项检查
[ ] 每次验证只改变一个主要变量
[ ] 变更前确认副本、PDB、容量、数据和回退路径
[ ] 记录操作结果是否符合预期

恢复与闭环
[ ] 区分临时恢复和永久修复
[ ] 恢复后继续验证根因
[ ] 补充监控、告警和Runbook
[ ] 记录复盘行动项、负责人和完成时间

证据记录模板

已确认事实：
当前假设：
支持证据：
矛盾证据：
下一项验证：
预期结果A及后续方向：
预期结果B及后续方向：
操作风险：
回退方式：
实际结果：
结论置信度：
仍缺少的信息：

---

十一、面试怎么说

60秒方法论版本

我处理Kubernetes生产故障时，第一步不是直接看日志或重启Pod，而是确认业务影响、故障范围和是否需要先止损。如果有冗余承接，我会先保存Events、日志、版本和Pod分布，再按业务入口、Service、Pod、Node和外部依赖分层采集证据。我会把当前假设、支持证据和矛盾证据写出来，优先选择最有区分度的下一项验证，并使用正常与异常对象做对照。变更操作前检查副本、PDB、容量和回退路径，每次尽量只改变一个变量。业务恢复以后继续确认根因，再补监控、Runbook和复盘行动项。

3分钟案例版本

我遇到过一次多个微服务偶发Redis连接超时。应用日志首先指向Redis，但服务端指标没有对应异常，从Pod做基础连通测试也能成功。我们没有继续只盯Redis，而是对比正常与异常Pod的分布，发现问题集中在部分Node。随后对比Node Exporter指标，异常Node上的node_sockstat_TCP_alloc持续增长，正常Node保持稳定。这个指标不能单独证明代码Bug，但它把范围从Redis服务端收敛到了客户端侧TCP连接行为。多个异常服务又共用同一个Redis客户端依赖，因此由开发继续检查连接生命周期，最终确认底层调用没有正确释放连接。我们先受控迁移工作负载降低影响，再升级公共依赖完成永久修复，并补充节点TCP连接趋势监控和排障Runbook。这个案例让我形成的习惯是，先确认范围，再通过对照证据切换观察层级，不能让第一条错误日志锁死排查方向。

---

十二、延伸问答

1. Events、日志和指标应该先看哪个

没有固定顺序。Pod未调度时优先看调度Events；容器反复退出时看状态、退出码和previous日志；多个服务集中在同一Node异常时应尽早看节点指标。顺序由当前范围和假设决定。

2. 什么时候可以直接重启Pod

核心业务中断且重启是经过验证的恢复手段时，可以优先止损。影响可控时，应先保存容易消失的现场。无论哪种情况，都要确认副本、数据、依赖和回退风险。

3. 最近有发布，是否应该立即回滚

如果影响严重、发布时间高度相关且回滚路径已经验证，回滚可以作为止损动作。但从根因角度，仍需比较版本差异和回滚后的指标，不能仅凭时间接近宣布发布是根因。

4. Node为Ready，为什么还要查Node

Ready主要反映kubelet上报的节点健康条件。局部丢包、socket异常、conntrack压力、特定网卡路径或应用连接行为不一定立刻让Node变为NotReady。

5. node_sockstat_TCP_alloc高就说明连接泄漏吗

不能。它表示已分配TCP socket数量，需要结合趋势、基线、socket状态、正常Node对照、业务错误和应用连接生命周期分析。

6. 迁移Pod后恢复能够证明什么

它支持故障与原Node环境相关，但不能单独区分内核、网络、运行时、节点负载和应用连接状态。还需要继续采集证据。

7. 多人同时排障怎样避免混乱

指定事件负责人统一决策，设置记录人维护时间线；每个排查方向有明确负责人；所有变更先报备影响、预期和回退；结论进入共享证据表，而不是散落在聊天记录中。

---

小结

1. 生产故障先判断业务影响，再决定止损和取证顺序。
2. Running、一次连通成功和单一指标都只能证明有限范围的事实。
3. 先按工作负载、Node、时间和请求路径确认范围，再枚举原因。
4. 每个假设都要同时记录支持证据、矛盾证据和下一项验证。
5. 正常与异常对象的对照，往往比继续堆积同类日志更有区分度。
6. 受控迁移能够验证Node关联，但不能独立证明最终根因。
7. 完整处理包括止损、取证、根因、永久修复、监控和复盘。

下一篇预告

下一篇进入kubectl排障工具箱，重点不是背命令，而是说明get、describe、logs、events、top、debug和jsonpath分别适合回答什么问题，如何组合使用，以及常见输出应该怎样判断。

参考资料

1. Kubernetes官方文档：Monitoring, Logging, and Debugging
2. Kubernetes官方文档：Debug Pods
3. Kubernetes官方文档：Debug Running Pods
4. Kubernetes官方文档：Debug Services
5. Kubernetes官方文档：Troubleshooting Clusters
6. Prometheus官方文档：Monitoring Linux host metrics with the Node Exporter
7. Node Exporter源码：sockstat Linux collector
8. Kubernetes官方文档：Pod Lifecycle