一块慢盘，瘫了半张核心网：5GC云原生排障复盘

概述：2026年，国内主要运营商的5GC控制面基本完成了虚拟化/容器化改造，AMF、UDM、NRF这些“大脑”网元，如今都跑在Kubernetes集群和分布式存储之上。但运维的手册还停留在“看网元告警、查信令跟踪”的老时代——当地基（存储、节点）出问题时，故障会以“网元抽风”的假面目出现。本文以一个脱敏复合案例为主线，复盘一次“AMF反复重启、用户批量掉线”的深夜故障：值班如何被假病因带偏、K8s的默认机制如何放大事故、最终如何在存储层抓到真凶，并给出可落地的分层治理清单。

目录

• 一、故障当夜：一场教科书式的“假病因”
• 二、云化核心网：故障分层的新地图
• 三、K8s的善后逻辑：为什么雪崩要等五分钟
• 四、存储层：最容易被忽视的地基
• 五、复盘：四步定位法
• 六、治理清单：把下一次雪闷在摇篮里
• 七、老运维的三点感悟
• 参考来源

一、故障当夜：一场教科书式的“假病因”

先说清楚：这是一个脱敏复合案例，由多起真实的云化核心网故障模式合成，环境细节做了改写，但每一步的技术机制都有据可查，文末附官方文档来源。场景是一家省公司的5GC控制面资源池：约40个K8s worker节点、Ceph分布式存储做持久卷，AMF容量池3副本、UDM/NRF若干，承载全省约两千万用户的NAS信令。

时间线如下：

这起故障最典型的特征，不是它有多复杂，而是每一层都在撒谎：网元层报“AMF重启”，看起来是软件问题；值班的第一反应是回滚版本——这是传统NFV时代养成的肌肉记忆。但版本回滚动了一轮pod调度，反而加剧了恢复风暴。真正的病灶在三层之下：一块服役四年的HDD盘，在当晚的备份窗口叠加数据恢复流量后，延迟飙升，拖垮了跑在其上持久卷里的AMF实例。

二、云化核心网：故障分层的新地图

传统核心网运维，故障树是“网元-单板-链路”三级；云化之后，变成五层。任何一层的故障，都会向上“翻译”成网元层的语言报出来，这就是假病因的来源。

flowchart TD
    A["业务层<br/>用户掉线附着慢"] --> B["网元层<br/>AMF重启N2闪断"]
    B --> C["K8s平台层<br/>Pod驱逐节点NotReady"]
    C --> D["存储层<br/>Ceph慢OSD慢请求"]
    C --> E["硬件层<br/>HDD老化网络闪断"]
    D --> F["真凶<br/>一块慢盘拖垮全池"]
    E --> F

五层的典型现象与定位手段，整理成一张对照表：

很多省公司的现状是：无线专业、核心网专业、IT云资源池专业分属三个部门，告警系统各管一段。网元告警一响，核心网值班先跳起来，而底层存储的慢请求提示根本没接到核心网的告警清单里。这起故障里，23:41的Ceph慢请求如果当时就能联动到核心网值班，后头两个小时基本可以省掉。

三、K8s的善后逻辑：为什么雪崩要等五分钟

这起故障里有一个当时所有人都没想通的细节：worker-07在23:47就出了问题，为什么AMF实例直到快00:00才开始大规模漂移重建，而业务恢复又拖到了凌晨三点半？

答案在Kubernetes的节点故障处理机制里，官方文档写得清清楚楚，但大多数通信运维从没读过：

• 心跳：每个节点的kubelet默认每10秒更新一次Lease对象（放在kube-node-lease命名空间），这就是节点的“脉搏”。
• 判死：node controller等不到心跳，超过node-monitor-grace-period（默认40秒），就把节点标成NotReady。
• 驱逐：节点NotReady后，默认还要再等约5分钟，节点上的pod才开始被驱逐、到别的节点重建。
• 限速：驱逐不是一拥而上，controller-manager默认以每秒0.1个节点的速率限流驱逐，防止大规模故障时雪崩。

