当前位置： 首页 > news >正文

基于Helm与Kubernetes的5G核心网云原生部署实践

news 2026/5/10 3:04:19

1. 项目概述与核心价值

最近在折腾5G核心网部署，发现了一个宝藏项目：Orange-OpenSource/towards5gs-helm。这可不是一个简单的Helm Chart仓库，它背后是Orange这家全球领先的电信运营商的开源实践，目标是把复杂的5G核心网组件，通过Kubernetes和Helm这套云原生标准工具链，变得像部署一个Web应用一样简单、可重复、可管理。如果你正在研究5G、云原生网络，或者头疼于如何将NFV（网络功能虚拟化）平滑过渡到CNF（云原生网络功能），这个项目绝对值得你花时间深挖。

简单来说，towards5gs-helm提供了一套完整的、生产可参考的Helm Charts，用于在Kubernetes上部署和运行3GPP标准的5G核心网。它基于著名的free5GC或open5gs等开源5GC项目，但解决了从“能跑起来”到“能在生产环境稳定运行”之间的巨大鸿沟。项目名中的“towards”很有深意，它代表着一种方向——朝着用云原生方法构建和管理5G核心网迈进。对于开发者、架构师和运维工程师而言，它不仅仅是一堆YAML文件，更是一套经过验证的最佳实践模板，涵盖了网络配置、服务发现、持久化、监控、高可用等你在真实部署中必然会遇到的所有棘手问题。

2. 项目整体架构与设计哲学

2.1 为什么是Helm + Kubernetes？

5G核心网的传统部署方式，要么是基于物理专有设备，要么是使用VM+手动配置的NFV。这两种方式都存在部署慢、升级复杂、资源利用率低、故障恢复时间长的问题。towards5gs-helm选择Helm和Kubernetes，正是为了应对这些挑战。

Helm作为Kubernetes的包管理器，它把5G核心网中每个网络功能（如AMF、SMF、UPF）以及其依赖（如数据库、消息队列）打包成一个独立的“Chart”。每个Chart里包含了部署所需的所有Kubernetes资源定义（Deployment, Service, ConfigMap等），以及可配置的values.yaml。这意味着：

  • 参数化配置：你可以通过一个中心化的values文件，轻松调整所有网元的镜像版本、副本数、资源限制、网络配置等，无需手动修改几十个YAML文件。
  • 依赖管理：Chart可以声明依赖关系。例如，部署SMF可能需要先有UDM（用户数据管理），Helm会帮你管理这些依赖的安装顺序。
  • 版本化与回滚：每次安装或升级都是一个明确的“Release”，出问题可以一键回滚到上一个稳定版本，这对于核心网络这种对稳定性要求极高的场景至关重要。

Kubernetes则提供了运行时的保障：

  • 声明式运维：你只需要告诉K8s“我想要5个AMF实例在运行”，它会自动帮你创建、调度、监控并保持这个状态。
  • 高可用与自愈：通过Deployment和ReplicaSet，Pod（容器实例）故障后会自动重启或迁移，结合就绪探针和存活探针，确保服务持续可用。
  • 资源管理与隔离：可以为每个5G网元精确分配CPU、内存资源，并利用命名空间进行逻辑隔离，避免“吵闹的邻居”问题。
  • 服务发现与负载均衡：Kubernetes Service为内部复杂的5G网元间通信提供了稳定的网络端点，无论是ClusterIP用于内部通信，还是LoadBalancer/NodePort用于对外暴露N1/N2/N4等接口，都变得标准化。

注意：将5G核心网容器化并上K8s，并非简单地把二进制文件塞进容器。需要仔细处理有状态服务（如UDM的数据库）、高性能网络（UPF的数据面转发）、以及时间同步（NTP/PTP）等特殊需求。towards5gs-helm的Chart设计正是在解决这些难题。

2.2 核心组件与Chart结构解析

