★ FEATURED ARTICLE 简介本资源是一份面向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等及功能验证清单是理解Kube-OVN控制面与数据面协同机制的优质入门与进阶材料。目前已有433人学习下载。1. Kube-OVN 是什么一个能把 Kubernetes 网络“重新定义”的 CNCF 沙盒项目你有没有遇到过这种场景Kubernetes 集群跑得挺稳但一加 NetworkPolicy 就延迟飙升想给某个 Pod 固定一个公网可访问的 IP结果发现得手动配 iptables hostPort Service LoadBalancer三套配置互相打架或者业务要上多租户 VPC翻遍 CNI 插件文档发现要么功能残缺要么性能崩盘——最后只能在 YAML 里硬塞一堆 annotation祈祷它别哪天突然失效。Kube-OVN 就是为解决这类“云原生网络玄学”而生的。它不是另一个轻量级 CNI而是把 OVNOpen Virtual Network这个企业级 SDN 控制平面完整、深度、生产就绪地嫁接到 Kubernetes 上。它不遮掩复杂性但把复杂性封装进声明式 API 和自动化控制器里——比如你只写一行ovn.kubernetes.io/ip_address: 10.16.20.100它就能确保该 Pod 启动时真拿到这个地址、路由可达、ACL 生效、QoS 限速、甚至流量镜像同步开启。这不是“支持”这是“交付”。它适合三类人正在评估容器网络选型的 SRE 工程师尤其关注大规模集群下控制面稳定性、需要子网隔离VPC跨集群互联的平台团队、以及被传统 CNI 在 QoS/静态 IP/集中式网关等场景反复翻车的开发运维混合角色。它不承诺“零配置”但承诺“每项能力都有明确入口、可观测路径和可验证手段”。所谓“物超所值”不是因为它免费而是因为你花一天部署调试的时间能省下未来三个月排查网络抖动、IP 冲突、SNAT 黑盒的血泪经验。2. 安装与初始化从裸 Kubernetes 到生产就绪网络的 7 分钟闭环Kube-OVN 的安装设计非常务实它不假设你已掌握 OVS/OVN 底层也不要求你提前部署 etcd 或独立数据库。整个控制面ovn-central和数据面ovs-ovn全部以 Kubernetes 原生资源方式部署所有状态都存于 etcd —— 这意味着你删掉 kube-ovn namespace网络就干净退出没有残留进程或内核模块。但正因如此环境兼容性必须卡死否则后续所有功能验证都会在第一步就断链。2.1 环境校验为什么 CentOS 7.9 Kernel 5.4 是硬门槛Kube-OVN v1.11当前主流稳定分支对内核版本有强依赖核心原因在于其 eBPF 加速路径和 OVS 内核模块的 ABI 兼容性。Kernel 5.4 会导致ovs-vswitchd启动失败报错类似failed to open netlink socket: Protocol not supported而 CentOS 7.9 默认 kernel 3.10.x必须升级到 elrepo 提供的 5.4.243 或更高。验证命令如下# 检查内核版本必须 ≥5.4 uname -r # 输出应为5.4.243-1.el7.elrepo.x86_64 # 检查 OVS 内核模块是否可用Kube-OVN 安装脚本会自动加载 lsmod | grep openvswitch # 正常应输出openvswitch 286720 0 - Live 0xffffffffc0a0e000 # 检查 systemd 是否启用 cgroup v1Kube-OVN 当前不兼容 cgroup v2 cat /proc/1/cmdline | tr \0 \n | grep cgroup # 若出现 systemd.unified_cgroup_hierarchy1需在 grub 中禁用 cgroup v2提示Docker 19.03 是最低要求但实际建议使用 20.10。旧版 Docker 的--iptablesfalse模式与 Kube-OVN 的 iptables 自管理逻辑冲突会导致 SNAT 规则丢失。若必须用 19.03请确保iptables服务已启动且未被 firewalld 掩盖。2.2 一键安装脚本背后做了什么官方提供的install.sh并非黑匣子它本质是 Kubernetes manifest 的参数化编排器。执行过程分三阶段预检 → 部署 → 初始化。我们拆解关键动作# 下载并执行注意指定 release 分支避免拉取 master 不稳定版 wget https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.11/dist/images/install.sh chmod x install.sh ./install.sh --version v1.11.0 --service-cidr 10.96.0.0/12 --pod-network-cidr 10.16.0.0/12该脚本实际执行以下操作创建kube-ovnnamespace 及 RBAC 权限含hostNetwork、privileged等高权限能力部署ovn-centralDeployment含 ovn-nb, ovn-sb, ovn-northd默认使用嵌入式 etcdovn-central-etcdStatefulSet部署ovs-ovnDaemonSet在每个节点启动ovsdb-server和ovn-controller并自动连接ovn-central部署kube-ovn-controller和kube-ovn-cni后者将二进制文件复制到/opt/cni/bin/kube-ovn并注册为 CNI 插件最关键的一步创建kube-ovn-configConfigMap其中default-subnet字段决定默认子网 CIDR即--pod-network-cidr参数值该子网将被自动创建并绑定到defaultNamespace。安装完成后务必验证核心组件状态# 检查所有 Pod 处于 Running 状态特别注意 ovs-ovn 的 READY 为 2/2 kubectl get pod -n kube-ovn # 检查 CNI 插件是否注册成功应看到 kube-ovn 出现在列表中 ls /opt/cni/bin/ | grep kube-ovn # 检查默认子网是否创建输出应包含 default 子网信息 kubectl get subnet若ovs-ovnPod 卡在ContainerCreating大概率是内核模块未加载或 SELinux 限制CentOS 7.9 默认开启此时需手动执行modprobe openvswitch并临时关闭 SELinuxsetenforce 0。2.3 初始化后必做的三件事安装只是起点以下操作决定后续功能能否落地验证 CNI 链路通路创建一个测试 Pod检查其 annotation 是否注入网络信息kubectl run test-pod --imagebusybox:1.35 -- sleep 3600 kubectl get pod test-pod -o wide kubectl get pod test-pod -o jsonpath{.metadata.annotations} # 正常应看到类似ovn.kubernetes.io/ip_address: 10.16.0.2确认默认子网行为默认子网在 Overlay 模式下启用分布式网关gatewayType: distributed和 SNATnatOutgoing: true。验证方法是进入 test-podping 集群外地址如 8.8.8.8同时在节点上抓包tcpdump -i any icmp and host 8.8.8.8观察源 IP 是否为节点 IP证明 SNAT 生效。启用监控栈非必须但强烈推荐Kube-OVN 自带 Prometheus Exporter但 Grafana 仪表板需单独部署kubectl apply -f https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.11/dist/yaml/monitoring.yaml # 之后通过 port-forward 访问kubectl port-forward svc/kube-ovn-monitor 9090:9090这三步做完你手上就不是一个“装好了的插件”而是一个具备基础连通性、IPAM、SNAT 能力的可验证网络基座。后续所有高级功能EIP、QoS、流量镜像都建立在此之上。3. 核心组件深度解析OVN 控制平面如何与 Kubernetes 对齐Kube-OVN 的架构不是简单地把 OVN 套在 Kubernetes 外壳上而是构建了一套双向翻译引擎一边监听 Kubernetes API Server 的事件流一边驱动 OVN 数据库的状态变更。理解其组件协作逻辑是调试网络异常、定制化扩展、甚至贡献代码的前提。我们按数据流向拆解——从用户创建 Pod 开始到容器网络真正就绪。3.1 上游 OVN/OVSSDN 的“大脑”与“神经末梢”OVN 是一个分层架构ovn-nbNorthbound Database存储用户意图如“创建子网 10.16.0.0/16”ovn-sbSouthbound Database存储物理映射如“节点 node-1 上的逻辑端口 lp-test-pod 绑定到 veth0”ovn-northd是两者间的编译器将高层逻辑转换为底层流表。Kube-OVN 的kube-ovn-controller只与ovn-nb交互绝不触碰ovn-sb—— 这是其稳定性的基石。ovn-centralDeployment 包含三个容器ovn-nb基于内存的键值数据库Kube-OVN 所有 CRDSubnet/VPC/ProviderNetwork最终都转化为ovn-nb中的记录ovn-sb同样基于内存但存储的是ovn-northd编译后的逻辑流ovs-ovnDaemonSet 中的ovn-controller会持续监听ovn-sb变更ovn-northd实时监听ovn-nb生成ovn-sb流表。Kube-OVN 对其做了关键裁剪——移除了 OVN 上游中 Kubernetes 不需要的chassis、encap等冗余表减少内存占用 30%。ovs-ovnDaemonSet 是真正的“数据面代理”每个节点运行ovsdb-server本地 OVS 数据库和ovn-controller连接ovn-sbovn-controller读取ovn-sb中分配给本节点的逻辑端口调用ovs-vsctl命令在本地 OVS Bridgebr-int上创建端口、设置流表、绑定 veth关键细节ovs-ovn不直接操作内核而是通过ovs-vswitchd进程完成所有转发逻辑这意味着所有流量都经过 OVS 内核模块天然支持 conntrack、meter、sample 等高级特性。3.2 kube-ovn-controllerKubernetes 与 OVN 的“翻译官”这是 Kube-OVN 的心脏一个典型的 Kubernetes Operator 实现。它监听 10 种资源事件但核心逻辑只有两条主线主线一Pod 生命周期驱动 IPAM 与端口创建当 Pod 创建事件到达controller 执行查询 Pod 所属 Namespace 的subnetannotation若无则用默认子网调用内存 IPAM 模块分配 IP非随机而是按子网内已用 IP 位图计算下一个可用地址向ovn-nb发送Logical_Switch_Port创建请求携带 IP、MAC、子网 UUID同时写入 Pod annotationovn.kubernetes.io/ip_address,ovn.kubernetes.io/mac_address,ovn.kubernetes.io/router_ip若子网启用了natOutgoing则自动添加NAT记录到ovn-nb的NAT表。参数说明ovn.kubernetes.io/ip_address是 controller 分配的 IPovn.kubernetes.io/router_ip是该子网的网关 IP即ovn0接口 IP两者不同。例如子网10.16.0.0/16的router_ip是10.16.0.1而 Pod IP 是10.16.0.2。主线二NetworkPolicy 转换为 ACL 流表Kube-OVN 不使用 Kubernetes 原生 NetworkPolicy 的ip-tables实现而是将其编译为 OVN 的ACLAccess Control List规则直接注入ovn-nb的ACL表。优势在于ACL 规则在ovn-sb中被编译为 OpenFlow 流表由 OVS 内核模块执行性能远高于 userspace iptables支持to-lport/from-lport方向控制可精确到单个逻辑端口与子网 ACL 合并避免规则爆炸Cilium 的 BPF Policy 也类似但 Kube-OVN 的 ACL 是纯 SDN 层不依赖 BPF JIT。3.3 kube-ovn-cniCNI 接口的“最后一公里”kube-ovn-cni是标准 CNI 插件二进制由 kubelet 调用。它不处理 IP 分配那是 controller 的事只做两件事Add 操作根据 Pod annotation 中的 IP/MAC调用ovs-vsctl创建 veth pair一端挂到br-int另一端注入容器命名空间配置容器内路由ip route add default via router_ipDel 操作清理 veth、OVS 端口、iptables 规则如 SNAT 相关的KUBE-POSTROUTING链。避坑点kube-ovn-cni默认使用host-localIPAM但 Kube-OVN 强制覆盖此行为——它忽略 CNI 配置中的ipam字段完全信任 controller 注入的 annotation。因此切勿修改/etc/cni/net.d/下的 kube-ovn 配置文件中的ipam部分否则会导致 IP 冲突或分配失败。3.4 监控与运维组件让黑匣子变透明Kube-OVN 的可观测性设计非常扎实不是简单暴露指标而是分层建模组件数据来源关键指标示例排查价值kube-ovn-pinger节点本地pingovs-ofctl dump-flowsovs_pinger_latency_ms,ovs_flow_count定位节点级 OVS 性能瓶颈如流表溢出kube-ovn-monitorovn-nb/ovn-sb数据库查询ovn_nb_logical_switch_count,ovn_sb_chassis_count监控控制面资源水位如子网数、逻辑端口数kubectl-koCLI 直接调用 Kube-OVN APIko subnet list,ko pod ip快速诊断单个资源状态替代kubectl get例如当发现某 Pod 无法访问外网标准排查链路是kubectl ko pod ip pod-name→ 确认 IP 和子网是否正确kubectl ko subnet get subnet-name→ 检查natOutgoing和gatewayTypekubectl logs -n kube-ovn ovs-ovn-pod→ 查看ovn-controller是否上报错误如no chassis for logical portovs-ofctl dump-flows br-int \| grep pod-mac→ 在节点上直查 OVS 流表命中情况。这套组合拳让网络问题不再停留在“连不通”的模糊状态而是能精准定位到 OVN 数据库、OVS 流表、或内核转发环节。4. 功能验证实战从 LoadBalancer 到流量镜像的 8 个关键场景Kube-OVN 的功能列表很长但真正影响生产落地的是那些高频、刚需、且传统 CNI 难以优雅实现的场景。我们跳过理论直接给出每个功能的最小可验证 YAML 验证命令 常见失败现象。所有操作均基于 v1.11默认子网已启用。4.1 LoadBalancer Service用 macvlan 实现“真”四层负载均衡Kube-OVN 的 LoadBalancer 不走 NodePort 或 iptables DNAT而是通过multus-cnimacvlan为 Service 分配独立网卡让外部流量直通 Pod。这是它区别于其他 CNI 的核心竞争力。前提条件已安装multus-cniKube-OVN 官方提供一键安装脚本物理网卡如ens33需处于UP状态且未被其他 CNI 占用Service 必须在defaultVPC 下自定义 VPC 需额外配置vpc-nat-gw。验证步骤创建 macvlan NetworkAttachmentDefinition# macvlan-conf.yaml apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: macvlan-conf namespace: default spec: config: { cniVersion: 0.3.1, type: macvlan, master: ens33, # 注意此处必须是真实网卡名 mode: bridge, ipam: { type: static } }kubectl apply -f macvlan-conf.yaml创建 LoadBalancer Service# lb-service.yaml apiVersion: v1 kind: Service metadata: name: nginx-lb annotations: k8s.v1.cni.cncf.io/networks: macvlan-conf # 绑定 macvlan 网络 spec: type: LoadBalancer ports: - port: 80 targetPort: 80 selector: app: nginx部署 Nginx Pod 并验证kubectl run nginx --imagenginx:alpine --expose --port80 kubectl get service nginx-lb # 查看 EXTERNAL-IP应为 ens33 网段内的 IP curl http://EXTERNAL-IP # 从集群外机器访问避坑 / 常见问题 / 排查现象一Service 的EXTERNAL-IP一直为pending且kube-ovn-pinger日志报failed to allocate ip from macvlan。原因macvlan-conf中master字段填写错误如写成eth0而非ens33或物理网卡未 UP。解决ip link show ens33确认状态若网卡名动态变化改用udev规则固定名称。现象二curl返回Connection refused但 Pod 日志显示请求未到达。原因multus-cni未正确注入Pod 的k8s.v1.cni.cncf.io/networks-statusannotation 为空。解决检查multusDaemonSet 是否运行kubectl get crd network-attachment-definitions.k8s.cni.cncf.io确认 CRD 存在。现象三LoadBalancer 创建后test-podKube-OVN 自动创建的健康检查 Pod状态为ContainerCreating。原因multus与kube-ovn-cni的 CNI 配置冲突导致test-pod同时尝试加载两个 CNI 插件。解决在test-pod的spec.containers[0].env中添加KUBERNETES_POD_NETWORK_MODE: kube-ovn强制其只用 kube-ovn 网络。4.2 EIP 与 SNAT给 Pod 分配固定公网出口 IPEIPElastic IP是 Kube-OVN 的杀手级功能它允许你为任意 Pod 绑定一个固定的公网 IP且该 IP 的出站流量SNAT和入站流量DNAT均可独立控制。操作流程创建 EIP 资源需先有 ProviderNetwork# 创建 provider network绑定物理网卡 kubectl apply -f - EOF apiVersion: kubeovn.io/v1 kind: ProviderNetwork metadata: name: provider-network spec: defaultInterface: ens33 subnets: - name: provider-subnet cidr: 192.168.1.0/24 gateway: 192.168.1.1 EOF为 Pod 绑定 EIPkubectl annotate pod nginx --overwrite \ ovn.kubernetes.io/eip192.168.1.100 \ ovn.kubernetes.io/snats192.168.1.100验证# 进入 Pod 查看出站 IP kubectl exec -it nginx -- curl ifconfig.me # 应返回 192.168.1.100 # 检查 SNAT 规则是否生成 kubectl get eip # 输出应包含 STATUS: Active4.3 集中式网关让所有出站流量走固定节点适用于安全审计、白名单管控场景。与分布式网关每个节点自己 SNAT不同集中式网关强制所有子网流量经由指定节点如gateway-node出网。配置方法# subnet-central-gw.yaml apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: central-subnet spec: cidr: 10.17.0.0/16 gateway: 10.17.0.1 gatewayNode: gateway-node # 指定网关节点 gatewayType: centralized # 关键设为 centralized natOutgoing: true验证将 Pod 调度到非gateway-node的节点kubectl exec -it pod -- curl ifconfig.me源 IP 应为gateway-node的物理 IP在gateway-node上执行tcpdump -i any port 80应捕获到所有出站 HTTP 流量。4.4 静态 IP 分配告别 IP 冲突比hostPort更彻底的方案直接为 Pod 指定 IP且该 IP 在整个集群内唯一。kubectl annotate pod nginx --overwrite \ ovn.kubernetes.io/ip_address10.16.10.100 \ ovn.kubernetes.io/mac_address00:00:00:11:22:33注意ip_address必须属于目标子网 CIDR且未被其他 Pod 占用。Kube-OVN 会在创建时校验失败则 Pod 保持Pending。4.5 Pod 级 QoS带宽、延迟、丢包三位一体控制Kube-OVN 的 QoS 不是粗粒度的kubernetes.io/egress-bandwidth而是基于 OVSmeter表的 per-pod 精确限速。限速 30Mbps 示例kubectl annotate pod nginx --overwrite \ ovn.kubernetes.io/ingress_rate30 \ ovn.kubernetes.io/egress_rate30验证# 在另一 Pod 中用 iperf3 测试 kubectl run iperf --imagenetworkstatic/iperf3 --restartNever -- \ -c nginx-pod-ip -p 5201 -t 30 -i 1 # 观察带宽是否稳定在 ~30Mbps4.6 流量镜像把容器流量复制到指定网卡用于对接传统 NPMNetwork Performance Monitoring系统如 Zeek、Suricata。启用镜像kubectl annotate pod nginx --overwrite \ ovn.kubernetes.io/mirror-portmirror0 \ ovn.kubernetes.io/mirror-ifaceens33抓包验证# 在 nginx Pod 所在节点执行 tcpdump -i ens33 -w mirror.pcap port 80 # 然后 curl nginx 服务检查 pcap 中是否有重复流量性能提示流量镜像会带来 5%~10% CPU 开销生产环境建议仅对关键 Pod 启用并监控ovs_pinger_cpu_usage_percent指标。4.7 子网管理Namespace 级别的网络策略单元Kube-OVN 的子网是全局资源可跨节点分配 IP。创建子网后只需将 Namespace 绑定即可kubectl label namespace dev ovn.kubernetes.io/subnetdev-subnet新创建的 Pod 将自动从dev-subnet获取 IP并继承其网关类型、ACL、NAT 策略。4.8 多网络插件 IPAM让 macvlan/vlan 也享受 Kube-OVN 的 IP 管理Kube-OVN 可作为“IPAM 中央服务器”为其他 CNI 插件提供地址分配服务。配置 multus 使用 kube-ovn IPAM# multus-conf.yaml片段 ipam: { type: kube-ovn, subnet: multus-subnet, provider: provider-network }避坑点若部署后 Pod 状态为ContainerCreating大概率是multus未正确加载kube-ovnIPAM 插件。检查/opt/cni/bin/是否存在kube-ovn-ipam二进制并确认multusDaemonSet 的args中指定了--cni-bin-dir/opt/cni/bin。5. 避坑指南8 条血泪经验总结的高频翻车现场Kube-OVN 功能强大但因其深度集成 OVS/OVN某些错误表现非常隐蔽。以下是我在多个客户集群中踩过的坑按发生频率排序每条都附带现象 → 原因 → 解决的完整链路。5.1 现象ovs-ovnPod 重启频繁日志循环打印ovn-controller: connection failed原因ovn-central的ovn-sb服务未就绪或ovs-ovn的OVN_SB_ADDR环境变量指向错误地址。常见于ovn-central-etcdStatefulSet 启动慢于ovs-ovnDaemonSet导致ovn-controller连不上ovn-sb。解决检查ovn-central-etcdPod 状态kubectl get pod -n kube-ovn -l appovn-central-etcd若其READY为0/1查看日志kubectl logs -n kube-ovn ovn-central-etcd-0常见原因是磁盘空间不足或etcd数据目录权限错误临时修复删除ovn-central-etcdPod强制重建长期方案在ovs-ovnDaemonSet 中添加initContainer等待ovn-sb服务端口6642可达后再启动主容器。5.2 现象Pod IP 分配成功但无法 ping 通同子网其他 Pod原因kube-ovn-controller与ovn-central通信中断导致ovn-nb中的Logical_Switch_Port记录未同步到ovn-sbovn-controller无法生成对应流表。解决检查kube-ovn-controller日志kubectl logs -n kube-ovn deploy/kube-ovn-controller \| grep failed to sync若出现context deadline exceeded说明ovn-nb连接超时检查ovn-central的ovn-nb容器资源CPU 限制过低会导致响应延迟快速验证kubectl exec -n kube-ovn ovn-central-0 -- ovn-nbctl ls-port-list subnet-name若无输出证明ovn-nb未写入端口。5.3 现象kubectl ko subnet list显示子网STATUS: Pending且AGE持续增长原因子网 CIDR 与现有子网重叠或gatewayIP 不在 CIDR 范围内。Kube-OVN 的子网校验非常严格任何数学错误都会卡住状态机。解决kubectl get subnet subnet-name -o yaml检查spec.cidr和spec.gateway使用 Python 快速验证import ipaddress net ipaddress.ip_network(10.16.0.0/16) gw ipaddress.ip_address(10.16.0.1) print(gw in net) # 必须为 True若 CIDR 错误删除子网并重建切勿 patch 修改 CIDRKube-OVN 不支持子网 CIDR 变更。5.4 现象启用traffic-mirror后节点 CPU 暴涨ovs-vswitchd进程占满 100%原因流量镜像目标网卡如ens33未配置为混杂模式promiscuous mode导致 OVS 内核模块不断丢弃镜像包并重试。解决ip link set ens33 promisc on永久生效echo post-up ip link set ens33 promisc on /etc/network/interfacesDebian或nmcli con mod ens33 802-3-ethernet.accept-all-mac-addresses yesRHEL重要镜像网卡不应承载任何业务流量建议专用一张网卡。5.5 现象kubectl ko pod ip pod返回Error: no IP found但kubectl get pod -o wide显示 IP 正常原因kubectl-ko插件版本与 Kube-OVN 集群版本不匹配。ko插件从kube-ovn-controller的 metrics 端口获取数据若版本不一致API 路径或字段名变更会导致解析失败。解决下载与集群版本一致的kubectl-kocurl -LO https://github.com/kubeovn/kube-ovn/releases/download/v1.11.0/kubectl-ko-linux-amd64 chmod x kubectl-ko-linux-amd64 sudo mv kubectl-ko-linux-amd64 /usr/local/bin/kubectl-ko验证kubectl ko version应与kubectl get po -n kube-ovn -l appkube-ovn-controller -o jsonpath{.items[0].spec.containers[0].image}输出的镜像 tag 一致。5.6 现象kube-ovn-pinger报ovs flow count 100000且ovs-ofctl dump-flows br-int \| wc -l确实超限原因大量 NetworkPolicy 或子网 ACL 导致 OVS 流表膨胀。Kube-OVN 默认不限制流表大小但 OVS 内核模块有硬上限通常 10 万条。解决优化 ACL合并重复规则使用ipBlock替代单个 IP清理无用子网kubectl get subnet \| grep -v default \| xargs -n1 kubectl delete subnet终极方案在ovs-ovnDaemonSet 中增加ovs-vswitchd启动本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
