简介本资源是一份面向Kubernetes网络运维工程师、云原生架构师及容器平台建设者的Kube-OVN深度技术文档系统解析这一CNCF沙盒项目的原理、组件与落地实践。文档完整覆盖其三大核心优势依托OVN/OVS实现的子网管理、VPC多租户、跨集群互联等丰富SDN功能通过eBPF、DPDK及内核优化达成的近主机网络性能以及一键安装脚本、Grafana监控看板和kubectl-ko命令行工具带来的极简运维体验。资源为1个1.77MB的Word文档.docx内容结构清晰包含项目定位、安装环境K8s 1.19/CentOS 7.9、全量组件详解ovn-central、kube-ovn-controller、kube-ovn-cni、kube-ovn-speaker等、各模块交互逻辑及功能验证清单。目前已有433人学习下载适合希望深入理解Kube-OVN控制面与数据面协同机制、快速部署生产级容器网络的技术人员。1. Kube-OVN 不是“又一个 CNI”它是把 SDN 能力真正焊进 Kubernetes 的生产级网络底座你有没有遇到过这种场景Kubernetes 集群跑得稳但一加 NetworkPolicy 就延迟飙升想给某个关键 Pod 绑定固定公网出口 IP 做白名单却发现原生 Service LoadBalancer 根本不支持 EIP 映射或者调试跨 Namespace 流量时抓包发现 iptables 规则层层嵌套像掉进黑匣子迷宫——不是不会配而是原生网络模型压根没给你留出精细控制的接口。Kube-OVN 就是为这类真实生产卡点而生的它不抽象、不妥协直接把 OVN/OVS 这套经过电信级验证的 SDN 控制平面以 Kubernetes 原生资源Subnet/VPC/ProviderNetwork的方式暴露出来。它适合三类人正在做容器网络毕设/课设需要拿得出手的完整方案的学生运维千节点集群、被多租户隔离和 QoS 限速折磨过的 SRE以及评估云原生网络选型的技术负责人——你要的不是“能跑”而是“能管、能查、能审计、能扩容”。本文不讲概念对比只拆解一套可落地、可答辩、可直接复用于生产环境的 Kube-OVN 完整方案从需求锚定、架构设计、模块实现到验收 checklist 全链路覆盖。2. 总体架构设计三层解耦结构与四大核心组件的职责边界Kube-OVN 的架构不是简单堆砌组件而是按“控制-数据-运维”严格分层每层有明确输入输出和故障域隔离。这种设计让排查问题时能快速定位到责任模块也方便你在毕设答辩中清晰阐述系统边界。下面这张结构图不是示意而是你部署后实际运行时各组件的真实拓扑关系--------------------- ----------------------------------- | Kubernetes API | | OVN/OVS Control Plane | | (etcd, kube-apiserver) | | ovn-nb (Northbound DB) | | |---| ovn-sb (Southbound DB) | ------------------ | ovn-northd (Translator) | | ---------------------------------- | | v v ---------------------- --------------------------- | kube-ovn-controller | | ovs-ovn (per-node Agent) | | - 监听 Pod/Service/ |-------| - ovn-controller (SB→OVS) | | Subnet/VPC 等事件 | | - ovs-vswitchd (datapath) | | - 调用 ovn-nb 写配置 | | - ovsdb-server (local DB) | | - 注入 annotation | --------------------------- ---------------------- | | --------------------------- | kube-ovn-cni (per-node) | | - 实现 CNI ADD/DEL 接口 | | - 创建 veth pair 绑定 OVS port | | - 配置 ovn0 网卡 主机路由 | | - 动态更新 iptables/ipset | ---------------------------这个三层结构里最常被误解的是kube-ovn-controller 和 ovs-ovn 的协作边界。很多初学者以为 controller 直接下发流表到 OVS其实不然controller 只操作ovn-nb北向数据库由ovn-northd将逻辑网络翻译成ovn-sb中的逻辑流表再由每个节点上的ovn-controller拉取ovn-sb数据最终生成本地 OVS 流表。这种解耦带来两个硬性好处一是 controller 故障不影响已有 Pod 通信流表已固化在 OVS二是ovn-sb作为中间状态天然支持跨集群同步比如ovn-k8s的跨集群互联就是基于此。2.1 上游 OVN/OVS 组件为什么必须用 ovn-central 而非单机模式ovn-central是 Kube-OVN 的控制中枢它由三个核心进程组成缺一不可ovn-nb存储所有逻辑网络定义Subnet CIDR、VPC 路由、ACL 规则。Kube-OVN 所有自定义资源如SubnetCRD最终都映射为ovn-nb中的Logical_Switch和ACL记录。ovn-sb存储运行时状态包括每个节点上报的Chassis物理主机标识、Encap隧道封装方式、Port_Binding逻辑端口绑定到哪个节点。这是 Kube-OVN 支持大规模集群的关键——controller 不需要轮询节点状态直接查ovn-sb即可。ovn-northd实时监听ovn-nb变更将逻辑网络如Logical_Switch编译为ovn-sb中的Logical_Flow。它的性能直接影响集群扩缩容速度。Kube-OVN 对其做了深度裁剪默认禁用stateful相关 flow如连接跟踪因为 Kubernetes Pod 生命周期短不需要会话保持。提示ovn-central必须以 Deployment 形式部署非 StatefulSet且ovn-nb和ovn-sb必须共存于同一 Pod。这是 OVN 官方要求也是 Kube-OVN 一键脚本强制校验的点。若你手动部署时分开会出现ovn-northd无法连接ovn-sb的报错日志里会反复打印failed to connect to sb db。2.2 核心控制器与 Agentkube-ovn-controller 如何把 Kubernetes 资源翻译成网络行为kube-ovn-controller是整个系统的“翻译官”它不处理任何数据包只做两件事监听 Kubernetes 事件和调用 OVN API 更新配置。它的设计哲学是“最小化侵入”——所有网络配置变更都通过标准 OVN DB 接口而非直接操作节点 OVS。这使得它与底层 CNI 解耦也为未来替换为 eBPF datapath 留下接口。以创建一个带静态 IP 的 Pod 为例完整流程如下用户提交 Pod YAML其中annotations: {ovn.kubernetes.io/ip_address: 10.16.10.100}kube-ovn-controller监听到 Pod 创建事件检查 annotation 中的 IP 是否在所属 Subnet 的 CIDR 内若合法调用ovn-nb的ls-add-port接口在对应Logical_Switch上创建Logical_Port并设置addresses[10.16.10.100]同时写入ovn-nb的Logical_Router_Port为该 Pod 添加静态路由下一跳指向所在节点的chassis最后将分配结果回写到 Pod annotationovn.kubernetes.io/ip_address: 10.16.10.100和ovn.kubernetes.io/mac_address: 00:00:00:11:22:33kube-ovn-cni在节点上读取这些 annotation执行本地 OVS 配置创建 veth、绑定 port、设置 MAC这个过程的关键在于IP 分配发生在 controller 层而非 cni 层。这意味着即使某个节点的kube-ovn-cni暂时宕机只要ovn-central正常IP 地址就不会被重复分配——这是 Kube-OVN 支持高可用集群的底层保障。2.3 监控与运维组件为什么 kubectl-ko 和 kube-ovn-pinger 是生产环境刚需Kube-OVN 的运维工具不是锦上添花而是解决“看不见、查不清、改不动”三大痛点的刚需kubectl-ko这是 Kube-OVN 的kubectl插件提供ko get subnet、ko describe vpc等命令。它不依赖 Grafana直接从ovn-nb读取原始数据比kubectl get查 CRD 更准确CRD 可能因 controller 延迟未同步。例如ko get subnet default会显示该子网实际已分配的 IP 数量、剩余 IP、关联的 VPC 名称这些信息在 CRD 的 status 字段里并不完整。kube-ovn-pinger每个节点上运行的 DaemonSet持续向ovn0网卡发送 ICMP 包并统计丢包率、延迟。它的指标如ovn_pinger_latency_seconds直接反映 OVS 数据面健康度。当出现网络抖动时先看pinger指标是否异常再决定是查 controller 日志还是节点 OVS。kube-ovn-monitorDeployment 形式从ovn-sb拉取Chassis状态、Encap类型、Port_Binding数量等元数据。它提供的ovn_sb_chassis_up指标是判断节点是否成功接入集群的黄金标准——如果某节点ovn-sb中没有对应的Chassis记录说明ovs-ovnAgent 未正常启动或网络不通。注意kube-ovn-speaker仅在启用 BGP 模式时才需要。如果你的环境是纯内网或使用云厂商 SLB可以禁用它以减少组件复杂度。Kube-OVN 一键脚本默认不启用 speaker这点和 Calico 不同。3. 关键功能实现从静态 IP 到流量镜像的 7 个生产级能力落地Kube-OVN 的价值不在“支持多少功能”而在每个功能是否能闭环交付。下面这 7 个能力是我在某高校容器平台升级项目中实际落地、并通过等保三级验收的核心项。每一项都给出可直接粘贴执行的 YAML、关键参数说明以及为什么这样写——不是教你怎么抄而是让你懂背后的约束条件。3.1 静态 IP 分配如何确保 Pod 每次重启都拿到同一个 IP静态 IP 是 Kube-OVN 最常用也最容易翻车的功能。很多人以为加个 annotation 就行但实际要同时满足三个条件Subnet 必须启用exclude_ips排除 IP 段避免 controller 把你指定的 IP 当作空闲地址分配出去Pod annotation 中的 IP 必须在 Subnet CIDR 内且不能是网关、广播地址如果 Subnet 启用了 DHCP需显式关闭spec.dhcpEnable: false否则 DHCP server 可能干扰静态分配# 1. 创建一个预留静态 IP 的 Subnet apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: static-subnet spec: cidr: 10.16.20.0/24 gateway: 10.16.20.1 excludeIps: [10.16.20.1, 10.16.20.254, 10.16.20.100-10.16.20.110] dhcpEnable: false protocol: IPv4# 2. 创建 Pod 并指定静态 IP apiVersion: v1 kind: Pod metadata: name: static-pod annotations: ovn.kubernetes.io/ip_address: 10.16.20.105 spec: containers: - name: nginx image: nginx:alpine设计说明excludeIps字段是关键。它告诉 controller“这段 IP 永远不要自动分配”这样即使你忘记加 annotation也不会误占。10.16.20.100-10.16.20.110这个范围就是为业务 Pod 预留的静态池。实测中我们给 20 个核心服务 Pod 都分配了固定 IP并在 Ingress Controller 中硬编码这些 IP 做健康检查彻底规避了 Service ClusterIP 变更导致的探针失败。3.2 集中式网关让所有出向流量走固定出口 IP满足安全审计要求集中式网关Centralized Gateway是 Kube-OVN 实现“固定出口 IP”的核心机制。它和分布式网关的区别在于所有 Pod 出向流量先被路由到指定节点的ovn0网卡再由该节点执行 SNAT。这样外部看到的源 IP 就是该节点的物理 IP。# 创建一个集中式网关 Subnet apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: central-gw-subnet spec: cidr: 10.16.30.0/24 gateway: 10.16.30.1 gatewayNode: node-gw-01 # 指定网关节点 gatewayType: centralized # 关键必须设为 centralized natOutgoing: true # 关键开启 SNAT protocol: IPv4参数说明gatewayNode必须是集群中已存在的节点名kubectl get node输出的 NAME且该节点必须打上标签kubernetes.io/oslinuxKube-OVN 默认只在 Linux 节点部署 ovs-ovn。natOutgoing: true表示对出向流量做 SNAT源 IP 替换为gatewayNode的物理网卡 IP。如果设为false则只做路由转发Pod 会以自身 IP 直接访问外网需确保外网路由可达。3.3 EIP 与 SNAT如何为特定 Pod 绑定公网 IP 并做端口映射EIPElastic IP是 Kube-OVN 对云厂商公网 IP 能力的模拟。它本质是为 Pod 创建一条 DNATSNAT 规则让外部可通过公网 IP:Port 访问 Pod同时 Pod 出向流量也使用该公网 IP。# 1. 创建 EIP 资源绑定到公网 IP apiVersion: kubeovn.io/v1 kind: Eip metadata: name: web-eip spec: ip: 203.0.113.10 # 你的公网 IP nat: true # 开启 NAT即同时做 DNAT 和 SNAT --- # 2. 创建 Service 并引用 EIP apiVersion: v1 kind: Service metadata: name: web-service annotations: ovn.kubernetes.io/eip: web-eip # 关键关联 EIP spec: type: LoadBalancer ports: - port: 80 targetPort: 80 selector: app: nginx设计说明ovn.kubernetes.io/eipannotation 是触发点。Kube-OVN 会自动在ovn-nb中创建两条规则DNAT203.0.113.10:80 → 10.16.30.105:80Pod IPSNAT10.16.30.105 → 203.0.113.10出向流量这样就实现了“一个公网 IP双向流量统一出口”。注意EIP 的 IP 必须是集群所在网络能路由到的地址不能是私有 IP。3.4 Pod 级 QoS用 ingress_rate 和 egress_rate 精确限制带宽Kube-OVN 的 QoS 不是粗粒度的 namespace 限速而是精确到单个 Pod 的入口/出口带宽控制底层基于 OVS 的qos和queue实现。# 为 Pod 设置入口限速 30Mbps即 ingress_rate30 kubectl annotate --overwrite pod perf-n5jhn \ -n ls1 ovn.kubernetes.io/ingress_rate30 # 设置出口限速 50Mbps kubectl annotate --overwrite pod perf-n5jhn \ -n ls1 ovn.kubernetes.io/egress_rate50参数说明ingress_rate单位是 Mbps兆比特每秒不是 MB/s。Kube-OVN 会将其转换为 OVS 的max-rate参数单位 bit/s。实测中我们给监控采集 Pod 设置ingress_rate5防止其突发流量打满节点带宽给日志推送 Pod 设置egress_rate10避免日志洪峰冲击外网链路。注意QoS 生效需要节点 OVS 版本 ≥ 2.12CentOS 7.9 默认 OVS 是 2.9需手动升级。3.5 流量镜像如何把 Pod 流量复制到指定网卡供 Wireshark 分析流量镜像Traffic Mirroring是 Kube-OVN 的高级功能用于安全审计和 NPM网络性能监控集成。它不修改原始流量而是复制一份到宿主机的指定网卡如mirror0。# 1. 创建 Mirror 资源 apiVersion: kubeovn.io/v1 kind: Mirror metadata: name: pod-mirror spec: mirrorInterface: mirror0 # 镜像出口网卡名 direction: both # both/in/out rate: 100 # 镜像比例% --- # 2. 为 Pod 启用镜像 apiVersion: v1 kind: Pod metadata: name: mirrored-pod annotations: ovn.kubernetes.io/mirror: pod-mirror # 关键关联 Mirror spec: containers: - name: nginx image: nginx:alpine设计说明mirrorInterface必须是宿主机上已存在的网卡。Kube-OVN 会在每个节点上自动创建mirror0如果不存在但建议你提前创建ip link add mirror0 type dummy。direction: both表示同时镜像进出流量rate: 100表示全量镜像。实测 CPU 开销约 7%符合文档所述的 5%~10% 范围。抓包命令tcpdump -i mirror0 -w /tmp/mirror.pcap。3.6 子网管理如何实现 Namespace 级别的网络隔离与策略继承子网Subnet是 Kube-OVN 的核心抽象它让网络策略可以按业务维度组织而非按节点维度。一个 Subnet 可以被多个 Namespace 共享也可以独占。# 创建一个隔离子网禁止跨 Namespace 访问 apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: finance-subnet spec: cidr: 10.16.40.0/24 gateway: 10.16.40.1 disableGateway: false allowSubnets: [] # 空数组表示禁止与其他子网互通 private: true # 关键启用私有子网默认拒绝所有入向流量 protocol: IPv4# 将 finance-ns 绑定到 finance-subnet apiVersion: v1 kind: Namespace metadata: name: finance-ns annotations: ovn.kubernetes.io/subnet: finance-subnet设计说明private: true是实现网络隔离的关键。它会让 Kube-OVN 自动为该子网添加 ACL 规则默认拒绝所有入向连接只允许来自同一子网的流量。allowSubnets: []表示不显式允许任何其他子网进一步加固。这样finance-ns下的 Pod 只能和同子网的 Pod 通信即使它们在不同节点上——这才是真正的逻辑隔离。3.7 多网络插件协同如何让 macvlan CNI 复用 Kube-OVN 的 IPAMKube-OVN 的 IPAM 不仅服务自身还能为其他 CNI如 macvlan、ipvlan提供全局 IP 分配。这解决了多网卡场景下 IP 冲突的难题。# 1. 创建 ProviderNetwork物理网络抽象 apiVersion: kubeovn.io/v1 kind: ProviderNetwork metadata: name: provider-net spec: defaultInterface: ens33 # 物理网卡名 subnets: [provider-subnet] --- # 2. 创建 ProviderNetwork 对应的 Subnet apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: provider-subnet spec: provider: provider-net cidr: 192.168.100.0/24 gateway: 192.168.100.1 excludeIps: [192.168.100.1] protocol: IPv4// 3. macvlan CNI 配置/etc/cni/net.d/10-macvlan.conf { cniVersion: 0.3.1, type: macvlan, master: ens33, ipam: { type: kube-ovn } }设计说明ipam.type: kube-ovn是关键。它告诉 macvlan CNI“别自己分配 IP去调用 Kube-OVN 的 IPAM 接口”。Kube-OVN 会根据ProviderNetwork的配置为 macvlan Pod 分配192.168.100.0/24网段的 IP并自动配置路由。这样一个 Pod 就可以同时拥有 Kube-OVN Overlay 网络用于集群内通信和 macvlan Underlay 网络用于直连物理网络——双网卡方案落地。4. 部署避坑指南8 个新手必踩的翻车点与血泪解决方案Kube-OVN 的安装看似一键但背后隐藏着大量环境适配细节。以下是我带过的 3 个毕设项目、2 个企业 PoC 中学生和工程师最常卡住的 8 个点。每一条都按“现象→原因→解决”展开不是泛泛而谈。4.1 现象install.sh执行后ovn-centralPod 一直CrashLoopBackOff日志显示ovn-nb: connection refused原因ovn-central的ovn-nb和ovn-sb进程启动顺序错误。ovn-northd依赖ovn-sb先启动但脚本默认并行启动导致ovn-northd启动时ovn-sb还未就绪。解决修改install.sh在ovn-centralDeployment 的initContainers中加入健康检查# 在 install.sh 的 ovn-central template 中添加 initContainers: - name: wait-for-ovn-sb image: busybox:1.35 command: [sh, -c, until nc -z localhost 6642; do echo waiting for ovn-sb; sleep 2; done]补充6642是ovn-sb的默认端口。CentOS 7.9 需确保nc命令存在yum install -y nc。4.2 现象kube-ovn-cniPod 启动失败报错failed to copy binary to /opt/cni/bin原因节点/opt/cni/bin目录权限不足或kubelet配置的cni-bin-dir不是/opt/cni/bin。解决检查 kubelet 配置ps aux | grep kubelet | grep cni-bin-dir确认实际路径若为/var/lib/cni/bin则修改install.sh中kube-ovn-cni的hostPathvolumeMounts: - name: cni-bin-dir mountPath: /var/lib/cni/bin # 改为此路径 volumes: - name: cni-bin-dir hostPath: path: /var/lib/cni/bin # 改为此路径4.3 现象LoadBalancer Service 创建后test-pod状态为ContainerCreatingdescribe 显示FailedCreatePodSandBox原因multus-cni未正确安装或macvlanCNI 配置缺失。Kube-OVN 的 LB 依赖 multus 提供多网卡能力。解决确认 multus 已部署kubectl get pods -n kube-system | grep multus检查macvlan配置文件是否存在ls /etc/cni/net.d/*macvlan*若缺失手动创建/etc/cni/net.d/00-multus.conf{ cniVersion: 0.3.1, type: multus, kubeconfig: /etc/cni/net.d/multus.d/multus.kubeconfig, delegates: [ { type: kube-ovn }, { type: macvlan, master: ens33, ipam: { type: host-local } } ] }4.4 现象修改 Subnet 的gatewayNode为ens33后Pod 创建失败日志显示failed to find interface ens33原因gatewayNode字段应填节点名如node1而非网卡名。网卡名应在ProviderNetwork或Subnet.spec.provider中指定。解决错误写法gatewayNode: ens33正确写法gatewayNode: node1并在ProviderNetwork中指定defaultInterface: ens334.5 现象kubectl-ko get subnet返回空但kubectl get subnet能看到资源原因kubectl-ko插件未正确安装或kube-ovn-controller未将 Subnet 状态同步到ovn-nb。解决检查插件kubectl ko version应输出版本号检查 controller 日志kubectl logs -n kube-system deploy/kube-ovn-controller | grep sync subnet若无日志重启 controllerkubectl rollout restart deploy/kube-ovn-controller -n kube-system4.6 现象Pod 级 QoS 设置后无效果tc qdisc show dev ovn0显示无qos规则原因节点 OVS 版本过低 2.12不支持qos功能。解决升级 OVS# CentOS 7.9 升级 OVS 到 2.17 yum install -y https://repos.openvswitch.org/rpm/centos-7/x86_64/openvswitch-2.17.9-1.el7.x86_64.rpm systemctl restart openvswitch重启ovs-ovnDaemonSetkubectl rollout restart ds/ovs-ovn -n kube-system4.7 现象流量镜像后mirror0网卡无流量tcpdump抓不到包原因mirror0网卡未启用ip link set mirror0 up或Mirror资源未正确关联到 Pod。解决启用网卡ip link set mirror0 up检查 Pod annotationkubectl get pod pod-name -o yaml | grep mirror确认Mirror资源状态kubectl get mirror pod-mirror -o yaml检查status.phase是否为Ready4.8 现象多网络插件下macvlan Pod 获取不到 IPkubectl describe pod显示FailedAllocateIP原因ProviderNetwork的subnets字段未包含实际使用的 Subnet 名称。解决错误subnets: []正确subnets: [provider-subnet]且provider-subnet必须已存在5. 验收与答辩用 5 个可量化指标证明你的 Kube-OVN 方案已达到生产就绪答辩不是讲 PPT而是证明你真的把这套网络跑通了、管住了、扛住了。我带过的项目里评委最常问的 5 个问题都对应一个可现场演示的验收动作。下面这份 checklist你照着做一遍答辩时就能拿出真凭实据。5.1 验收指标 1静态 IP 分配成功率 ≥ 99.9%验证方法连续创建 1000 个 Pod这不是理论值而是必须实测的数据。方法很简单写一个脚本循环创建 1000 个带静态 IP 的 Pod统计失败数。# 创建测试脚本 create-static-pods.sh for i in $(seq 1 1000); do cat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: static-pod-$i annotations: ovn.kubernetes.io/ip_address: 10.16.20.$((100i)) spec: containers: - name: nginx image: nginx:alpine EOF done# 检查失败数 kubectl get pods | grep static-pod | grep -v Running | wc -l # 应该 ≤ 1即成功率 ≥ 99.9%为什么这个指标重要它直接证明你的excludeIps配置合理、IPAM 无竞争、controller 吞吐足够。如果失败率高说明 Subnet CIDR 太小或excludeIps漏了网关地址。5.2 验收指标 2集中式网关延迟增加 ≤ 0.2ms验证方法对比分布式 vs 集中式网关用ping测延迟但必须控制变量同一 Pod分别接入分布式网关 Subnet 和集中式网关 Subnet测到相同目标 IP 的延迟。# 1. 创建两个 Subnetdist-subnet分布式、cent-subnet集中式 # 2. 部署两个 Pod分别指定不同 Subnet # 3. 在 dist-pod 中执行 kubectl exec dist-pod -- ping -c 10 10.16.1.1 | tail -1 | awk {print $4} | cut -d/ -f2 # 4. 在 cent-pod 中执行相同命令 # 5. 计算差值cent-delay - dist-delay ≤ 0.2ms这个指标证明集中式网关的性能损耗在可接受范围内。如果超过 0.2ms检查gatewayNode节点 CPU 是否过载或ovn-controller日志是否有flow installation delay。5.3 验收指标 3EIP 端口映射可用性 100%验证方法curl telnet 双校验EIP 不只是能连还要保证长连接稳定。用curl测试 HTTP用telnet测试 TCP 连通性。# 假设 EIP 为 203.0.113.10映射到 Pod 80 端口 # 1. curl 测试 curl -I http://203.0.113.10 --connect-timeout 5 # 应返回 HTTP/1.1 200 OK # 2. telnet 测试验证 TCP 层 echo | telnet 203.0.113.10 80 2/dev/null | grep Connected || echo FAIL # 应输出 Connected如果curl成功但telnet失败说明是应用层问题如果都失败检查ovn-nb中的 DNAT 规则ovn-nbctl list nat | grep 203.0.113.10。5.4 验收指标 4QoS 限速精度误差 ≤ 5%验证方法iperf3 实测带宽用iperf3实测比kubectl annotate设置的值更真实。# 1. 为 pod-a 设置 ingress_rate30 kubectl annotate pod pod-a ovn.kubernetes.io/ingress_rate30 # 2. 在 pod-b同节点中运行 iperf3 server kubectl exec pod-b -- iperf3 -s -D # 3. 在 pod-a 中运行 iper p a hrefhttps://download.csdn.net/download/m0_37767500/88511470 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p