该项目通常为5G核心网的每个标准网元提供一个独立的Helm Chart。我们以一套典型的5G SA（独立组网）核心网为例，拆解其核心组件：

  1. 控制面网元：

    • AMF (Access and Mobility Management Function)：接入和移动性管理功能，是终端（UE）接入网络的第一个控制点。Chart需要配置N1/N2接口、与NRF的交互、以及AMF Set/Region等用于容灾的标识。
    • SMF (Session Management Function)：会话管理功能，负责UPF选择、IP地址分配、会话策略控制。它的Chart配置最为复杂，涉及与PCF、UDM、UPF的多方交互，以及数据网络（DNN）的配置。
    • UDM/UDR (Unified Data Management/Repository)：统一数据管理/存储。这是典型的有状态服务，Chart中必须包含数据库（如MongoDB）的部署，并处理好数据持久化（PersistentVolume）和初始化（如创建索引）。
    • PCF (Policy Control Function)：策略控制功能。Chart需要配置策略规则以及与SMF的接口。
    • NRF (Network Repository Function)：网络仓库功能，相当于5G核心网的服务发现中心。所有网元都要向NRF注册。它的高可用性设计至关重要。
    • AUSF (Authentication Server Function)：认证服务器功能。

  2. 用户面网元：

    • UPF (User Plane Function)：用户面功能，负责数据包的转发、路由和策略执行。这是性能瓶颈和设计难点。Chart需要处理：
      • 高性能网络：通常需要启用hostNetwork模式或使用SR-IOV、DPDK等加速技术，以绕过K8s网络栈，获得接近线速的转发性能。
      • 多网卡配置：区分N3（接入侧）、N6（数据网络侧）等不同网络接口。
      • 特殊权限：可能需要privileged: true权限或特定的Linux Capabilities来操作网络设备。

  3. 支撑与基础设施：

    • MongoDB/Redis：作为UDM/UDR、PCF等网元的后端存储。项目可能会提供内嵌的子Chart，或推荐使用外部的、经过优化的数据库Operator（如MongoDB Community Operator）。
    • WebUI：一个用于展示网络拓扑、查看注册用户、会话状态的可视化控制台。
    • Grafana & Prometheus：监控套件。Chart中通常会集成ServiceMonitor，自动抓取各网元暴露的指标（如注册用户数、会话数、消息处理延迟）。

项目的目录结构通常如下所示：

towards5gs-helm/ ├── charts/ │ ├── amf/ │ │ ├── Chart.yaml │ │ ├── values.yaml │ │ ├── templates/ # 存放所有K8s资源模板文件 │ │ └── ... │ ├── smf/ │ ├── upf/ │ └── ... ├── umbrella-chart/ # 可选：一个总Chart，一键部署整个5GC │ ├── Chart.yaml │ ├── values.yaml │ └── charts/ # 依赖所有子Chart └── examples/ └── values-full.yaml # 一份完整的、包含所有配置的values示例文件

2.3 网络架构设计考量

在Kubernetes中部署5G核心网，网络规划是重中之重。towards5gs-helm的values文件里，网络相关的配置项通常占很大比重。

  • 服务发现与通信：所有控制面网元（AMF, SMF, UDM等）通过Kubernetes Service（ClusterIP类型）相互发现和通信。NRF的Service名称（如nrf-svc）会成为其他网元配置中的通用端点。
  • 对外暴露接口：
    • N1/N2 (AMF)：需要暴露给基站（gNB）和终端。通常使用LoadBalancer类型的Service（在公有云或支持MetalLB的本地集群），或者NodePort并配合外部负载均衡器。安全组和防火墙规则必须相应开放。
    • N4 (SMF-UPF)：SMF与UPF之间的控制接口。由于UPF可能采用主机网络，SMF可能需要通过UPF Pod所在节点的特定IP和端口来访问它。
    • N6 (UPF)：UPF到互联网或企业数据网络的出口。这通常通过UPF Pod的第二个网络接口（或主机网络）直接连接外部物理网络。
  • CNI插件选择：默认的Calico或Flannel可能无法满足UPF的高性能需求。生产环境往往会考虑Cilium（得益于eBPF的高性能）、Multus（支持多网卡）或特定的SR-IOV CNI插件。towards5gs-helm的UPF Chart可能需要适配不同的CNI配置。

3. 核心细节解析与实操要点

3.1 Values.yaml 深度配置指南

values.yaml是整个Helm部署的灵魂。以AMF Chart为例，我们拆解关键配置段：

