Google Cloud 的多网络方法使通讯提供商能够克服这些限制,从而实现以下功能,但不限于:
- 严格的网络隔离:通过隔离 Kubernetes 内的管理、信令和媒体流量来强制遵守法规并增强安全性。
- 最高性能:对于需要硬件加速(例如 SR-IOV)的通讯应用,实现要求苛刻的 5G 移动核心、RAN 和数据平面工作负载所需的高吞吐量和低延迟。
现有的解决方案例如Multus,它是 Kubernetes 中多宿主 Pod 的元插件,但它有一些缺点:
- 难以使用:Multus 依赖于非结构化的基于字符串的注释,使得配置复杂且容易出错。
- 不灵活:它不允许向 Pod 动态添加或删除网络,从而产生运营开销并限制适应性。
- Kubernetes 集成有限:Multus 缺乏对
- 网络策略:跨多个网络实施安全性很困难。
- 网络服务:不支持使用辅助接口的应用程序的负载平衡和运行状况检查。
- 可观察性差:Multus 使得多网络设置的监控和故障排除变得困难。
Google Cloud 的方法将多网络原生集成到 Kubernetes 中。这使得 Kubernetes 服务、负载均衡器、边界网关协议 (BGP) 和网络策略的使用变得很容易——这对于构建强大的通讯网络至关重要。我们还与 Kubernetes 社区一起研究这个概念,作为云原生计算基金会(CNCF) Kubernetes 增强提案的一部分。
爱立信等合作伙伴支持 Google Cloud 的多网络方法,重点关注满足通讯用例的特定需求。
“谷歌的多网络功能解决了通过网络分离确保通讯部署的安全性和运营效率,同时保留 Kubernetes 标准网络功能的挑战。值得注意的是,谷歌的多网络功能如何在不影响功能的情况下为这一挑战提供解决方案。” – 爱立信
在本博客中,我们探讨了多网络支持的关键通讯用例。我们还深入研究了Google 分布式云(GDC) 中的两个具体实现示例:在 4G/5G 移动核心部署中隔离移动管理实体 (MME) 和归属用户服务器 (HSS) 之间的信令流量,以及隔离网络暴露功能 (NEF) 及其应用功能 (AF) 对等体。
多网络用例#1
云原生网络功能 (CNF) 应用程序需要在其 Kubernetes Pod 中配置额外的接口。出于监管合规性目的,每个接口都必须位于隔离的网络中。隔离必须在第 2 层网络上完成。
多网络用例#2
CNF 应用程序需要向工作负载 Pod 提供基于硬件的接口(例如 SR-IOV VF)。用户空间应用程序(例如基于 DPDK)将利用硬件来实现性能目的(高带宽、低延迟)。
4G/5G组网场景多组网应用
多网络用例:S6a 流量
现在,我们来看看4G移动核心网的移动管理实体(MME)和归属用户服务器( HSS)功能之间组网的多网络框架的具体使用。在4G移动网络中,MME和HSS是负责管理用户连接和安全的关键网元:
- 女士:
- 处理用户连接/分离过程,在网络上注册和取消注册设备
- 当用户移动时管理蜂窝塔之间的切换
- 路由传入和传出的呼叫以及来自/来自用户的数据流量
- 高速钢:
- 存储订阅者信息,例如身份验证凭据、订阅详细信息和漫游协议
- 执行身份验证和授权程序以验证用户身份和访问控制
- 向MME提供用户位置信息以用于紧急服务和其他目的
MME 和 HSS 共同提供安全、流畅的用户体验,同时保持网络效率和用户信息完整性。
该连接场景重点介绍了上述用例 1 的特定应用,目的是通过隔离信令网络在连接配置中使用 GDC 连接 MME 和 HSS Pod,该网络提供完全托管的硬件和软件产品,可提供配备 AI、安全性的现代应用程序,并在边缘开源。在此实现中,MME 使用 MACVLAN 类型的接口,HSS Pod 使用单独的多网络接口将 Diameter 流量引导到同一信令网络上。
apiVersion: networking.gke.io/v1
kind: Network
metadata:
name: signaling-network
annotations:
networking.gke.io/gdce-vlan-id: 200
networking.gke.io/gdce-vlan-mtu: 2000
networking.gke.io/gdce-lb-service-vip-cidrs: “10.1.1.0/24”
spec:
type: L2
nodeInterfaceMatcher:
interfaceName: "sig-interface-200"
gateway4: "192.168.200.1"
l2NetworkConfig:
prefixLength4: 24
apiVersion: v1
kind: Pod
metadata:
name: myPod
annotations:
networking.gke.io/interfaces: [{"interfaceName":"eth1","interface":"sig-interface-200"}]
networking.gke.io/default-interface: eth1
...
现在,让我们看看多网络框架在网络暴露功能 (NEF) 及其应用功能 (AF) 对等点(5G 网络架构中的两个节点)之间联网的具体用途:
- NEF –该网络功能提供了一种将 3GPP 网络功能提供的服务和功能安全地公开给应用程序的方法
- AF 对等 – 此网络功能在流量管理和 QoS 分配中发挥着关键作用。
在此场景中,NEF 的 AF Peer 驻留在客户的信任域中,并连接到信令网络 (VRF)。默认情况下,NEF Pod 通过其主接口连接到默认网络 (VRF)。为了将流量保持在同一 VRF 上,我们在 NEF Pod 上启用信令多重网络,将它们连接到信令网络。
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
labels:
networking.gke.io/nf-operator-autocreated: "true"
name: signaling-network-bgplb
namespace: kube-system
spec:
network: signaling-network
peerSelector:
cluster.baremetal.gke.io/multinetwork-peer: "true"G
apiVersion: v1
data:
config: |
address-pools:
- name: signaling
protocol: bgp
addresses:
- 10.1.1.0/24
kind: ConfigMap
metadata:
annotations:
networking.gke.io/network: signaling-network
name: signaling-network-vip-pool
namespace: metallb-system
labels:
nf-operator-created: true