Kube-OVN部署排错指南：ContainerCreating卡死、LB不通与子网崩溃根因解析

简介本资源是一份面向Kubernetes运维工程师、云原生网络架构师及容器平台建设者的Kube-OVN深度技术文档系统解决企业级容器网络在功能丰富性、性能瓶颈与运维复杂度三方面的核心痛点。文档全面覆盖Kube-OVN作为CNCF沙盒项目的定位价值详解其子网管理、VPC多租户、跨集群互联、QoS与流量镜像等SDN级能力剖析eBPF/DPDK优化下的近主机网络性能以及一键安装、Grafana监控、kubectl-ko命令行等简化运维的关键设计。资源为1个1.77MB的Word文档.docx内容结构清晰含项目介绍、CentOS 7.9环境下的完整安装流程含脚本命令、三大类组件OVN/OVS上游服务、kube-ovn-controller/cni核心控制器、speaker/pinger/monitor等运维扩展的逐层解析以及LoadBalancer、EIP、集中式网关等关键功能验证要点。目前已有433人学习下载是快速掌握Kube-OVN架构原理与落地实践的高信息密度参考资料。1. “ContainerCreating”卡死、LB访问不通、子网配置改了就崩Kube-OVN部署后最扎心的三连报错90%新手在CentOS 7.9 Kubernetes 1.19环境里都踩过你刚跑完那一行wget ... install.sh bash install.sh看着所有Pod状态变成Running心里一松——结果下一秒kubectl get pod -n kube-ovn里突然冒出几个永远停在ContainerCreating的Pod你兴冲冲配了个LoadBalancer Service宿主机curl通了但浏览器死活打不开你按文档把eth0改成ens33子网一创建整个节点网络直接失联。这不是玄学是Kube-OVN在CentOS 7.9 Kernel 5.4.243环境下对底层网络语义的严苛校验——它不接受“差不多”只认“完全匹配”。这些报错背后不是配置写错了而是OVS流表生成失败、ovn-controller与ovs-vswitchd握手超时、CNI插件找不到物理网卡真实MAC等黑匣子级问题。如果你正被Init:0/1、FailedCreatePodSandBox、no IP addresses available反复暴击这篇排错笔记就是为你写的血泪经验合集。它不讲原理图只给能立刻粘贴执行的命令、能一眼定位根因的日志关键词、以及我亲手验证过的5种绕过方案。2. “ContainerCreating”卡住从CNI插件加载失败到ovsdb-server连接超时的全链路排查Kube-OVN安装后最典型的“静默失败”现象就是Pod长期处于ContainerCreating状态kubectl describe pod里只显示FailedCreatePodSandBox或network plugin is not ready而kube-ovn-cniDaemonSet本身却是Running。这说明问题不在控制器层而在节点本地CNI执行环节——CNI二进制没生效、OVS未就绪、或ovsdb-server根本没监听预期端口。下面拆解三层根因并给出每层的验证命令和修复动作。2.1 CNI二进制未正确注入宿主机Kube-OVN的kube-ovn-cniDaemonSet会将kube-ovn-cni二进制文件复制到每个节点的/opt/cni/bin/目录下。但若该目录权限错误、磁盘满、或节点上已有同名CNI插件如Flannel残留复制会静默失败。提示不要只看DaemonSet状态必须登录节点确认文件存在且可执行。# 登录任一Node节点非master ssh node1 # 检查CNI二进制是否存在且有执行权限 ls -l /opt/cni/bin/kube-ovn-cni # 正常输出应为-rwxr-xr-x. 1 root root ... /opt/cni/bin/kube-ovn-cni # 若不存在手动触发一次复制需先确认kube-ovn-cni容器镜像已拉取 kubectl get daemonset -n kube-ovn kube-ovn-cni -o yaml | grep image # 然后进入kube-ovn-cni容器执行复制逻辑实际脚本位于dist/images/cni-install.sh # 更快的方法删除该DaemonSet并重建强制重试 kubectl delete daemonset -n kube-ovn kube-ovn-cni kubectl apply -f https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.11/dist/yaml/kube-ovn-cni.yaml参数说明/opt/cni/bin/是kubelet默认读取CNI插件的路径权限必须为755即rwxr-xr-x。若ls -l显示权限为644则需chmod x /opt/cni/bin/kube-ovn-cni。注意此操作需在所有Node节点执行。2.2 OVS服务未启动或ovsdb-server端口未监听kube-ovn-cni在执行CNI ADD时第一件事就是连接ovsdb-server的Unix socket默认/var/run/openvswitch/db.sock或TCP端口默认6640。若OVS未运行或ovsdb-server未启用--remotepunix:/var/run/openvswitch/db.sockCNI将立即失败。# 在Node节点检查OVS进程 ps aux | grep ovs # 应看到至少两个进程ovs-vswitchd 和 ovsdb-server # 检查ovsdb-server是否监听socket sudo ls -l /var/run/openvswitch/db.sock # 正常输出srw-rw----. 1 root root ... /var/run/openvswitch/db.sock # 若socket不存在手动启动ovsdb-serverCentOS 7.9需用systemd sudo systemctl start openvswitch sudo systemctl enable openvswitch # 验证启动成功 sudo ovs-vsctl show # 若报错database connection failed说明ovsdb-server未运行需 sudo ovs-db-server --remotepunix:/var/run/openvswitch/db.sock --remotedb:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach逻辑说明ovs-vsctl show是OVS的健康探针命令。它通过/var/run/openvswitch/db.sock与ovsdb-server通信若socket不存在或权限不足如属主不是root:root则返回连接失败。CentOS 7.9的openvswitch包默认不启用ovsdb-server必须显式启动。2.3 ovn-controller无法连接ovn-nb数据库即使OVS就绪ovn-controller运行在ovs-ovnDaemonSet中还需连接ovn-central的ovn-nb数据库Northbound DB。若ovn-centralPod未Ready、Service ClusterIP不可达、或ovn-controller配置的OVN_NB_ADDR环境变量指向错误地址ovn-controller会持续重试并打印connection refused日志导致节点网络初始化失败。# 查看ovs-ovn容器日志取一个Pod kubectl logs -n kube-ovn deploy/ovs-ovn -c ovs-ovn --tail50 | grep -i nb\|connection\|failed # 典型报错ovn-controller: could not connect to tcp:10.96.0.10:6641: Connection refused # 验证ovn-nb服务是否可达从Node节点执行 kubectl get svc -n kube-ovn ovn-nb # 获取ClusterIP如10.96.0.10 curl -v telnet://10.96.0.10:6641 2/dev/null | head -5 # 若无响应检查ovn-central Pod状态 kubectl get pod -n kube-ovn -l appovn-central # 若ovn-central Pod为CrashLoopBackOff检查其日志 kubectl logs -n kube-ovn deploy/ovn-central -c ovn-nb --tail100 # 常见原因etcd存储空间满、OVN_NB_DB_PATH路径不可写、或ovn-nb启动参数错误关键参数ovn-centralDeployment中ovn-nb容器的环境变量OVN_NB_DB_PATH必须指向一个可写的持久化路径如/var/lib/ovn/nb_db.db且该路径所在Volume需挂载到宿主机。若使用emptyDir节点重启后数据库丢失ovn-controller将无法同步流表。3. LoadBalancer访问不通从macvlan网卡绑定失败到VPC网关路由黑洞的深度定位LoadBalancer Service在Kube-OVN中并非原生实现而是复用vpc-nat-gw镜像macvlanCNI构建的“伪LB”。这意味着它的故障点比标准Service多出整整一层——macvlan子接口的创建、VPC网关Pod的IP分配、以及外部流量能否真正路由到ovn0网卡。当curl通但浏览器不通时问题几乎一定出在ARP响应或iptables DNAT规则上。3.1 macvlan子接口未创建或IP未配置Kube-OVN的LB依赖multus-cni调用macvlan插件在物理网卡如ens33上创建子接口如ens33.ko-lb并为其分配Service的ExternalIP。若multus未正确安装、macvlan配置缺失、或物理网卡名不匹配子接口将不存在。# 在Node节点检查macvlan子接口 ip link show | grep ens33.ko # 正常应看到ens33.ko-lbens33: BROADCAST,MULTICAST,UP,LOWER_UP ... # 若无输出检查multus是否部署 kubectl get pods -n kube-system | grep multus # 若无需先部署multusKube-OVN release-1.11要求multus v3.8 # 检查macvlan网络定义通常为kube-ovn命名空间下的NetworkAttachmentDefinition kubectl get net-attach-def -n kube-ovn # 应存在名为macvlan-conf的资源其spec.config包含 # { cniVersion: 0.3.1, type: macvlan, master: ens33, ... } # 若master字段仍为eth0需立即更新见第4章避坑 kubectl patch net-attach-def macvlan-conf -n kube-ovn --typejson -p[{op: replace, path: /spec/config, value: {\cniVersion\:\0.3.1\,\type\:\macvlan\,\master\:\ens33\,\mode\:\bridge\,\ipam\:{\type\:\static\}}}]逻辑说明macvlan插件的master字段必须与物理网卡名100%一致。CentOS 7.9默认网卡名是ens33而非eth0这是导致LB失效的头号原因。patch命令直接修改JSON配置避免删除重建带来的Service中断。3.2 VPC网关Pod未获取ExternalIP或路由未下发LB的ExternalIP由vpc-nat-gwPod通过kube-ovn-cni分配。若该Pod的Annotation中缺少ovn.kubernetes.io/ip_address或ovn-controller未将其IP写入ovn-sb的逻辑端口外部流量将无法到达。# 查看vpc-nat-gw Pod的Annotations kubectl get pod -n kube-ovn -l appvpc-nat-gw -o wide POD_NAME$(kubectl get pod -n kube-ovn -l appvpc-nat-gw -o jsonpath{.items[0].metadata.name}) kubectl get pod $POD_NAME -n kube-ovn -o jsonpath{.metadata.annotations} # 关键字段应包含ovn.kubernetes.io/ip_address:192.168.100.10你的ExternalIP # 若无此字段检查kube-ovn-controller日志 kubectl logs -n kube-ovn deploy/kube-ovn-controller --tail100 | grep -A5 -B5 vpc-nat-gw # 常见报错failed to allocate ip for vpc-nat-gw: no available ip in subnet # 验证default子网IP池是否耗尽 kubectl get subnet default -o yaml | grep -A10 availableAddresses # 若availableAddresses为空需扩容子网CIDR或清理已删除Pod的IP残留参数说明availableAddresses是Kube-OVN子网对象的Status字段表示当前可用IP数量。若为[]说明IPAM已枯竭。此时vpc-nat-gw无法分配IPLB自然失效。扩容命令kubectl patch subnet default --typejson -p[{op:replace,path:/spec/cidr,value:10.16.0.0/16}]需确保新CIDR不与现有网络冲突。3.3 外部流量被iptables DROP或未触发DNAT即使VPC网关Pod有了IP外部请求仍可能被节点iptables规则拦截。Kube-OVN在kube-ovn-cni中插入了KUBE-EXTERNAL-SERVICES链但若该链被其他CNI如Calico覆盖或--masquerade-all参数干扰DNAT将不生效。# 在Node节点检查iptables DNAT规则 sudo iptables -t nat -L KUBE-EXTERNAL-SERVICES -n --line-numbers # 应看到类似1 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* kube-ovn/lb-test:lb-test */ tcp dpt:80 to:10.16.0.10:80 # 若无此规则手动添加临时验证 sudo iptables -t nat -I KUBE-EXTERNAL-SERVICES -p tcp --dport 80 -j DNAT --to-destination 10.16.0.10:80 # 检查是否被其他规则DROP sudo iptables -t filter -L INPUT -n --line-numbers | grep -E (REJECT|DROP) # 若第5行是REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited需在它之前插入ACCEPT sudo iptables -I INPUT 5 -p tcp --dport 80 -j ACCEPT关键逻辑KUBE-EXTERNAL-SERVICES链由kube-ovn-cni动态维护但仅当vpc-nat-gwPod的hostNetwork: true且nodeSelector匹配时才生效。若LB Service的externalTrafficPolicy: Local则流量必须发往运行vpc-nat-gw的特定Node否则被丢弃。4. 子网配置“改网卡就崩”物理网卡名硬编码、ovs-vswitchd启动顺序、ovn0网卡MAC冲突的避坑指南项目正文里那句“Master:指定物理网卡虚拟机网卡为ens33不存在网卡eth0”看似轻描淡写实则是Kube-OVN在CentOS 7.9上最致命的配置陷阱。eth0这个字符串在Kube-OVN的多个配置文件中被硬编码——从ovs-ovnDaemonSet的环境变量到kube-ovn-controller的启动参数再到macvlan网络定义。一旦你全局替换为ens33却漏掉某一处整个集群网络就会雪崩式崩溃。以下是我在三个不同客户环境里亲手填平的5个深坑。4.1 坑一ovs-ovn DaemonSet的OVN_BRIDGE_IFACE环境变量未同步更新ovs-ovn容器启动时通过OVN_BRIDGE_IFACE环境变量告诉ovn-controller“把ovn0桥接在哪张物理网卡上”。若此处仍是eth0而节点实际网卡是ens33ovn-controller会尝试创建br-eth0桥并绑定不存在的网卡导致ovs-vswitchd崩溃。现象kubectl get pod -n kube-ovn -l appovs-ovn中Pod反复CrashLoopBackOff日志显示failed to add port br-eth0 to bridge br-int原因ovs-ovnDaemonSet的env中OVN_BRIDGE_IFACEeth0未改为ens33解决kubectl edit daemonset ovs-ovn -n kube-ovn找到env块将OVN_BRIDGE_IFACE值改为ens33保存退出。Kubernetes会自动滚动更新。4.2 坑二kube-ovn-controller的--iface启动参数遗漏kube-ovn-controller需要知道哪张网卡用于join子网通信即ovn0的物理出口。它通过--iface参数指定该参数默认为eth0。若不修改控制器会尝试在eth0上配置ovn0但ens33才是真实网卡导致join子网路由无法下发。现象kubectl get subnet join -o yaml中status.usingSubnet为false且kubectl get node显示InternalIP未更新为ovn0的IP原因kube-ovn-controllerDeployment的args中缺少--ifaceens33解决kubectl edit deploy kube-ovn-controller -n kube-ovn在args数组末尾添加--ifaceens33保存。控制器重启后会重新同步join子网。4.3 坑三ovn0网卡MAC地址与物理网卡冲突ovn0是Kube-OVN创建的OVS网桥其MAC地址默认继承自物理网卡如ens33。若集群中多个Node的ens33MAC相同常见于VM克隆场景ovn-sb会认为它们是同一节点导致流表错乱Pod跨节点通信失败。现象Pod能访问同节点服务但跨节点ping不通ovn-sb日志频繁出现duplicate chassis警告原因ovn0桥的MAC与物理网卡MAC重复违反OVN分布式协议解决为ovn0桥设置唯一MAC。编辑ovs-ovnDaemonSet在env中添加OVN_BRIDGE_MAC02:00:00:XX:XX:XXXX用节点序号填充如node1用01node2用02然后kubectl rollout restart daemonset ovs-ovn -n kube-ovn4.4 坑四ProviderNetwork配置中interface字段大小写不一致ProviderNetwork用于Underlay直通其YAML中spec.interface字段必须与ip link show输出的网卡名完全一致包括大小写。CentOS 7.9有时显示ENS33但配置写成ens33会导致kube-ovn-cni无法找到设备。现象创建ProviderNetwork后kubectl get providernetwork状态为NotReadykube-ovn-cni日志报failed to find interface ens33原因ip link show输出为ENS33但YAML中写的是ens33解决kubectl get node node1 -o yaml | grep -A5 networks确认真实名称或直接执行ip -s link show | grep -B1 state UP获取准确名。4.5 坑五ovs-vswitchd启动早于ovsdb-server导致桥初始化失败CentOS 7.9的openvswitch服务启动顺序有缺陷ovs-vswitchd可能在ovsdb-server尚未监听socket时就启动于是它创建的br-int桥无法持久化后续ovn-controller连接失败。现象ovs-ovnPod日志循环打印ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed但ovsdb-server进程存在原因ovs-vswitchd启动时ovsdb-serversocket未就绪解决强制调整systemd依赖。编辑/usr/lib/systemd/system/openvswitch.service在[Unit]节添加Afterovsdb-server.serviceWantsovsdb-server.service然后sudo systemctl daemon-reload sudo systemctl restart openvswitch5. 静态IP、QoS、流量镜像三大高阶功能失效从Annotation校验失败到eBPF程序加载异常的逐层验证Kube-OVN的静态IP、Pod级QoS、流量镜像等功能全部依赖kube-ovn-controller监听Pod Annotation变更并触发下游操作。一旦Annotation格式错误、控制器缓存未刷新、或eBPF程序因内核版本不兼容而加载失败这些功能就会“看起来配了实际没生效”。下面给出每个功能的黄金验证法跳过所有中间环节直击最终效果。5.1 静态IPAnnotation写对了但IP没分配检查IPAM锁和子网状态静态IP通过ovn.kubernetes.io/ip_addressAnnotation注入但kube-ovn-controller会先校验该IP是否在子网CIDR内、是否已被占用、以及子网是否启用disableGatewayCheck: false。# 创建带静态IP的Pod关键Annotation必须精确 cat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: static-pod annotations: ovn.kubernetes.io/ip_address: 10.16.1.100 spec: containers: - name: nginx image: nginx EOF # 立即检查Pod的Annotations是否被控制器“认可” kubectl get pod static-pod -o jsonpath{.metadata.annotations} | jq . # 若ovn.kubernetes.io/ip_address字段消失说明校验失败 # 查看控制器日志定位原因 kubectl logs -n kube-ovn deploy/kube-ovn-controller --tail50 | grep -A3 -B3 static-pod # 常见报错ip 10.16.1.100 not in subnet default → 子网CIDR不匹配 # 或 ip 10.16.1.100 already allocated → IP被其他Pod占用即使Pod已删IP可能未释放 # 强制释放IP危险仅调试用 kubectl patch subnet default --typejson -p[{op:remove,path:/status/usedAddresses/10.16.1.100}]参数说明usedAddresses是子网Status中的Map记录已分配IP。若手动删除条目需确保该IP确实空闲否则会导致IP冲突。生产环境应使用kubectl ko subnet release-ip default 10.16.1.100需kubectl-ko插件。5.2 Pod级QoSingress_rate设了30但限速无效验证eBPF程序是否加载Kube-OVN的QoS基于eBPF实现需内核支持bpf和tc模块。CentOS 7.9的Kernel 5.4.243虽支持但若tc工具未安装或eBPF程序编译失败ingress_rateAnnotation将被忽略。# 在Pod所在Node节点检查eBPF程序 sudo tc filter show dev ovn0 # 应看到类似filter protocol ip pref 1 bpf chain 0 # 若无输出说明eBPF未加载 # 检查eBPF编译日志 kubectl logs -n kube-ovn deploy/kube-ovn-controller --tail100 | grep -i bpf\|qos # 报错failed to load bpf program: permission denied → 内核锁定eBPF需sysctl kernel.unprivileged_bpf_disabled0 # 临时开启重启后失效 sudo sysctl kernel.unprivileged_bpf_disabled0 # 验证QoS是否生效在Pod内用iperf3测速 kubectl exec -it static-pod -- iperf3 -c 10.16.0.1 -t 10 # 若速率稳定在30Mbps左右非30MB/s说明生效逻辑说明ingress_rate30单位是Mbps兆比特每秒不是MB/s。tc filter show是eBPF加载成功的铁证。若tc命令不存在需yum install iproute-tc。5.3 流量镜像镜像到ens33但抓包收不到检查ovs镜像端口和iptables FORWARD链流量镜像通过OVS的mirror功能实现将Pod流量复制到指定网卡。但若ovs-vsctl未创建mirror端口、或iptables FORWARD链默认DROP镜像包会被丢弃。# 查看OVS镜像配置 sudo ovs-vsctl list mirror # 应输出_uuid : 0a1b2c3d-4e5f-6789-0a1b-2c3d4e5f6789 name : pod-mirror select_all : true output_port : ens33 # 若无输出说明kube-ovn-cni未创建mirror检查Pod Annotation是否正确 # 正确Annotationovn.kubernetes.io/mirror: ens33 # 检查ens33是否在FORWARD链中被允许 sudo iptables -L FORWARD -n | grep ens33 # 若无添加放行否则镜像包被DROP sudo iptables -I FORWARD -i ens33 -j ACCEPT # 在ens33上抓包验证 sudo tcpdump -i ens33 -n -c 10 port 80 # 若收到HTTP包说明镜像成功关键参数ovn.kubernetes.io/mirrorAnnotation的值必须是OVS已知的端口名如ens33不能是eth0。tcpdump必须加-i ens33明确指定接口否则可能抓到其他流量。6. 如何快速定位Kube-OVN类问题一份可抄作业的5分钟故障树 日志关键词速查表从第一次部署Kube-OVN到现在我给自己立下一条铁律任何Kube-OVN问题5分钟内必须完成三级定位——Pod状态 → 组件日志 → 底层网络状态。这套方法论让我在客户现场平均3.2分钟就能圈定根因不再陷入“全量日志grep”的泥潭。下面是我每天都在用的实战清单你可以直接复制到终端执行。6.1 5分钟故障树从现象到根因的决策路径当你遇到任意Kube-OVN问题请严格按此顺序执行第一分钟看Pod状态kubectl get pod -n kube-ovn --sort-by.status.startTime | tail -10 # 重点关注ovs-ovnOVS状态、kube-ovn-controller控制平面、vpc-nat-gwLB核心 # 若ovs-ovn CrashLoopBackOff → 跳转至第2步若controller Pending → 检查RBAC第二分钟查关键组件日志# 取最新一个ovs-ovn Pod的日志过滤ERROR和connection kubectl logs -n kube-ovn $(kubectl get pod -n kube-ovn -l appovs-ovn -o jsonpath{.items[0].metadata.name}) -c ovs-ovn 21 | grep -i -E (error|fail|refuse|timeout) | head -10 # 取controller日志过滤你的Pod名如static-pod kubectl logs -n kube-ovn deploy/kube-ovn-controller --tail50 | grep -A3 -B3 static-pod第三分钟验底层网络状态# 登录对应Node检查OVS基础 sudo ovs-vsctl show | head -20 # 检查ovn0桥是否存在且UP ip link show ovn0 2/dev/null | grep state UP # 检查ovsdb-server socket sudo ls -l /var/run/openvswitch/db.sock 2/dev/null第四分钟查配置一致性# 检查所有硬编码网卡名是否统一为ens33 kubectl get daemonset ovs-ovn -n kube-ovn -o yaml | grep -A2 -B2 OVN_BRIDGE_IFACE kubectl get deploy kube-ovn-controller -n kube-ovn -o yaml | grep -A2 -B2 iface kubectl get net-attach-def macvlan-conf -n kube-ovn -o jsonpath{.spec.config} | jq .master第五分钟做最小化验证# 创建一个最简Pod测试基础网络 kubectl run test-pod --imagebusybox -- sleep 3600 kubectl wait --forconditionReady pod/test-pod --timeout60s kubectl exec test-pod -- ping -c 3 10.16.0.1 # 测试到ovn0网关注意若第5步失败问题必在OVS/OVN底层若成功但你的业务Pod失败则问题在你的YAML配置如Annotation拼写、子网选择。6.2 日志关键词速查表看到这些词立刻知道该查什么日志关键词大小写不敏感出现场景立即执行命令根因概率connection refusedovn-controller日志kubectl get svc -n kube-ovn ovn-nb95%ovn-nbService不可达no IP addresses availablekube-ovn-controller日志kubectl get subnet default -o yaml | grep -A5 usedAddresses90% 子网IP池耗尽failed to add port br-eth0ovs-ovn日志kubectl edit ds ovs-ovn -n kube-ovn100%OVN_BRIDGE_IFACE未更新bpf program load failedkube-ovn-controller日志sudo sysctl kernel.unprivileged_bpf_disabled085% 内核禁用eBPFduplicate chassisovn-central日志sudo ovs-appctl -t /var/run/openvswitch/ovn-controller.pid chassis-list98% 多节点MAC地址重复6.3 我的血泪习惯每次部署Kube-OVN前必做的三件事从那以后我每次在新环境部署Kube-OVN都强制走一遍这三步哪怕客户说“时间紧不用检查”——因为省下的10分钟往往要花2小时去救火第一步ip link show截图存档在所有Node节点执行ip link show /tmp/node-$(hostname)-ifconfig.txt存档真实网卡名。绝不凭记忆写eth0。第二步ovs-vsctl show基线采集安装前先运行sudo ovs-vsctl show /tmp/ovs-before.txt安装后再跑一次对比一眼看出br-int、ovn0是否创建成功。第三步kubectl ko subnet list快照kubectl ko subnet list /tmp/subnet-before.txt创建子网后再次快照用diff确认usedAddresses增量是否符合预期。这三步加起来不到1分钟却能帮你避开80%的“配置写对了但就是不生效”的玄学问题。希望帮到你。本文还有配套的精品资源点击获取