# towards5gs-helm/charts/amf/values.yaml 示例片段 image: repository: towards5gs/amf tag: latest # 生产环境务必指定具体版本号，如v3.2.1 pullPolicy: IfNotPresent replicaCount: 2 # 决定AMF的Pod副本数，用于高可用 # 资源限制，根据实际负载调整 resources: limits: cpu: "1" memory: "512Mi" requests: cpu: "500m" memory: "256Mi" # 这是5G核心网特有的配置，通过ConfigMap或环境变量注入容器 configuration: # AMF实例标识，同一AMF Set内的实例需配置相同的setId amfName: "amf1" ngapIp: "0.0.0.0" # 容器内监听地址 sbiIp: "0.0.0.0" nrfUri: "http://nrf-svc:8000" # 指向NRF的Service # 服务区域列表，定义该AMF覆盖的TACs servedGuamiList: - plmnId: "20893" amfId: "cafe00" # 网络切片选择辅助信息 networkSliceList: - sst: 1 sd: "010203" # Kubernetes Service配置 service: type: ClusterIP # 内部通信 ngapPort: 38412 # N2接口端口 sbiPort: 80 # 服务化接口端口 # 如果需要对外暴露N2接口给gNB serviceExternal: enabled: true type: LoadBalancer ngapPort: 38412 # 可以为LoadBalancer指定特定IP或使用注解配置特定云供应商功能 # loadBalancerIP: "10.0.100.10" # annotations: # metallb.universe.tf/address-pool: public-ips

关键配置解析与避坑：

  • 镜像标签：永远不要在生产环境使用latest标签。锁定一个已知稳定的版本。
  • 资源请求与限制：requests是调度依据，limits是硬性上限。5G网元（尤其是UPF、SMF）在忙时可能突发流量，limits设置过紧会导致Pod被OOM Kill或Throttle。建议先监控，后调整。
  • nrfUri：这是服务发现的关键。必须确保这个域名（nrf-svc）能在Pod内正确解析到NRF的Service。在复杂的多集群或混合网络环境中，可能需要配置CoreDNS或hostAliases。
  • 网络切片配置：sst（切片类型）和sd（切片区分符）必须与终端、基站以及SMF、PCF中的配置匹配，否则切片选择会失败。
  • 对外暴露服务：使用LoadBalancer时，要清楚云供应商的负载均衡器创建时间和成本。NodePort则需自行管理外部负载均衡和健康检查。

3.2 有状态服务的数据持久化

UDM/UDR和PCF等网元依赖数据库。在K8s中处理有状态服务需要格外小心。

# 以UDM Chart中MongoDB的配置为例 udm: persistence: enabled: true # 使用StorageClass动态 provisioning storageClass: "fast-ssd" accessModes: - ReadWriteOnce size: 10Gi # 挂载路径 mountPath: /data/db # 或者，使用独立的MongoDB子Chart或外部数据库 externalMongoDB: enabled: false # 如果使用云数据库服务或独立部署的MongoDB集群 # uri: "mongodb://user:pass@mongodb-svc:27017/udm"

实操心得：

  1. StorageClass选择：根据数据库的IO性能要求选择。本地SSD盘（localvolume）性能最好，但需要管理节点亲和性。网络存储（如Ceph RBD， AWS gp3）更灵活，但延迟稍高。
  2. 访问模式：MongoDB单实例通常用ReadWriteOnce。如果部署MongoDB副本集（生产环境推荐），则需要能被多个Pod挂载的ReadWriteMany存储，这对存储后端有要求。
  3. 备份与恢复：K8s的PersistentVolume（PV）本身不提供备份。必须建立独立的数据库备份策略，例如使用mongodump定期备份到对象存储，或使用K8s原生备份工具如Velero。
  4. 初始化：Chart的templates/目录下可能会有configmap-init.yaml或job.yaml，用于在数据库Pod启动后执行初始化脚本（创建数据库、用户、集合索引）。要确保这些初始化Job只成功运行一次。

3.3 配置管理与敏感信息处理

