网云融合
-
date_range 23/01/2023 09:09
点击量：次infosort网随云动label
目录
- eBPF + OVS 双数据面
- 三大 CNI 深入对比
- OVN 北向与南向数据库
- KubeVirt 虚拟机网络
- 云网分层架构
- 云的五个层面
- SDN 隧道业务映射
- DSCP 优先级标签
- DetNet Controller 完整架构
- 面试话术汇总
一、eBPF + OVS 双数据面
1.1 为什么需要 eBPF 补充 OVS
OVS 能做的流分类（L3/L4）：
| 能力 | 支持 |
|---|---|
| 源/目的 IP | ✅ |
| TCP 端口 | ✅ |
| DSCP 值 | ✅ |
| HTTP URL 内容 | ❌ |
| HTTP Header | ❌ |
| gRPC 方法名 | ❌ |
问题场景：
同一个 SCADA 服务（IP 和端口都一样）有两种请求：
POST /api/scada/control → 实时控制指令（必须 < 5ms）
GET /api/scada/history → 历史数据查询（无所谓延迟）
OVS 分不出来！因为 IP 和端口完全一样，只有 HTTP URL 不同。
Cilium eBPF 能做的流分类（L7）：
| 能力 | 支持 |
|---|---|
| HTTP URL | ✅ |
| HTTP Method | ✅ |
| HTTP Header | ✅ |
| gRPC 方法名 | ✅ |
1.2 OVS + eBPF 双数据面架构
数据包
│
↓
┌───────────────────────────────────────────┐
│ Cilium eBPF（L7 流分类） │
│ │
│ POST /api/scada/control → 打 DSCP=46 │
│ GET /api/scada/history → 打 DSCP=0 │
│ │
│ eBPF 在内核里执行，性能极高 │
│ 分类完毕后交给 OVS │
└──────────────┬────────────────────────────┘
↓ 已经打好 DSCP 标记的包
┌──────────────┴────────────────────────────┐
│ OVS（L3/L4 路径执行） │
│ │
│ DSCP=46 → SRv6 确定性路径 │
│ DSCP=0 → 普通路由 │
└──────────────┬────────────────────────────┘
↓
物理网络（SDN 管的）
类比：
- eBPF = 安检员（打开箱子看里面是什么），贴紧急/普通标签
- OVS = 传送带调度员（看标签分拣），走紧急通道或普通通道
1.3 完整数据包旅程
紧急请求：
Java 代码发出请求：
POST /api/scada/control HTTP/1.1
X-Priority: emergency
{"action": "emergency_shutdown", "station": "all"}
第1步：DSCP = 0（默认）
第2步：Cilium eBPF 拦截
✅ Method = POST
✅ Path = /api/scada/control
✅ Header X-Priority = emergency
→ DSCP: 0 → 48
第3步：OVS 匹配 DSCP=48
→ 优先级 400（最高）
→ 走紧急 SRv6 路径
第4步：物理网络
→ 最高优先级队列，不排队，直接发
第5步：到达 SCADA 服务器
总延迟 < 2ms ✅
普通请求：
GET /api/scada/history?date=2026-04-13
第2步：Cilium eBPF → DSCP = 0（不修改）
第3步：OVS → 走默认路由，Geneve 隧道
第5步：延迟 5ms~50ms（不保证，够用）
1.4 eBPF vs OVS 分工
| 维度 | Cilium eBPF | OVS |
|---|---|---|
| 位置 | Pod 网卡出口（tc egress hook） | br-int 虚拟交换机 |
| 能力 | L7 内容感知（HTTP/gRPC） | L3/L4（IP/端口/DSCP） |
| 动作 | 修改 DSCP 字段 | 根据 DSCP 选择 SRv6 路径 |
| 性能 | 内核态，纳秒级，零拷贝 | 标准 OVS 性能 |
1.5 Cilium vs Kube-OVN 核心差距
VPC 隔离：
OVN 能做（Cilium 做不了）：
kubectl apply Vpc tenant-a-vpc
→ 两个租户完全独立的虚拟网络
→ 各自有独立 IP 地址空间（可以重叠）
→ 各自有独立路由表、网关
→ VNI 隔离，L2 层完全不通
Cilium 能做：
NetworkPolicy 控制"谁能访问谁"
→ 底层还是同一个网络（IP 不能重叠）
→ 本质是"防火墙规则"，不是"独立网络"
类比：
- OVN VPC = 两栋独立的楼（各自的电梯、大门、门牌号）
- Cilium NetworkPolicy = 同一栋楼里锁了门（同一部电梯，某些楼层不让去）
1.6 正确的组合方案
数据包 → Cilium eBPF（L7 分类，打 DSCP）
↓
OVS/OVN（VPC 隔离 + SRv6 封装）
↓
物理网络（SDN Controller 管的）
| 组件 | 擅长 | 角色 |
|---|---|---|
| Cilium eBPF | L7 流分类、高性能转发、可观测（Hubble） | 流分类 + 打标记 |
| OVN/OVS (Kube-OVN) | VPC/子网/浮动IP、OVS流表、SRv6封装、和物理交换机对接 | VPC隔离 + 路径执行 + SDN桥梁 |
二、三大 CNI 深入对比
2.1 一句话区别
| CNI | 比喻 | 核心技术 |
|---|---|---|
| Calico | 普通公路（红绿灯+路牌） | BGP |
| Kube-OVN | 城市地铁系统（站点/线路/换乘） | OVS/OVN |
| Cilium | 高铁（直达，速度快） | eBPF |
2.2 技术对比
| 维度 | Calico | Kube-OVN | Cilium |
|---|---|---|---|
| 数据面技术 | iptables/IPVS | OVS | eBPF |
| 控制面技术 | BGP + Felix | OVN 北向/南向数据库 | eBPF Agent |
| 内存占用 | ~200MB | ~1.5GB | ~500MB |
| 性能 | 好 | 中等 | 最好（绕过 iptables） |
| VPC 隔离 | ❌ | ✅ | ❌ |
| 子网管理 | ❌ | ✅ | ❌ |
| 浮动 IP | ❌ | ✅ | ❌ |
| NetworkPolicy | ✅ | ✅ | ✅（更强大） |
| 可观测性 | 基础 | 中等 | 最强（Hubble） |
| 学习曲线 | 低 | 高 | 中 |
| 适合场景 | 90% 通用场景 | IaaS/传统网络模型 | 高性能/安全敏感 |
三、OVN 北向与南向数据库
┌──────────────────────────────────────┐
│ 用户 / Kube-OVN Controller │
│ "我要创建一个 VPC，子网 172.16.1.0/24"│
└──────────────┬───────────────────────┘
↓ 写入
┌──────────────┴───────────────────────┐
│ OVN 北向数据库（NB DB） │
│ │
│ 存的是"意图"（设计图）： │
│ ├── 逻辑交换机: tenant-a-switch │
│ ├── 逻辑路由器: tenant-a-router │
│ ├── 逻辑端口: port-1 (172.16.1.2) │
│ └── ACL 规则: 允许 TCP 80 │
└──────────────┬───────────────────────┘
↓ ovn-northd 翻译
┌──────────────┴───────────────────────┐
│ OVN 南向数据库（SB DB） │
│ │
│ 存的是"指令"（施工图）： │
│ ├── 绑定: port-1 在 iaas-1 节点 │
│ ├── 流表: match(ip.dst==172.16.1.2) │
│ │ → action(output:port-1) │
│ └── 隧道: iaas-1 ↔ iaas-2 (Geneve) │
└──────────────┬───────────────────────┘
↓ ovn-controller 执行
┌──────────────┴───────────────────────┐
│ OVS（每个节点上） │
│ 实际转发数据包 │
│ │
│ iaas-1 的 OVS： │
│ 流表1: 目的IP=172.16.1.2 → 端口3 │
│ 流表2: 目的IP=172.16.2.x → 丢弃 │
└──────────────────────────────────────┘
四、KubeVirt 虚拟机场景下的隧道和 SRv6
4.1 VM 在 K8s 里的网络本质
Pod（virt-launcher-vm-01-xxx）
└── 容器：virt-launcher
└── QEMU 进程
└── VM（CirrOS）
└── 虚拟网卡 eth0
IP: 172.16.1.x（VPC 子网）
Pod IP: 10.244.x.x（Kube-OVN分配）
VM IP: 172.16.1.x（VPC 子网）
VM 的网络有两层：
| 层次 | IP | 管理者 |
|---|---|---|
| Pod 网络 | 10.244.1.50 | Kube-OVN（Geneve 隧道） |
| VM 内部网络 | 172.16.1.10 | QEMU 虚拟网卡（TAP 设备） |
4.2 完整数据包路径
VM-01(iaas-1) → VM-02(iaas-3) （172.16.1.10 → 172.16.1.20）
封装后的数据包：
┌────────────────────────────────────────────┐
│ 外层 IP: 10.10.10.121 → 10.10.10.123 │ ← 节点真实 IP
│ 外层 UDP: 端口 6081（Geneve） │
│ Geneve 头: VNI=100（tenant-a-vpc 的标识） │ ← VPC 隔离靠这个
│ 内层: 172.16.1.10 → 172.16.1.20 │ ← VM 的真实数据
└────────────────────────────────────────────┘
五、云网分层架构
┌─────────────────────────────────────────────────────────┐
│ L7 应用层 │ Service Mesh（Istio/Dapr） │
│ │ HTTP 路由、重试、限流、熔断 │
├──────────────┼──────────────────────────────────────────┤
│ L4 传输层 │ kube-proxy / Service │
│ │ TCP 负载均衡、端口转发 │
├──────────────┼──────────────────────────────────────────┤
│ L3 网络层 │ K8s CNI（Calico/Kube-OVN/Cilium） │
│（虚拟） │ Pod IP、VPC、Overlay 隧道 │
│ │ → 管"Pod 之间怎么通信" │
╠══════════════╪══════════════════════════════════════════╣
│ L3 网络层 │ 你的 SDN 控制器 │
│（物理） │ BGP/OSPF 路由、SRv6 路径、DetNet QoS │
│ │ → 管"真实路由器之间怎么转发" │
├──────────────┼──────────────────────────────────────────┤
│ L2 链路层 │ 你的 SDN 控制器 │
│ │ VLAN、MAC 表、交换机端口 │
└──────────────┴──────────────────────────────────────────┘
↑↑↑ 上方：K8s 管的（虚拟世界）
↓↓↓ 下方：你的 SDN 管的（物理世界）
类比：
| 系统 | 类比 | 管理范围 |
|---|---|---|
| 你的 SDN | 交通局 | 路由器、交换机、SRv6 路径 |
| K8s CNI | 园区物业 | OVS、Geneve 隧道、Pod 网络 |
| Service Mesh | 快递调度系统 | 应用之间的请求级别 |
5.1 K8s 内部延迟的本质
VM(node-01) → OVS → Geneve 封装 → 物理网卡 → [物理交换机] → 物理网卡 → OVS → VM(node-50)
↑
这段是物理网络！
你的 SDN 管的！
结论：优化 K8s 内部延迟 = 优化数据中心内部的 SDN 路径
六、云的五个层面
6.1 资源池化（第1层）
传统 IT vs 云平台：
| 方式 | CPU 利用率 |
|---|---|
| 传统（固定分配） | < 20% |
| 云（K8s 统一调度） | > 70% |
6.2 基础设施即代码（第2层）
# 一个 YAML 交付完整租户基础设施（30秒）
---
# 网络：VPC
apiVersion: kubeovn.io/v1
kind: Vpc
metadata:
name: finance-vpc
---
# 计算：VM
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: finance-db
spec:
running: true
template:
spec:
domain:
cpu: { cores: 4 }
memory: { guest: 8Gi }
---
# 存储：50G 数据盘
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: finance-db-data
spec:
resources:
requests:
storage: 50Gi
---
# 安全：网络隔离策略
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: finance-isolation
传统方式：3 天 → 云平台：30 秒
6.3 资源弹性（第3层）
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
minReplicas: 3 # 最少 3 个
maxReplicas: 50 # 最多 50 个
metrics:
- type: Resource
resource:
name: cpu
target:
averageUtilization: 70 # CPU 超 70% 自动扩容
6.4 应用编排（第4层）
# 一条命令部署完整 SaaS 平台
helm install nocobase ./nocobase-chart \
--set tenants=40 \
--set mysql.replicas=3 \
--set redis.replicas=3
# 升级（零停机滚动更新）
helm upgrade nocobase --set image.tag=v2.0
# 回滚（30秒）
helm rollback nocobase 1
6.5 多云编排（第5层）
金融客户 → 自建集群（数据不出境）
普通客户 → 公有云集群（降低成本）
大促流量 → 自动溢出到公有云（弹性）
主集群故障 → 30 秒切到备集群（容灾）
RTO: 4 小时 → 30 秒
七、SDN 隧道业务的映射配置
7.1 三种映射方式对比
| 方式 | K8s 侧配置 | SDN 侧配置 | 粒度 | 适合场景 |
|---|---|---|---|---|
| VLAN 映射 | Provider Network | VLAN 子接口 + 路由策略 | 按 VPC/租户 | 按租户隔离 |
| DSCP 映射 | OVS 流表打标记 | 策略路由匹配 DSCP | 按业务类型/QoS | 按业务 SLA 隔离 |
| 源/目的 IP 映射 | NAT（无需额外配置） | 静态路由区分 | 按目的地 | 简单场景 |
7.2 生产环境组合方案
tenant-a(金融) → VLAN 100
→ DSCP=46 的包 → IPsec 加密隧道（核心交易）
→ DSCP=0 的包 → 普通专线（办公流量）
tenant-b(普通) → VLAN 200
→ DSCP=34 的包 → GRE 隧道（业务数据）
→ DSCP=0 的包 → 互联网（网页浏览）
7.3 加密说明
| 方式 | 有隧道 | 加密 | 性能 |
|---|---|---|---|
| 方式A（NAT + Geneve） | ✅ | ❌ | 中（封装开销） |
| 方式B（Provider Network） | ❌ | ❌ | 最好（无封装） |
| IPsec | ✅ | ✅ | 中低（加密开销） |
| WireGuard | ✅ | ✅ | 中（比 IPsec 轻量） |
生产建议： 数据中心内部应用层用 TLS；跨数据中心用 IPsec/WireGuard 网络层加密。
八、DSCP 优先级标签详解
8.1 什么是 DSCP
DSCP = 数据包上的”优先级标签”，告诉网络设备这个包重不重要。
IP 头部中的位置：
TOS 字段（8位）
┌──────────────┬────┐
│ DSCP（6位） │ECN │
│ 优先级标签 │2位 │
└──────────────┴────┘
6位 = 0~63，共 64 个等级
8.2 常用 DSCP 值
| DSCP 值 | 缩写 | 含义 | 场景 |
|---|---|---|---|
| 0 | BE | Best Effort，尽力而为 | 网页浏览、文件下载 |
| 10 | AF11 | 低优先级保证 | 后台备份、日志 |
| 26 | AF31 | 中等优先级 | 视频会议、流媒体 |
| 34 | AF41 | 较高优先级 | 重要业务数据 |
| 46 | EF | Expedited Forwarding | SCADA 实时控制、金融交易 |
类比（快递服务等级）：
- DSCP=0 → 普通快递（3-5天）
- DSCP=34 → 次日达
- DSCP=46 → 同城急送（专车直送，不排队）
8.3 标记流程
VM 发出数据包 → DSCP=0（默认）
↓
OVS 流表匹配：这是确定性业务
↓
OVS 修改 DSCP=46
↓
数据包从物理网卡出去（带 DSCP=46）
↓
TOR 交换机 → 最高优先级队列
↓
Spine 交换机 → 最高优先级队列
↓
路由器 → 走 IPsec 加密隧道
一路绿灯，每一跳都优先处理 ✅
九、DetNet Controller 完整架构
9.1 整体架构图
┌───────────────────────────────────────────────────────┐
│ DetNet Controller │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌────────────────┐ │
│ │ CloudWatcher │ │ PathEngine │ │ NetworkClient │ │
│ │ 云侧监听器 │ │ CSPF路径计算 │ │ SDN API 客户端 │ │
│ └──────┬──────┘ └──────┬───────┘ └───────┬────────┘ │
│ │ │ │ │
│ Watch Pod 事件 CSPF 算法计算 调 SDN RESTful API │
│ 配置 OVS 流表 输入：拓扑+约束 GET /topology │
│ 输出：SRv6段列表 POST /path │
│ GET /link-status │
├──────────────┬────────────────────────┬────────────────┤
│ │ │ │
│ K8s API │ SDN RESTful API │
│ OVN API │ │ │
│ ↓ ↓ │
│ ┌───────────────┐ ┌────────────────────┐ │
│ │ K8s 集群 │ │ SDN Controller │ │
│ │ OVS/Kube-OVN │ │ （紫金山开发的） │ │
│ └───────────────┘ └────────────────────┘ │
└───────────────────────────────────────────────────────┘
9.2 组件清单
| 组件 | 作用 | 接口 |
|---|---|---|
| CloudWatcher | 监听 Pod/VM 事件 | K8s API |
| OVSConfigurator | 配置 OVS 流表标记 | OVN API |
| PathEngine (CSPF) | 计算 SRv6 路径 | 内部 |
| SDNClient | 调用 SDN API | REST API |
| ClusterLabeler | 更新集群网络标签 | Karmada |
| SLAMonitor | 监控路径延迟 | REST API |
9.3 四个闭环
闭环1：VM 创建（云 → 网）
用户点击"创建确定性 VM"
↓ ① K8s API
K8s 创建 Pod（VM）
↓ ② Watch 事件
DetNet Controller 收到 Pod Created 事件
↓
├─→ ③ OVN API → OVS 配置流分类 + DSCP 标记
├─→ ④ SDN API GET /topology → 获取全域拓扑
├─→ ⑤ CSPF 算法 → 计算 SRv6 路径
└─→ ⑥ SDN API POST /paths → 创建路径
↓
SDN Controller
↓
Netconf → TOR/Spine/Router
↓ ⑦ 路径就绪
VM 发出数据包 → 确定性延迟 < 5ms ✅
闭环2：VM 迁移（云 → 网，自动适配）
node-01 故障（T+0s）
↓
K8s 自动迁移 VM 到 node-35（T+35s）
↓ ② Watch 事件（NodeName 变化）
DetNet Controller 检测到
↓
├─→ ③ SDN API → 查 node-35 接在 TOR-4
├─→ ④ CSPF → 重算路径
├─→ ⑤ OVN API → 更新 node-35 OVS 流表
└─→ ⑥ SDN API → 更新路径
↓
5秒内路径恢复 ✅
总中断时间：~45秒（K8s 迁移 35s + DetNet 路径恢复 5s）
闭环3：链路拥堵（网 → 云，SLA 自愈）
Spine-2 拥堵（AI 训练流量打满）
↓ ① 每秒轮询
SDN API → 延迟 8ms（超标！）
↓ ② 触发重算
SDN API → Spine-2 利用率 95%
↓ ③ CSPF 避开 Spine-2
新路径：TOR-4 → Spine-1 → TOR-5（绕开拥堵）
↓ ④ 更新路径 + 上报 Prometheus
延迟恢复到 3.5ms ✅
闭环4：网络能力影响调度（网 → 云）
每 30 秒检测网络能力
↓
北京区域：detnetCapable=true
上海区域：detnetCapable=true
公有云区域：detnetCapable=false
↓
Karmada 更新集群标签
↓
用户创建确定性 VM
→ PropagationPolicy 匹配 detnet/capable=true
→ 只有 iaas-cluster 满足
→ VM 自动调度到 iaas-cluster ✅
→ 触发闭环1
9.4 OVN API vs Netconf 分工
| 接口 | 管什么 | 能力 |
|---|---|---|
| OVN API | OVS 层面（段1） | ✅流分类 ✅DSCP ✅SRv6封装 ❌物理路径 |
| Netconf（数据中心内部） | TOR/Spine 物理交换机（段2） | ✅路径转发 ✅QoS队列 ✅拓扑感知 |
| Netconf（骨干网） | 骨干网路由器（段3） | ✅跨数据中心SRv6路径 |
十、面试话术汇总
10.1 eBPF + OVS 双数据面
“在 DetNet 架构中，我们采用 Cilium eBPF + OVS 双数据面实现精细化流分类。OVS 只能做到 L3/L4 级别的匹配，但同一个 SCADA 服务的实时控制指令和历史查询用的是同一个 IP 和端口，OVS 区分不了。所以我们在 Pod 出口处挂载 Cilium eBPF 程序，在内核态解析 HTTP Method、URL Path 和 Header，根据 L7 内容给数据包打不同的 DSCP 标记——POST /api/scada/control 打 DSCP=46 走确定性路径，GET /api/scada/history 保持 DSCP=0 走普通路由。eBPF 负责’看内容贴标签’，OVS 负责’看标签选路径’，SDN Controller 负责’按路径配设备’。三层配合实现了同一个服务内不同 API 走不同网络路径的精细化流量治理。”
10.2 K8s 内部延迟本质
“K8s 内部节点间的通信本质上走的还是物理 Spine-Leaf 网络，Geneve 隧道只是在两端做封装拆封装，中间的传输延迟完全取决于物理网络路径。所以 DetNet Controller 在 K8s 集群内部做的’优化’，本质上是通过 OVN API 间接控制底层物理交换机的转发路径——把 SRv6 段列表从 OVS 延伸到 TOR、Spine 交换机，再延伸到骨干网路由器，形成端到端的统一路径控制。Kube-OVN 的价值不在于延迟优化，而在于 IP 管理、VPC 隔离和声明式网络管理。”
10.3 云网融合（完整版）
“网云融合平台的’云’体现在五个层面：
- 资源池化：计算、存储、网络通过 K8s 统一调度，利用率从 20% 提升到 70%。
- 基础设施即代码：租户的 VPC、VM、存储、安全策略用一个 YAML 声明式交付，从 3 天缩短到分钟级。
- 弹性伸缩：HPA 自动扩缩容，峰值流量溢出到公有云，成本降低 60%。
- 应用编排：Helm 标准化整个 SaaS 技术栈，新环境 30 分钟交付。
- 多云联邦：Karmada 统一管理自建和公有云集群，30 秒跨云容灾。
‘融合’体现在：VM 迁移后 DetNet Controller 自动重算 SRv6 路径；确定性业务通过 Karmada 自动调度到有 DetNet 能力的集群。最终实现从 VM 创建到网络路径到 QoS 保证的端到端自动化。”
10.4 DetNet Controller
“DetNet Controller 是云网融合的核心编排器，通过两个接口实现双向联动。云侧通过 K8s Watch 机制监听 Pod/VM 生命周期事件，通过 OVN API 在 OVS 上配置流分类和 DSCP 标记。网侧通过 SDN Controller 的 RESTful API 获取全域物理拓扑、创建和更新 SRv6 路径——DetNet Controller 不直接操作物理设备，而是调用 SDN Controller 的 API，由 SDN Controller 负责通过 Netconf 逐设备下发。这形成了四个闭环：VM 创建触发路径建立、VM 迁移触发路径重算、链路拥堵触发路径自愈、网络能力检测反向影响 Karmada 调度决策。”
10.5 SDN 隧道映射
“K8s 虚拟网络与 SDN 物理隧道的映射通过两个标识实现：VLAN ID 做租户级映射，DSCP 做业务级映射。K8s 侧通过 Kube-OVN Provider Network 将 VPC 映射到物理 VLAN，同时在 OVS 上为不同 QoS 等级的流量打 DSCP 标记。SDN 侧物理路由器通过策略路由匹配 VLAN + DSCP 组合，将流量导入对应的隧道——金融租户的核心业务走 IPsec 加密隧道，普通租户走 GRE 隧道，公有云对接走 VXLAN 隧道。DetNet Controller 统一编排两侧配置：OVN API 管入口标记，Netconf 管隧道路由，实现从 VM 创建到隧道映射的全自动化。”
附录：关键 YAML 参考
readinessProbe 配置
readinessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 3
无 readinessProbe：容器启动就分配流量，Spring Boot 还在初始化 → 报错 500
有 readinessProbe：返回 200 才分配流量 → 用户请求正常响应
KubeVirt VM 创建
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: scada-vm
namespace: tenant-a
spec:
running: true
template:
spec:
domain:
cpu:
cores: 4
memory:
guest: 8Gi
devices:
interfaces:
- name: default
masquerade: {} # NAT 模式
networks:
- name: default
pod: {}
Karmada 确定性业务调度
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
name: detnet-policy
spec:
resourceSelectors:
- apiVersion: kubevirt.io/v1
kind: VirtualMachine
labelSelector:
matchLabels:
sla: deterministic
placement:
clusterAffinity:
matchLabels:
detnet/capable: "true" # 只调度到有 DetNet 能力的集群
数据来源：全国农村集体资产监督管理平台 · 紫金山实验室网云融合项目实践
评论：
技术文章推送
手机、电脑实用软件分享
微信公众号：AndrewYG的算法世界