这四条默认值拼起来，就是一个运维必须背下来的结论：一个节点猝死，它上面的网元pod要等40秒+5分钟才会“搬家”，搬完家还要重连SCTP、重建N2、恢复服务注册。对电信业务来说，5G核心网的AMF哪怕抖一分钟，全省在移动性管理中的用户都可能被波及；而K8s的默认参数是为互联网业务设计的，对它来说5分钟的收敛不算事。

还有一条更反直觉的：很多团队给AMF配了PodDisruptionBudget（PDB），以为就有了“驱逐保护”。但官方文档明确写着——PDB只保护自愿中断（比如kubectl drain这种计划内维护），对节点宕机这种非自愿中断完全不设防。节点一死，pod该驱逐还是驱逐，PDB拦不住。把PDB当成节点故障保险，是云化核心网运维里流传最广的误解之一。

顺带把PDB的正确用法说透：它的字段只有两个，minAvailable（驱逐后至少保住几个pod）和maxUnavailable（最多允许挂几个），百分比按向上取整。官方给的典型场景恰恰是ZooKeeper、etcd这类有状态应用——保住仲裁数即可。映射到核心网：AMF池3副本配minAvailable: 2，保证计划内维护时至少两副本在线；但别指望它管节点猝死。

四、存储层：最容易被忽视的地基

网元副本数做3、跨机架反亲和、PDB配齐——这些团队都做了，为什么还是瘫了三个多小时？因为最后一公里倒在存储上。

虚拟化核心网的有状态数据（AMF上下文备份、UDM签约缓存、日志卷）大多落在Ceph这类分布式存储的RBD卷上。Ceph对慢盘有一套健康告警机制：当OSD的请求处理时间明显偏慢时，集群健康状态会打出slow ops类的提示（用ceph health detail能看到具体哪些OSD拖了后腿）。问题在于，慢请求是“温馨提示”不是“红色警报”，在23:41的备份窗口里，它淹没在几千条日常告警里没人看见。

慢盘对有状态NF的杀伤链条是这样的：

flowchart TD
    A["HDD老化IO延迟飙升"] --> B["RBD卷写延迟变大"]
    B --> C["AMF写日志与状态超时"]
    C --> D["实例OOM重启"]
    D --> E["pod漂移重建<br/>全池恢复流量涌入"]
    E --> F["Ceph雪上加霜<br/>其他卷跟着变慢"]
    F --> G["更多实例抖动<br/>全池降容"]

注意第5、6步：pod漂移本身会制造存储压力。三个AMF实例在几分钟内先后在其他节点重建，重建要读旧卷、写新状态、灌日志，恢复流量瞬间把本就吃紧的Ceph池打满，于是“一个慢盘”升级成“全池变慢”。这就是云化故障和传统故障最大的不同——传统设备故障是线性的，坏一块板坏一个网元；云化故障是会自我放大的，恢复动作本身可能成为第二次故障的引信。

另一个隐形地雷是“同池不同命”：信令面的卷和大吞吐的日志卷、备份卷共用一个Ceph池，没有QoS隔离。日志卷吃IO，信令卷就得挨饿。硬盘不区分你的业务优先级，谁重谁先到。

五、复盘：四步定位法

这起故障走完弯路之后，团队把排障过程沉淀成一个四步法，后来在另一次类似故障里十分钟定位。核心思想一句话：云化核心网排障，从下往上查，而不是从上往下猜。

flowchart TD
    A["网元批量异常"] --> B["第一步<br/>看K8s事件流"]
    B --> C{"有Pod驱逐<br/>或节点NotReady?"}
    C -->|有| D["查节点硬件与心跳"]
    C -->|没有| E["查网元自身日志"]
    D --> F["第二步<br/>查存储健康"]
    F --> G{"有慢请求<br/>或OSD异常?"}
    G -->|有| H["隔离慢盘限恢复带宽"]
    G -->|没有| I["查网络与宿主机"]
    E --> I
    H --> J["第三步<br/>观察恢复流量"]
    J --> K["第四步<br/>确认业务回满"]