5G核心网配置包含IP地址、端口、PLMN ID、数据库密码等大量信息。Helm提供了多种管理方式：

  • 默认Values + 自定义Values文件：最佳实践是保持charts/目录下的原始values.yaml不变，创建一个自定义的my-values.yaml文件，使用helm install -f my-values.yaml来覆盖默认值。这便于版本控制和管理不同环境（开发、测试、生产）的配置。
  • ConfigMap vs. 环境变量：复杂的配置文件（如JSON、YAML格式的网元配置）适合放在ConfigMap中挂载到容器内。简单的键值对则可以通过环境变量注入。在Chart的templates/configmap.yaml中可以看到如何将values.yaml中的configuration部分生成为ConfigMap。
  • Secret管理：数据库密码、证书私钥等必须使用Kubernetes Secret。Helm支持在values.yaml中通过secretKeyRef引用Secret。绝对不要将明文密码写在values.yaml或提交到代码库。可以使用helm secrets插件（集成sops或vals）在部署时动态解密，或使用云厂商的密钥管理服务（如AWS KMS, GCP Secret Manager）。

4. 完整部署流程与核心环节实现

4.1 前置环境准备

假设你已有一个运行正常的Kubernetes集群（版本1.23+）。以下是额外的必要准备：

  1. 安装Helm：确保Helm 3.x客户端已安装。
  2. 配置存储：根据需要，创建合适的StorageClass。例如，在本地测试中使用hostPath，在生产中使用云存储或配置好的Ceph集群。
    # 示例：创建一个使用本地目录的StorageClass (仅用于测试) cat <<EOF | kubectl apply -f - apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer EOF
  3. 加载容器镜像：如果是在离线环境或内部仓库，需要先将towards5gs相关的Docker镜像推送到你的私有仓库，并在values.yaml中更新image.repository字段。
  4. 网络规划：
    • 确定用于N2、N3、N6等接口的IP地址段。
    • 如果使用MetalLB提供LoadBalancer，需要配置地址池。
    • 如果UPF要使用主机网络或SR-IOV，需要在对应节点上配置好物理网卡和驱动。

4.2 分步部署实战

我们采用“由内向外”的顺序部署：先部署内部依赖和服务发现，再部署控制面，最后部署用户面。

步骤一：添加仓库并查看Chart

helm repo add towards5gs https://orange-opensource.github.io/towards5gs-helm/ helm repo update helm search repo towards5gs # 查看所有可用的Chart

步骤二：部署NRF（服务发现核心）NRF是第一个需要部署的组件，因为其他所有网元都要向它注册。

# 1. 创建一个独立的namespace，便于管理 kubectl create namespace 5g-core # 2. 为NRF准备自定义配置 cat > nrf-values.yaml <<EOF replicaCount: 2 image: tag: "v3.2.1" service: type: ClusterIP port: 8000 # 如果NRF需要持久化存储（例如缓存注册信息），可以在这里配置 # persistence: # enabled: true # storageClass: "local-storage" # size: 5Gi EOF # 3. 部署NRF helm install nrf towards5gs/nrf -n 5g-core -f nrf-values.yaml # 4. 检查部署状态 kubectl get pods,svc -n 5g-core -l app=nrf # 等待Pod状态变为Running，并且READY为1/1或2/2。

步骤三：部署UDM/UDR（用户数据管理）UDM是有状态服务，需要数据库。

# 1. 准备UDM配置，重点是指向NRF和配置数据库 cat > udm-values.yaml <<EOF configuration: nrfUri: "http://nrf-svc.5g-core.svc.cluster.local:8000" # 使用完整的K8s内部域名 mongoUri: "mongodb://mongodb-svc:27017" # 假设MongoDB Service名称为mongodb-svc # 如果使用Chart内嵌的MongoDB子Chart mongodb: enabled: true architecture: "standalone" auth: enabled: true rootPassword: "请替换为强密码" # 生产环境应从Secret读取 persistence: enabled: true storageClass: "local-storage" size: 10Gi EOF # 2. 部署UDM (它会自动部署MongoDB) helm install udm towards5gs/udm -n 5g-core -f udm-values.yaml # 3. 检查MongoDB和UDM Pod kubectl get pods -n 5g-core -l 'app in (udm, mongodb)'

步骤四：部署其他控制面网元（AMF, SMF, PCF, AUSF）流程类似，每个都需要一份自定义的values.yaml，核心是正确配置nrfUri以及与其他网元的关联信息（如SMF需要配置UDM、PCF的地址）。

以AMF为例：

