跳转至

Chapter 6: Managed Cloud Service

本章讲述如何将前面章节的所有组件 (RAN, 6GC) 整合起来, 以云服务的形式提供5G连接.

这是一种与传统电信运营商完全不同的思路:

  • 传统方式: 电信运营商用专有硬件, 封闭系统, 通过复杂的OSS/BSS系统管理
  • 云原生方式: 用通用硬件, 开源软件, 像管理普通云应用一样管理5G网络

核心转变: 把"运营商的专属领域"变成"可以在企业自己部署的云服务", 有利于扁平化与横向扩展.

这样的5G服务, 部署在企业自己的数据中心或公有云上, 称为私有5G (Private 5G). 这也与本书的标题 Private 5G: A Systems Approach 相呼应.

私有5G的用户可以是企业, 工厂, 校园等, 他们自己管理网络, 满足特定的业务需求. 这类用例也就是很多公众号, 新闻里提及的"工业 4.0"

构建模块

building blocks

5G在最开始是传统运营商的专属领域 (封闭的专有硬件设备), 这种OSS/BSS系统架构与管理方式, 与我们这里提及的 cloud-native private 5G 的完全不同.

我们并不关心前者, 他们是历史的尘埃. 我们更倾向于了解后者的构建模块. 因此本章节并不会提及 prev 5G, 以及传统组件与 cloud-native 组件的关系.

我们从零起步, 只关心 cloud-native private 5G 的构建模块!

整个 cloud-native private 5G 系统, 如下图所示:

alt text

硬件层: 交换机+服务器

软件层: 云原生组件与管理平台

这五个工具形成一条"流水线", 各司其职:

工具 角色比喻 具体职责 谁该负责
Docker 打包工人 把软件功能打包成标准化的"集装箱" (容器), 确保在任何地方都能运行 -
Kubernetes 车间主任 管理这些"集装箱": 启动多少个, 分配多少资源, 坏了自动重启 -
Helm 装配图纸 描述一个应用由哪些容器组成, 它们之间如何连接 (由开发者编写) 开发者
Fleet 物流调度 把多套Helm图纸部署到多个Kubernetes集群上 (支持GitOps方式) 运维人员
Terraform 基建工程师 搭建Kubernetes集群本身. 以声明式方法配置infra 运维人员
terraform 如何以声明式方式配置infra

Terraform 假设有底层的配置 API, 利用这些 API 来创建和管理资源.

用户只需编写配置文件, 描述所需的基础设施状态, Terraform 会自动处理创建, 更新和删除资源的细节

常见的 API 有:

  1. AKS: Azure Kubernetes Service. 来自 Microsoft Azure
  2. EKS: Elastic Kubernetes Service. 来自 AWS
  3. GKE: Google Kubernetes Engine. 来自 GCP
  4. RKE: Rancher Kubernetes Engine. 来自 Rancher

部署架构: 以 Aether 为例

以一个前几章反复提及的开源项目来展示: Aether 是一个已部署到多个站点的运营边缘云

它受到了 SDN 的启发, 将多个站点的边缘设备 (如 RAN, 核心网等) 整合起来, 以云服务的形式提供5G连接.

整个框架叫做 Hybrid Cloud Architecture, 包括两个主要部分:

  1. 中央大脑: Central Cloud
    • 就一个. 位于云端数据中心
  2. 边缘站点: Edge Cloud
    • 很多个. 位于网络边缘
    • 在Aether中的专有名词是: ACE. Aether Connected Edge

alt text

看局部: 边缘云 ACE

每个企业部署一个ACE, 每一个ACE是一组基于Kubernetes的边缘节点, 运行RAN和核心网组件

alt text

本质上, 自顶向下分三层:

  • Layer 3: SD-RAN, SD-Core, ...
  • Layer 2: SD-Fabrics
  • Layer 1: Physical Infra (k8s + server + switch)

