4.2 从VNF到CNF云原生演进

4.2 从 VNF 到 CNF 云原生演进

本节摘要：第一代 VNF 跑在虚拟机里，把传统网络设备的功能原封不动塞进 VM，没充分利用云的优势。CNF（Containerized Network Function，云原生网络功能）用容器替代虚拟机、用微服务替代单体、用 Kubernetes 替代传统虚拟化管理，让网络功能真正具备云原生的弹性和敏捷。本节讲清 CNF 相比 VNF 的核心改进、改造要点、以及演进中面临的挑战。

学习目标

阅读完本节，你应当能够：

1. 说清 CNF 相比 VNF 的三个核心改进
2. 解释微服务拆分对网络功能的意义
3. 说明 Kubernetes 在 CNF 编排中的角色
4. 列出 VNF 改造成 CNF 的三个难点
5. 判断什么场景该做 CNF 化、什么场景保持 VNF

一、问题与直觉

第一代 VNF 有个尴尬：它叫"虚拟化网络功能"，但实际上只是"把网络设备的功能塞进虚拟机"。一个 vFirewall 的虚拟机镜像可能有好几个 GB，启动要几分钟，扩容要复制整个 VM，更新要整体替换。这本质上还是"硬件思维"——只不过把硬件换成了虚拟机，运维模式没变。

这种 VNF 没有真正利用云计算的弹性优势。一个虚拟机里跑着一个庞大的单体软件，扩容粒度粗（只能整个 VM 复制）、资源占用大（每个 VM 含完整操作系统）、启动慢、更新难。它比专用硬件灵活，但离"像云原生应用一样敏捷"还差得远。

CNF 的思路是：把网络功能也做成云原生应用——用容器替代虚拟机（更轻量）、用微服务替代单体（更灵活）、用 Kubernetes 编排（自动化运维）。这样网络功能就能享受云原生的全部红利：秒级启动、滚动更新、自动扩缩容、持续集成。这是 NFV 在云原生时代的必然演进。

二、核心原理

2.1 CNF 相比 VNF 的三个改进

CNF 不是简单的"把 VNF 从虚拟机挪到容器"，而是三个层面的改进：

载体改进：虚拟机 → 容器。容器共享宿主机内核，不需要每个实例带完整操作系统。一个 vFirewall 的容器镜像可能只有几十 MB（虚拟机镜像要几 GB），启动从分钟级降到秒级，单台服务器能跑的实例数翻几倍。

架构改进：单体 → 微服务。传统 VNF 是一个大单体程序，所有功能（配置管理、流量处理、日志、监控）揉在一起。CNF 把这些功能拆成独立微服务——流量处理一个服务、配置管理一个服务、监控一个服务，各自独立部署、独立扩缩。比如流量大但配置变更少时，只扩容流量处理服务，不浪费资源在配置服务上。

运维改进：传统管理 → Kubernetes 编排。CNF 用 Kubernetes 管理生命周期——部署用声明式 YAML、扩缩容靠 K8s 自动调节、更新用滚动发布、故障靠 K8s 自愈。这比传统 VNFM 的脚本式管理成熟得多，也跟主流 DevOps 工具链无缝对接。

2.2 微服务拆分的意义

把网络功能拆成微服务，是 CNF 最核心的改变。以一个 vFirewall 为例：

传统 VNF（单体）架构：

vFirewall VM
├── 配置管理模块
├── 规则引擎
├── 流量处理引擎
├── 日志模块
└── 监控agent
（全部塞在一个进程里，一起启动一起扩缩）
​

CNF（微服务）架构：

拆分的好处：

• 独立扩缩：流量处理是 CPU 密集的，要按负载扩容；配置管理基本不变，不用扩。微服务架构下可以只扩流量处理服务，节省资源。
• 独立更新：规则引擎要更新规则库时，只重启规则服务，流量处理不中断。
• 独立容错：日志服务挂了不影响流量处理，故障隔离。

但微服务拆分也有代价——服务间通信开销、部署复杂度上升、分布式调试难。第 5 章会讲这些问题怎么靠服务网格等手段缓解。

2.3 Kubernetes 在 CNF 里的角色

Kubernetes 是 CNF 的事实标准编排平台。它为 CNF 提供：

• 声明式部署：用 YAML 描述"我要几个 CNF 实例、每个多少资源"，K8s 自动调度到合适的节点。
• 自动扩缩容（HPA）：根据 CPU/内存等指标自动增减 Pod 数量。
• 滚动更新：新版本 CNF 逐个替换旧版本，不中断服务。
• 服务发现：CNF 之间通过 K8s Service 互相找，不用硬编码地址。
• 自愈：Pod 挂了 K8s 自动重启，节点挂了把 Pod 迁移到其他节点。

这些能力让 CNF 的运维比传统 VNF 自动化得多。传统 VNF 要 VNFM 写脚本管生命周期，CNF 直接用 K8s 的成熟机制，运维跟普通云原生应用一致。

2.4 CNF 的网络挑战

把网络功能装进容器，有个特殊挑战：容器网络本身要做额外处理。普通应用（Web 服务）的容器网络只要能访问外网就行，但网络功能（路由器、防火墙）的容器要处理大量转发流量，对网络性能要求高。

K8s 默认的容器网络（CNI 插件，如 Calico、Flannel）是为普通应用设计的，吞吐和延迟满足不了高性能网络功能。所以 CNF 场景下要用专门的 CNI 或数据平面加速：

• SR-IOV CNI：把 SR-IOV 的 VF 直接分配给容器，绕过 K8s 默认网络栈。
• DPDK in container：在容器里跑 DPDK，配合大页内存和 CPU 绑核。
• Multus 多网卡：给一个容器挂多个虚拟网卡，区分管理流量和数据流量。