cat > amf-values.yaml <<EOF replicaCount: 2 configuration: amfName: "amf-01" nrfUri: "http://nrf-svc.5g-core.svc.cluster.local:8000" servedGuamiList: - plmnId: "20893" # MCC MNC amfId: "cafe00" supportTaiList: - plmnId: "20893" tac: "000001" service: type: ClusterIP serviceExternal: enabled: true type: LoadBalancer # 或NodePort annotations: metallb.universe.tf/address-pool: public-ips ngapPort: 38412 EOF helm install amf towards5gs/amf -n 5g-core -f amf-values.yaml

步骤五：部署UPF（用户面功能）这是最具挑战性的一步，因为涉及高性能网络。

cat > upf-values.yaml <<EOF # 关键：选择正确的网络模式 network: mode: "host" # 可选：host, sriov, macvlan。host模式性能好，但牺牲了可移植性。 # 如果mode=host，需要指定节点选择器，将UPF调度到具有特定网卡的节点上 nodeSelector: node-role.kubernetes.io/upf-node: "" # 配置N3和N6接口的网卡信息（host模式下，直接使用主机网卡） interfaces: n3: dev: "eth1" # 连接基站的网卡 ip: "10.100.0.10/24" n6: dev: "eth2" # 连接互联网的网卡 ip: "192.168.100.10/24" gw: "192.168.100.1" configuration: nrfUri: "http://nrf-svc.5g-core.svc.cluster.local:8000" # UPF特定的配置，如DNN列表、QoS规则等 dnnList: - dnn: "internet" cidr: "60.60.0.0/16" # 为UE分配的IP池 EOF # 首先，给目标节点打上标签 kubectl label nodes <your-upf-node-name> node-role.kubernetes.io/upf-node= # 然后部署UPF helm install upf towards5gs/upf -n 5g-core -f upf-values.yaml

步骤六：使用Umbrella Chart一键部署（可选）对于测试环境，项目可能提供一个“总Chart”，可以一键部署所有组件。

# 下载或克隆仓库，进入umbrella-chart目录 git clone https://github.com/Orange-OpenSource/towards5gs-helm.git cd towards5gs-helm/umbrella-chart # 编辑顶层的values.yaml，配置所有组件的参数 cp values.yaml my-global-values.yaml vim my-global-values.yaml # 一键安装 helm install full-5gc . -n 5g-core -f my-global-values.yaml

4.3 部署后验证与连通性测试

部署完成后，不能只看Pod状态是Running就万事大吉。

  1. 基础状态检查：

    kubectl get pods -n 5g-core # 所有Pod应为Running且Ready kubectl get svc -n 5g-core # 查看Service，特别是LoadBalancer类型的外部IP

  2. 日志检查：查看关键组件日志，确保没有持续报错。

    kubectl logs -n 5g-core deployment/amf --tail=50 kubectl logs -n 5g-core deployment/nrf --tail=50 # 重点关注“registered”、“connected”、“successful”等关键字，以及错误堆栈。

  3. NRF服务注册验证：检查各网元是否成功向NRF注册。

    # 假设NRF Service端口为8000，临时端口转发到本地 kubectl port-forward -n 5g-core svc/nrf-svc 8080:8000 & # 然后访问NRF的API curl http://localhost:8080/nnrf-nfm/v1/nf-instances

    应该返回一个JSON列表，包含已注册的AMF、SMF等网元信息。

  4. 基本信令流程测试：使用5G测试终端模拟器（如UERANSIM）连接你部署的AMF外部IP和端口，尝试发起注册请求。观察AMF、AUSF、UDM的日志，看注册流程是否顺利走通。

5. 常见问题、排查技巧与性能调优实录

5.1 部署阶段常见问题

问题1：Pod一直处于Pending状态。

  • 可能原因：资源不足、节点选择器不匹配、PVC无法绑定。
  • 排查：
    kubectl describe pod <pod-name> -n 5g-core
    查看Events部分。常见信息：
    • Insufficient cpu/memory：调整values.yaml中的resources.requests或为集群增加资源。
    • didn‘t find available persistent volumes：检查StorageClass配置和PV是否可用。
    • node(s) didn‘t match Pod‘s node selector：检查Pod的nodeSelector配置，并确保有节点拥有相应标签。