四步各自的关键动作：

1. 看K8s事件流：kubectl get events --sort-by=.lastTimestamp按时间拉通看，pod重启、驱逐、调度失败的原始记录都在这里。网元日志说“我自己重启了”，事件流会告诉你“是谁把你搬走的”。这次的误判，就是只看了网元日志没看事件流。
2. 查存储健康：ceph health detail看有没有慢请求提示，ceph osd perf看各OSD的apply/commit延迟是否分化——健康池里各盘延迟应在一个量级，一块盘比同伴慢一个数量级，就是它。
3. 管住恢复流量：定位后第一动作不是“赶紧搬”，而是限流着搬——控制pod重建并发，给Ceph的恢复带宽设上限，避免恢复风暴二次伤害。
4. 确认回满：别看“告警清了”就收工，要看AMF池容量、附着成功率、寻呼时延回到基线，确认没有隐性欠账（比如半死不活的长尾会话）。

六、治理清单：把下一次雪闷在摇篮里

事故之后，团队落了七条整改，按“事前-事中-事后”整理成表，供云化核心网的同行直接对照自查：

其中投入产出比最高的两条：信令面存储换NVMe（一次改造，消灭最大单点诱因）和慢请求告警上浮（零成本，把发现时间从两小时压到两分钟）。标准允许多种实现，各厂家云化方案的平台组件形态有差异，具体参数以各厂家官方文档为准，但上面这套分层思想是通用的。

七、老运维的三点感悟

第一，云化没有消灭故障，只是把故障翻译成了另一门语言。 老一代运维看得懂单板灯、信令码，新一代必须同时看得懂K8s事件流和Ceph健康报告。这门新语言的词汇量不大——节点心跳40秒、驱逐5分钟、PDB只管自愿中断、慢请求要盯OSD延迟分化——但每个词都值得背下来。

第二，“副本数够”不等于“高可用够”。 三副本的AMF，可以同时踩在同一块慢盘撑起的同一个Ceph池上。高可用不是数pod，是数故障域：存储池算一个域，机架算一个域，供电算一个域。域没分开，副本就是同一枚硬币的三个面。

第三，恢复动作本身要当故障对待。 这次事故真正拉长的两个小时，一半是回滚误判，一半是不受控的恢复风暴。以后深夜处理云化故障，我的第一问永远是：“我们现在做的这个动作，会不会成为下一个故障？”在传统网元时代这是多虑，在云上这是必修课。

5G-A时代核心网在继续向云原生深处走，将来还有边缘UPF的分布式云节点要运维。地基的故障只会更多，不会更少——趁下一次深夜告警响起之前，把K8s的默认参数背熟，把存储池的分域画清楚，才是真功夫。

参考来源

1. Kubernetes官方文档：Nodes与节点心跳机制 — node-monitor-grace-period默认40秒、Lease心跳每10秒、节点失联后默认约5分钟开始驱逐pod、驱逐限速默认每秒0.1节点等机制与默认值，均出自该文档的Node heartbeats与node controller章节
2. Kubernetes官方文档：配置PodDisruptionBudget — PDB只保护自愿中断、minAvailable/maxUnavailable语义与向上取整规则、以ZooKeeper等有状态应用保仲裁数为例的官方建议
3. Ceph官方文档：OSD故障排查 — 慢请求（slow ops）类健康提示的成因与OSD级排查手段，ceph health detail/ceph osd perf等命令出处
4. 本文案例为脱敏复合案例，时间线与省份数据已改写；文中涉及各厂家云化核心网平台的具体实现差异不在本文讨论范围，以各厂家官方文档为准

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。