核心组件:

  • SD-RAN: 软件定义的无线接入网, 控制部署在企业的小基站
  • SD-Core:
    • 本质上是 Core-UP (ch2中我们提到过, local breakout架构, Core-UP放本地, Core-CP放云端)
    • 处理实际的数据转发, 实现"本地分流" (Local Breakout)
  • SD-Fabric: 以SDN方式管理的交换网络

看整体: Hybrid Cloud

alt text

  1. 控制面集中, 用户面分布: 控制面逻辑可以共享, 用户面必须靠近用户
  2. 灵活配对: 一个控制面实例可以管理多个用户面实例, 隔离程度可配置
  3. 逻辑集群 vs 物理集群:
    • 边缘 ACE 通常是物理集群 (真实硬件. 上述的 server / switch)
    • 中央的 SD-Core CP 是逻辑集群 (运行在GCP/Azure/AWS上的k8s)
    • 甚至可以用KIND (Kubernetes in Docker)在笔记本上跑开发环境

(1) "multi-tenant"需要区分不同角色:

角色 职责 访问范围 举例
云运营商 管理整个混合云基础设施 全部集群 AWS, Azure, GCP DC管理员
企业管理员 决定本站点运行什么应用, 如何分配资源 仅自己的站点 mint, 中国移动企业管理员
第三方服务商 提供边缘应用 (源码/Docker镜像) 通过生命周期管理流水线接入 开源社区为❤️发电的开发者

(2) Aether支持从简单到复杂的多种部署形态:

  • 最简配置: 单服务器, 用传统小基站 (非O-RAN), AMP和SD-Core都在本地
  • 标准配置: 多服务器集群, O-RAN小基站 + SD-RAN, 控制面在云端

云管理平台: 以 AMP 为例

Cloud Management Platform

"AMP manages both the distributed set of ACE clusters and one or more SD-Core CP clusters running in the central cloud"

AMP (Aether Management Platform) 位于中央云端, 负责管理所有边缘 ACE 集群和中央 SD-Core CP 集群, 提供 5G-as-a-Service 服务

alt text

自顶向下看, AMP有四个子系统:

  1. Resource Provisioning:
    • 初始化资源 (配置并启动物理和虚拟资源)
    • 状态转移 (增加, 替换或升级容量)
  2. Lifecycle Management:
    • 持续集成 + 软件组件的部署 (基于 GitOps)
  3. Service Orchestration:
    • "manage services once they are operational"
    • 定义了一个 API, 隐藏底层 micro-service 的实现细节, 并基于此管理提供的 5G 连接服务
  4. Monitoring & Telemetry:
    • 收集, 归档, 评估和分析底层组件产生的运营数据
注意

积累! 学着点! 说不定后面我们的 dtclab-plc 项目也会用到类似的架构设计

从 workflow 的角度看 AMP (highlighting the offline and online aspects of cloud management):

alt text

离线 vs 在线的区分
  • 离线: 通过提交代码/配置到Git仓库来触发系统变更
  • 在线: 通过API, 实时读写运行系统的参数

Resource Provisioning

def(资源配置): 将虚拟和物理资源在线的过程

当 cloud 由虚拟和物理资源结合构建时, 比如像 Aether 这样的混合云, 我们需要一种无缝的方式来兼容两者

alt text

做法: 用 Terraform 把基础设施的配置"代码化" - 可版本控制, 可重复执行, 可审计

  1. 先在硬件资源上叠加逻辑结构
  2. 再在逻辑结构上部署 Kubernetes 集群
  3. Terraform "声明式定义" 集群
声明式定义 vs 命令式定义
  1. 声明式定义 (Declarative Definition) 是一种编程范式, 强调描述期望的最终状态, 而不是具体的实现步骤.
  2. 命令式定义 (Imperative Definition) 则侧重于逐步指令, 明确告诉系统如何一步步达到目标状态.

如果是"命令式" (比如用 Shell 脚本)

你需要写清楚每一步, 很麻烦:

Bash
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# 伪代码: 命令式脚本
# 1. 检查集群是否存在
if ! check_cluster_exists "my-cluster"; then
  create_cluster "my-cluster" --version 1.27
fi

# 2. 检查节点数量
current_nodes=$(get_node_count "my-cluster")
if [ "$current_nodes" -lt 3 ]; then
  add_nodes "my-cluster" $((3 - current_nodes))
elif [ "$current_nodes" -gt 3 ]; then
  remove_nodes "my-cluster" $((current_nodes - 3))
fi

如果是 Terraform 的"声明式定义" (.tf 描述期望状态即可)

Terraform
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
# main.tf (Terraform 配置文件)

# 我声明: 我要一个 AWS EKS 集群
resource "aws_eks_cluster" "example" {
    name     = "my-cluster"
    version  = "1.27"
}

# 我声明: 这个集群要有 3 个工作节点
resource "aws_eks_node_group" "example_nodes" {
    cluster_name    = aws_eks_cluster.example.name
    node_group_name = "worker-nodes"

    scaling_config {
      desired_size = 3  # 这里! 直接声明我想要 3 个
      max_size     = 5
      min_size     = 1
    }
}

声明式定义:

  1. 关注点在"终态": 定义的是"集群建成后长什么样"
  2. 代码即文档: 描述了系统应该是什么样子
  3. 幂等性: 同样的代码, 跑一次和跑一万次, 结果都是一样的. 极其适合自动化运维

Lifecycle Management

这是一条完整的CI/CD流水线:

alt text

CI (持续集成) 的"产出":

  • Docker镜像 (打包好的软件)
  • Helm Charts (部署配置)

CD (持续部署) 的"消费":

  • 从仓库拉取镜像和配置
  • 先部署到Staging测试
  • 通过后再部署到Production

三大核心原则:

  1. 松耦合: CI和CD通过仓库中的 artifact 对接, 互不直接依赖
  2. Configuration-as-Code (GitOps): 所有配置都在Git仓库中, 提交即部署
  3. 部署门控: 可以在流水线中加入人工审核或自动化测试的关卡

Service Orchestration

为运行中的 5G 服务提供统一的管理 API

服务编排的四个核心任务:

  1. 认证: 确认是谁在发起操作
  2. 授权: 检查这个人有没有权限执行这个操作
  3. 下发: 把配置推送到后端各组件
  4. 持久化: 记录配置, 确保重启后仍然生效

技术实现:

  • 用 YANG 语言定义数据模型
  • 从模型自动生成 API
  • 用 gNMI 协议向下层组件推送配置变更
  • 用 Key-Value Store 存储配置状态
YANG 语言是什么

YANG 是一种数据建模语言 (Data Modeling Language), 最初是由 IETF (互联网工程任务组) 设计开发的, 专门用于网络配置协议 (NETCONF)

它的核心作用是对网络设备上的数据进行建模. 具体包括:

  1. 配置数据 (Configuration Data): 例如接口的 IP 地址, 路由协议的参数
  2. 状态数据 (State Data): 例如接口的丢包统计, 当前的 CPU 使用率等只读数据
  3. 远程过程调用 (RPCs): 定义设备支持的操作命令
  4. 通知 (Notifications): 定义设备主动上报的告警或事件

例子: 为一个网络设备的 network interface 建立模型

YANG
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
module example-interface {
  // 1. 头部信息: 定义模块名称, 命名空间和前缀
  yang-version 1.1;
  namespace "urn:example:interface";
  prefix "if";

  description "一个简单的网络接口示例模型";