问题2：Pod处于CrashLoopBackOff状态。

  • 可能原因：容器启动后立即退出，通常是配置错误、依赖服务不可用或镜像问题。
  • 排查：
    kubectl logs <pod-name> -n 5g-core --previous # 查看上一次运行的日志
    • 连接NRF失败：日志中常见“Failed to connect to NRF”。检查nrfUri配置是否正确（注意命名空间5g-core），以及NRF服务是否真的可达（在Pod内执行curl测试）。
    • 数据库连接失败：检查MongoDB连接字符串、用户名密码，以及MongoDB Pod是否就绪。
    • 配置文件语法错误：检查通过ConfigMap注入的配置文件格式（YAML/JSON），确保没有缩进或语法错误。

问题3：Service无法通过域名访问。

  • 可能原因：CoreDNS问题、网络策略阻拦。
  • 排查：
    # 进入一个已存在的Pod（如busybox）进行调试 kubectl run -it --rm debug --image=busybox -n 5g-core -- sh # 在debug容器内 nslookup nrf-svc.5g-core.svc.cluster.local curl -v http://nrf-svc.5g-core.svc.cluster.local:8000
    如果nslookup失败，是DNS问题。如果解析成功但curl失败，可能是网络策略或服务端口问题。

5.2 运行时问题与性能调优

问题4：UPF数据面转发性能不达标。

  • 根因分析：默认的容器网络（veth pair + iptables/ipvs）会引入额外开销。
  • 解决方案：
    1. Host网络模式：如部署示例所示，性能最好，但UPF Pod与主机网络栈绑定，失去了部分K8s特性（如Service网络）。
    2. SR-IOV：为UPF Pod分配一个物理网卡VF（虚拟功能），能获得接近原生性能。需要在节点安装SR-IOV驱动和CNI插件，并在Chart中配置资源请求intel.com/sriov。
    3. eBPF加速：使用Cilium CNI并开启eBPF主机路由（kube-proxy-replacement）模式，可以大幅提升网络性能。
    4. CPU绑核与巨页：在UPF的values.yaml中，为DPDK或高性能转发的进程分配独占CPU核和HugePages。
      resources: limits: cpu: "2" memory: "2Gi" hugepages-2Mi: "1Gi" # 申请巨页 requests: cpu: "2" memory: "2Gi" hugepages-2Mi: "1Gi" # 使用CPU管理器策略为Pod分配独占CPU # 需要在kubelet开启--cpu-manager-policy=static，并为节点打上标签

问题5：控制面网元（如SMF）处理延迟高。

  • 排查方向：
    1. 资源瓶颈：使用kubectl top pods查看CPU/内存使用率。如果持续接近limits，需要调高。
    2. 依赖服务延迟：SMF需要频繁调用UDM、PCF。检查这些下游服务的响应时间。可以给这些服务添加Sidecar代理（如Envoy）来收集指标，或直接查看其日志。
    3. 垃圾回收（GC）：对于JVM或Go编写的网元，不合理的GC配置可能导致周期性停顿。需要调整容器的JVM/Go GC参数。
    4. 日志级别：生产环境应将日志级别从DEBUG调整为INFO或WARN，减少I/O开销。

问题6：如何实现跨可用区的高可用？

  • 解决方案：
    1. Pod反亲和性：在values.yaml中为关键网元（AMF, SMF, NRF）配置Pod反亲和性，确保同一应用的多个副本被调度到不同的节点或可用区。
      affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - amf topologyKey: topology.kubernetes.io/zone # 或 kubernetes.io/hostname
    2. NRF与数据库的高可用：NRF本身可以多副本，但需要共享存储吗？通常NRF是无状态的（注册信息可重建），多副本即可。UDM的MongoDB则需要部署为副本集，并配置在values.yaml中。
    3. 全局负载均衡：对于暴露给基站的AMF N2接口，可以使用多个LoadBalancer IP，或者在更高层使用DNS轮询/全局负载均衡器（GSLB）将流量分发到不同区域的集群。

5.3 监控与告警搭建

