# 一块慢盘，瘫了半张核心网：5GC云原生排障复盘 **概述**：2026年，国内主要运营商的5GC控制面基本完成了虚拟化/容器化改造，AMF、UDM、NRF这些“大脑”网元，如今都跑在Kubernetes集群和分布式存储之上。但运维的手册还停留在“看网元告警、查信令跟踪”的老时代——当地基（存储、节点）出问题时，故障会以“网元抽风”的假面目出现。本文以一个脱敏复合案例为主线，复盘一次“AMF反复重启、用户批量掉线”的深夜故障：值班如何被假病因带偏、K8s的默认机制如何放大事故、最终如何在存储层抓到真凶，并给出可落地的分层治理清单。 ## 目录 - 一、故障当夜：一场教科书式的“假病因” - 二、云化核心网：故障分层的新地图 - 三、K8s的善后逻辑：为什么雪崩要等五分钟 - 四、存储层：最容易被忽视的地基 - 五、复盘：四步定位法 - 六、治理清单：把下一次雪闷在摇篮里 - 七、老运维的三点感悟 - 参考来源 ## 一、故障当夜：一场教科书式的“假病因” 先说清楚：这是一个**脱敏复合案例**，由多起真实的云化核心网故障模式合成，环境细节做了改写，但每一步的技术机制都有据可查，文末附官方文档来源。场景是一家省公司的5GC控制面资源池：约40个K8s worker节点、Ceph分布式存储做持久卷，AMF容量池3副本、UDM/NRF若干，承载全省约两千万用户的NAS信令。 时间线如下： | 时间 | 事件 | 表面现象 | |------|------|----------| | 23:41 | Ceph集群出现慢请求提示，未触发短信告警 | 无感知 | | 23:47 | worker-07上的AMF实例OOM重启，N1/N2接口闪断 | 网元告警：AMF异常重启 | | 23:52 | AMF池另两个实例接连抖动，容量降25% | 用户批量掉线、附着变慢 | | 00:15 | 值班判断“新版本引入bug”，启动回滚 | 版本回滚开始 | | 01:30 | 回滚完成，故障依旧，且回滚期间业务二次受损 | 事故升级 | | 01:50 | 平台组介入，第一次看K8s节点状态 | 发现两个节点NotReady | | 02:10 | 查Ceph健康状态，确认慢OSD | 真凶现身：一块老HDD盘延迟飙升 | | 02:40 | 隔离慢OSD、限制恢复带宽 | 慢请求逐渐消退 | | 03:30 | AMF池满配，业务完全恢复 | 事故结束，历时约3小时45分 | 这起故障最典型的特征，不是它有多复杂，而是**每一层都在撒谎**：网元层报“AMF重启”，看起来是软件问题；值班的第一反应是回滚版本——这是传统NFV时代养成的肌肉记忆。但版本回滚动了一轮pod调度，反而加剧了恢复风暴。真正的病灶在三层之下：一块服役四年的HDD盘，在当晚的备份窗口叠加数据恢复流量后，延迟飙升，拖垮了跑在其上持久卷里的AMF实例。 ## 二、云化核心网：故障分层的新地图 传统核心网运维，故障树是“网元-单板-链路”三级；云化之后，变成五层。任何一层的故障，都会向上“翻译”成网元层的语言报出来，这就是假病因的来源。 ```mermaid flowchart TD A["业务层
用户掉线附着慢"] --> B["网元层
AMF重启N2闪断"] B --> C["K8s平台层
Pod驱逐节点NotReady"] C --> D["存储层
Ceph慢OSD慢请求"] C --> E["硬件层
HDD老化网络闪断"] D --> F["真凶
一块慢盘拖垮全池"] E --> F ``` 五层的典型现象与定位手段，整理成一张对照表： | 层级 | 典型现象 | 常见根因 | 第一定位手段 | |------|----------|----------|--------------| | 业务层 | 掉线、注册时延大 | 上层传导 | 拨测+话单比对 | | 网元层 | AMF重启、N2闪断 | pod被驱逐/资源不足 | 网元日志+K8s事件 | | 平台层 | pod漂移、节点NotReady | 心跳丢失、资源压力 | kubectl get nodes/events | | 存储层 | 卷IO延迟、慢请求 | 慢盘、恢复风暴 | ceph health detail | | 硬件层 | 盘卡异常、链路误码 | 硬件老化 | 供应商诊断工具 | 很多省公司的现状是：无线专业、核心网专业、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的杀伤链条是这样的： ```mermaid flowchart TD A["HDD老化IO延迟飙升"] --> B["RBD卷写延迟变大"] B --> C["AMF写日志与状态超时"] C --> D["实例OOM重启"] D --> E["pod漂移重建
全池恢复流量涌入"] E --> F["Ceph雪上加霜
其他卷跟着变慢"] F --> G["更多实例抖动
全池降容"] ``` 注意第5、6步：**pod漂移本身会制造存储压力**。三个AMF实例在几分钟内先后在其他节点重建，重建要读旧卷、写新状态、灌日志，恢复流量瞬间把本就吃紧的Ceph池打满，于是“一个慢盘”升级成“全池变慢”。这就是云化故障和传统故障最大的不同——传统设备故障是线性的，坏一块板坏一个网元；云化故障是**会自我放大**的，恢复动作本身可能成为第二次故障的引信。 另一个隐形地雷是“同池不同命”：信令面的卷和大吞吐的日志卷、备份卷共用一个Ceph池，没有QoS隔离。日志卷吃IO，信令卷就得挨饿。硬盘不区分你的业务优先级，谁重谁先到。 ## 五、复盘：四步定位法 这起故障走完弯路之后，团队把排障过程沉淀成一个四步法，后来在另一次类似故障里十分钟定位。核心思想一句话：**云化核心网排障，从下往上查，而不是从上往下猜**。 ```mermaid flowchart TD A["网元批量异常"] --> B["第一步
看K8s事件流"] B --> C{"有Pod驱逐
或节点NotReady?"} C -->|有| D["查节点硬件与心跳"] C -->|没有| E["查网元自身日志"] D --> F["第二步
查存储健康"] F --> G{"有慢请求
或OSD异常?"} G -->|有| H["隔离慢盘限恢复带宽"] G -->|没有| I["查网络与宿主机"] E --> I H --> J["第三步
观察恢复流量"] J --> K["第四步
确认业务回满"] ``` 四步各自的关键动作： 1. **看K8s事件流**：`kubectl get events --sort-by=.lastTimestamp`按时间拉通看，pod重启、驱逐、调度失败的原始记录都在这里。网元日志说“我自己重启了”，事件流会告诉你“是谁把你搬走的”。这次的误判，就是只看了网元日志没看事件流。 2. **查存储健康**：`ceph health detail`看有没有慢请求提示，`ceph osd perf`看各OSD的apply/commit延迟是否分化——健康池里各盘延迟应在一个量级，一块盘比同伴慢一个数量级，就是它。 3. **管住恢复流量**：定位后第一动作不是“赶紧搬”，而是**限流着搬**——控制pod重建并发，给Ceph的恢复带宽设上限，避免恢复风暴二次伤害。 4. **确认回满**：别看“告警清了”就收工，要看AMF池容量、附着成功率、寻呼时延回到基线，确认没有隐性欠账（比如半死不活的长尾会话）。 ## 六、治理清单：把下一次雪闷在摇篮里 事故之后，团队落了七条整改，按“事前-事中-事后”整理成表，供云化核心网的同行直接对照自查： | 阶段 | 措施 | 要点 | |------|------|------| | 事前 | 信令卷与日志卷分池 | Ceph按业务划池，信令面独享或设QoS上限 | | 事前 | 存储池换NVMe或混闪 | 信令面卷告别纯HDD机械盘 | | 事前 | Ceph慢请求告警接入核心网告警系统 | 底层“温馨提示”必须上浮到值班视野 | | 事前 | PDB按仲裁数配置 | 计划内维护保底，但明确它防不了宕机 | | 事中 | 驱逐重建限并发 | 用K8s的驱逐限速与滚动策略，禁止一拥而上 | | 事中 | 版本回滚前先看平台层 | 新增“回滚前置检查”：事件流+存储健康 | | 事后 | 三层告警关联降噪 | 基础设施-平台-网元告警做时间窗关联，根因优先上报 | 其中投入产出比最高的两条：**信令面存储换NVMe**（一次改造，消灭最大单点诱因）和**慢请求告警上浮**（零成本，把发现时间从两小时压到两分钟）。标准允许多种实现，各厂家云化方案的平台组件形态有差异，具体参数以各厂家官方文档为准，但上面这套分层思想是通用的。 ## 七、老运维的三点感悟 **第一，云化没有消灭故障，只是把故障翻译成了另一门语言。** 老一代运维看得懂单板灯、信令码，新一代必须同时看得懂K8s事件流和Ceph健康报告。这门新语言的词汇量不大——节点心跳40秒、驱逐5分钟、PDB只管自愿中断、慢请求要盯OSD延迟分化——但每个词都值得背下来。 **第二，“副本数够”不等于“高可用够”。** 三副本的AMF，可以同时踩在同一块慢盘撑起的同一个Ceph池上。高可用不是数pod，是数**故障域**：存储池算一个域，机架算一个域，供电算一个域。域没分开，副本就是同一枚硬币的三个面。 **第三，恢复动作本身要当故障对待。** 这次事故真正拉长的两个小时，一半是回滚误判，一半是不受控的恢复风暴。以后深夜处理云化故障，我的第一问永远是：“我们现在做的这个动作，会不会成为下一个故障？”在传统网元时代这是多虑，在云上这是必修课。 5G-A时代核心网在继续向云原生深处走，将来还有边缘UPF的分布式云节点要运维。地基的故障只会更多，不会更少——趁下一次深夜告警响起之前，把K8s的默认参数背熟，把存储池的分域画清楚，才是真功夫。 ## 参考来源 1. [Kubernetes官方文档：Nodes与节点心跳机制](https://kubernetes.io/docs/concepts/architecture/nodes/) — node-monitor-grace-period默认40秒、Lease心跳每10秒、节点失联后默认约5分钟开始驱逐pod、驱逐限速默认每秒0.1节点等机制与默认值，均出自该文档的Node heartbeats与node controller章节 2. [Kubernetes官方文档：配置PodDisruptionBudget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) — PDB只保护自愿中断、minAvailable/maxUnavailable语义与向上取整规则、以ZooKeeper等有状态应用保仲裁数为例的官方建议 3. [Ceph官方文档：OSD故障排查](https://docs.ceph.com/en/reef/rados/troubleshooting/troubleshooting-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 等场景全覆盖。