这些技术让 CNF 既能享受容器的轻量，又能达到网络功能所需的性能。

三、工程实践要点

3.1 VNF 改造成 CNF 的三个难点

把现有 VNF 改造成 CNF，不是简单地换个打包方式，而是要动架构。三个主要难点：

难点一：单体拆微服务。传统 VNF 是一个大单体，内部模块之间通过函数调用或共享内存通信，耦合很紧。拆成微服务后，跨服务通信要走网络（IPC 或 HTTP/gRPC），延迟增加、可靠性要自己保证。怎么拆、拆多细，是个架构设计难题。

难点二：有状态变无状态。K8s 的扩缩容和滚动更新假设 Pod 是无状态（或状态可重建）的。但很多网络功能（防火墙的连接表、NAT 的映射表）是有状态的。要把状态外部化（存到 Redis、etcd 等共享存储），或者用状态保持机制，改造工作量大。

难点三：性能保证。容器的网络性能默认不如虚拟机（多了一层容器网络）。要达到电信级性能，得上 SR-IOV CNI、DPDK 等加速手段，这些跟 K8s 的配合还不够成熟，踩坑多。

3.2 渐进式 CNF 化

不是所有 VNF 都要一次性改造成 CNF。渐进式策略：

• 新功能直接做 CNF：新部署的网络功能，一开始就用容器和微服务架构。
• 核心功能保留 VNF：对性能极其敏感、改造风险大的核心功能（如核心网的用户面），暂时保持虚拟机形态。
• 混合编排：用 NFVO 同时编排 VNF（OpenStack）和 CNF（K8s），逐步迁移。

💡 关键直觉：CNF 化是方向，但不是一刀切。对性能极其敏感、状态复杂、改造风险高的功能，保持 VNF 可能更稳妥。评估每个功能：CNF 化的收益（弹性、运维）是否大于改造成本和性能风险。

3.3 CNF 生态的现状

CNF 生态正在快速成熟，但还有不少挑战：

• 电信级 K8s：普通 K8s 的可靠性满足不了电信级（99.999%）要求，要做大量加固（多集群、灾备、故障域隔离）。
• CNF 标准化：CNCF（Cloud Native Computing Foundation）在推 CNF Test Suite，评估 CNF 的云原生合规性，但标准仍在完善。
• 厂商支持：主流网络设备厂商（爱立信、诺基亚、华为）都在推 CNF 产品，但成熟度和功能完整性参差不齐。

本节要点回顾

• CNF 相比 VNF 三个改进：载体（虚拟机→容器）、架构（单体→微服务）、运维（脚本→K8s），带来秒级启动、细粒度扩缩、80% 以上资源利用率。
• 微服务拆分是核心改变：独立扩缩、独立更新、独立容错，但要权衡通信开销和复杂度。
• Kubernetes 提供 CNF 全套运维能力：声明式部署、自动扩缩容、滚动更新、服务发现、自愈。
• CNF 的网络挑战：容器默认网络性能不够，要上 SR-IOV CNI、DPDK、Multus 多网卡。
• VNF 改造 CNF 三个难点：单体拆微服务、有状态变无状态、性能保证。
• 渐进式 CNF 化：新功能直接 CNF，核心高风险功能保留 VNF，混合编排逐步迁移。
• 电信级 K8s 要大量加固：普通 K8s 满足不了 99.999% 可用，要多集群、灾备、故障域隔离。

下一章专门讲 MANO——怎么编排这些 VNF/CNF，实现网络服务的自动化部署和运维。

四、云原生的电信级改造清单

容器技术为 IT 场景而生，电信场景搬进容器要过一套"电信级改造"清单。改造一，超大流量与 kube-proxy 的矛盾：默认的服务转发路径扛不住用户面吞吐，CNF 普遍绕开它，用直通网络或用户态转发面。改造二，有状态与会话保持：核心网网元维护海量会话上下文，容器重启不能丢会话——共享会话存储与实例亲和调度是两大流派，各有取舍。改造三，可靠性语义翻译：电信的"五个九"要翻译成云原生的探针、重试、PodDisruptionBudget 语言，翻译不当就会出现"编排器认为健康、业务已经僵死"的假活。改造四，升级不中断：滚动升级对无状态服务易如反掌，对会话型网元需要会话迁移或双轨并行的定制方案。这份清单说明 CNF 不是"把 VNF 塞进容器"的包装动作，而是一次按电信约束重写基础设施的工程——完成度高的 CNF 才真正兑现云原生的红利，半吊子改造常落得两头的缺点都占。

五、迁移决策：三问定形态

CNF 演进的收尾给一个迁移决策框架，三问定形态。问一，业务弹性需求真实存在吗？ 如果某网元的容量常年稳定（如承载网中间的转发节点），虚拟机甚至专用硬件的粗粒度供给更省心；为不存在的弹性需求做微服务化改造，是常见的过度工程。问二，团队能承接云原生运维栈吗？ 容器化把复杂度从开发期转移到运维期（镜像供应链、编排参数、可观测性栈都要养人），运维组织没有完成转型的团队，CNF 化后故障率反而上升——技术选型同时是组织能力的选型。问三，时延预算允许吗？ 微服务化引入的服务间调用链会吃掉时延预算，时延最敏感的用户面节点保留粗粒度甚至旁路架构是理性选择。三问过完，答案往往不是全盘 CNF 化，而是"新业务用 CNF、存量稳定的留在虚拟机、最敏感的保留专用件"的混合态——这也是当前电信云的主流形态。演进的目的从来不是到达某个名词，而是让每个功能停在与自身约束匹配的形态上。