  // 2. Container: 最外层的容器, 相当于文件夹
  container interfaces {
    description "所有接口的列表容器";

    // 3. List: 列表, 因为设备可能有多个接口 (eth0, eth1...)
    list interface {
      // 4. Key: 列表的主键, 必须唯一, 这里用 'name' 区分不同接口
      key "name";

      // 5. Leaf: 叶子节点, 承载具体数据
      leaf name {
        type string;
        description "接口名称, 例如 eth0";
      }

      leaf enabled {
        type boolean;
        default "true";
        description "接口是否启用";
      }

      leaf ip-address {
        type string;
        // 在实际项目中通常会引用 'ietf-inet-types' 来校验 IP 格式
        description "接口的 IP 地址";
      }

      // 6. Config false: 标记为状态数据 (只读), 不可配置
      leaf packet-received {
        type uint64;
        config false;
        description "接收到的数据包统计";
      }
    }
  }
}

Monitoring & Telemetry

收集三类数据来了解系统运行状态:

数据类型 特点 用途 常用工具
Metrics (指标) 定量数据, 周期性采集 性能监控, 容量规划, 告警 Prometheus
Logs (日志) 事件记录, 带时间戳 故障排查, 审计 ElasticSearch
Traces (追踪) 跨服务的调用链 理解请求路径, 定位延迟来源 Jaeger

Traces的特殊价值:

在微服务架构中, 一个用户请求可能经过10+个服务. Trace能告诉你"这个请求慢在哪一步"!

这在"单体应用时代"靠 调用栈 就能看到, 但在分布式系统中必须专门记录!

Connectivity API

这是企业管理员实际使用的接口, 用来控制5G连接服务

内容有很多:

  1. API 风格: GET, POST, PUT, DELETE, ...
  2. 核心数据模型
    • enterprise
    • slice
    • device-group
    • application
    • traffic-class
  3. QoS参数如何"注入"实际配置

详见原文: Connectivity API

注意

积累! 学着点! 我们的 dtclab-plc 项目一定会用到类似的API设计

本章核心名词

基础设施层

名词 解释
Leaf-Spine Fabric 叶脊网络架构, 一种数据中心常用的交换机互联拓扑, 提供高带宽, 低延迟的服务器间通信
Helm / Helm Chart Kubernetes的配置管理工具, Chart是描述应用如何部署的"图纸"
Fleet 多集群应用部署管理器, 支持GitOps方式批量部署
Terraform 基础设施即代码工具, 用声明式配置管理云资源
KIND Kubernetes in Docker, 在Docker容器中运行Kubernetes, 用于开发测试

部署架构

名词 解释
ACE Aether Connected Edge, Aether的边缘部署单元
AMP Aether Management Platform, Aether的云管理平台
SD-RAN 软件定义的无线接入网, 基于SDN架构的RAN实现
SD-Core 软件定义的核心网, 分为CP (控制面) 和UP/UPF (用户面)
SD-Fabric 软件定义的交换网络, 管理数据中心内部的流量转发
Local Breakout 本地分流, 边缘流量不绕行中央直接在本地处理
Neutral Host 中立主机, 拥有基础设施并向多个运营商出租的第三方

管理平台

名词 解释
Infrastructure-as-Code 基础设施即代码, 用代码文件定义和管理基础设施
Configuration-as-Code / GitOps 配置即代码, 配置变更通过Git提交触发自动部署
CI/CD 持续集成/持续部署, 自动化的软件构建和发布流水线
YANG 一种数据建模语言, 常用于网络设备配置
gNMI gRPC Network Management Interface, 基于gRPC的网络管理协议
Prometheus 开源的指标监控系统
ElasticSearch 开源的日志存储和分析系统
Jaeger 开源的分布式追踪系统

数据模型

名词 解释
Enterprise 企业对象, 多租户隔离的根节点
Site 站点, 企业的一个部署点
Slice 切片, 端到端的隔离通信通道
Device-Group 设备组, 通过IMSI范围定义的一组终端设备
Application 应用, 设备要访问的目标服务端点
Template 模板, 预定义的QoS配置套餐
Traffic-Class 流量类别, QoS的具体参数集合
SST/SD Slice/Service Type 和 Slice Differentiator, 3GPP定义的切片标识符
MBR Maximum Bit Rate, 最大比特率