“无监控，不运维”。5G核心网更需要细致的监控。

  1. 集成项目内置的监控：很多towards5gs-helmChart已经集成了Prometheus指标暴露。检查values.yaml中是否有metrics或prometheus相关的配置，将其启用。

    metrics: enabled: true serviceMonitor: enabled: true # 自动创建Prometheus Operator的ServiceMonitor

  2. 关键指标：

    • 控制面：各网元的HTTP/gRPC请求速率、延迟、错误率（5xx响应）；NRF的注册NF数量；AMF的注册用户数、连接基站数；SMF的活跃会话数。
    • 用户面：UPF的吞吐量（bps, pps）、丢包率、转发延迟。
    • 系统资源：Pod的CPU、内存、网络I/O使用率。

  3. 配置Grafana仪表盘：可以从社区寻找或自行制作5G核心网专属的Grafana看板，将上述指标可视化。告警规则（如“AMF注册用户数5分钟内下降90%”、“UPF丢包率>0.1%”）应在Prometheus Alertmanager中配置。

5.4 升级与回滚策略

  1. 版本管理：每次部署或升级都应使用明确的Helm Release版本和Chart版本。在values.yaml中固定所有镜像的标签。
  2. 升级流程：
    # 1. 先查看当前发布状态 helm list -n 5g-core # 2. 拉取最新的Chart helm repo update # 3. 干运行测试升级 helm upgrade <release-name> towards5gs/<chart-name> -n 5g-core -f my-values.yaml --dry-run --debug # 4. 执行升级 helm upgrade <release-name> towards5gs/<chart-name> -n 5g-core -f my-values.yaml # 5. 观察Pod滚动更新状态 kubectl get pods -n 5g-core -w
  3. 回滚：如果升级后出现问题，迅速回滚。
    helm history <release-name> -n 5g-core # 查看历史版本 helm rollback <release-name> <revision-number> -n 5g-core # 回滚到指定版本
  4. 数据库Schema升级：这是最危险的部分。如果新版本Chart要求数据库Schema变更，务必先备份数据库，并仔细阅读Chart的升级说明（通常位于README.md或UPGRADE.md），看是否需要手动执行迁移脚本。
http://www.jsqmd.com/news/786841/

相关文章：

  • ai应用开发中如何利用多模型能力提升系统鲁棒性
  • 为Cursor编辑器打造专属浅色主题：从色彩体系到实践应用
  • 2026年05月09日最热门的开源项目(Github)
  • ArkUI电商首页完整实战
  • CANN/ATVOSS块调度运行接口
  • 人与人的四种差别
  • 5分钟学会：无需越狱导出iOS微信聊天记录的终极方案
  • Hyprland高效截图工具链：集成hyprshot、swappy与pngquant的一键工作流
  • ARM GICv3虚拟化架构与ICH_LR寄存器解析
  • 从零搭建轻量级夜间构建系统：基于Docker与Cron的自动化实践
  • AI应用测试工程2026：如何系统化测试你的LLM应用
  • 基于Vue 3与Vite的快速后台管理框架：fast-soy-admin深度解析
  • 在Taotoken控制台中清晰追踪项目成本与各模型消耗明细
  • BLDC电机控制原理与PID优化实践
  • DeepSeek API调用延迟怎么优化？首字生成时间怎么降低？
  • 边缘部署LLM的混合精度量化技术与优化实践
  • NCM文件格式逆向解析与音频转换技术实现
  • Llama-Chinese项目实战：从中文增量预训练到指令微调部署全解析
  • MCP3551 Delta-Sigma ADC原理与高精度设计实战
  • Atom编辑器终极中文汉化指南：告别英文界面，提升编程效率
  • 抖音视频下载终极指南：3分钟掌握批量无水印下载技巧
  • 工业神经系统：11 老手血泪Tips + 新手避坑清单
  • 系统级自动化测试框架设计：从核心原理到工程实践
  • 32位FMC+SDRAM支持+串行PSRAM：STM32H7A3IIT6的大内存设计
  • Next.js SEO优化实战：使用nextjs-seo-optimizer提升搜索引擎排名
  • Godot双网格瓦片地图系统：实现复杂2D游戏地图的职责分离与高效管理
  • AI模型管理利器：OpenClaw Venice模型切换器原理与实战
  • ImagenTY：基于DashScope API的AI图像生成技能，专为中文渲染与Agent集成设计
  • CCaaS架构：解耦并发控制的分布式数据库创新设计
  • 容器化定时任务管理：基于Docker与Cron的轻量级解决方案