简介：本资源是一份面向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未启用--remote=punix:/var/run/openvswitch/db.sock，CNI将立即失败。

# 在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-server（CentOS 7.9需用systemd） sudo systemctl start openvswitch sudo systemctl enable openvswitch # 验证启动成功 sudo ovs-vsctl show # 若报错"database connection failed"，说明ovsdb-server未运行，需： sudo ovs-db-server --remote=punix:/var/run/openvswitch/db.sock --remote=db: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 --tail=50 | 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 app=ovn-central # 若ovn-central Pod为CrashLoopBackOff，检查其日志 kubectl logs -n kube-ovn deploy/ovn-central -c ovn-nb --tail=100 # 常见原因：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-lb@ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> ... # 若无输出，检查multus是否部署 kubectl get pods -n kube-system | grep multus # 若无，需先部署multus（Kube-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 --type='json' -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 app=vpc-nat-gw -o wide POD_NAME=$(kubectl get pod -n kube-ovn -l app=vpc-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 --tail=100 | 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无法分配IP，LB自然失效。扩容命令：kubectl patch subnet default --type='json' -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，而节点实际网卡是ens33，ovn-controller会尝试创建br-eth0桥并绑定不存在的网卡，导致ovs-vswitchd崩溃。

现象：kubectl get pod -n kube-ovn -l app=ovs-ovn中Pod反复CrashLoopBackOff，日志显示failed to add port br-eth0 to bridge br-int
原因：ovs-ovnDaemonSet的env中OVN_BRIDGE_IFACE=eth0未改为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中缺少--iface=ens33
解决：kubectl edit deploy kube-ovn-controller -n kube-ovn，在args数组末尾添加--iface=ens33，保存。控制器重启后会重新同步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_MAC="02:00:00:XX:XX:XX"（XX用节点序号填充，如node1用01，node2用02）
然后kubectl rollout restart daemonset ovs-ovn -n kube-ovn

4.4 坑四：ProviderNetwork配置中interface字段大小写不一致

ProviderNetwork用于Underlay直通，其YAML中spec.interface字段必须与ip link show输出的网卡名完全一致（包括大小写）。CentOS 7.9有时显示ENS33，但配置写成ens33会导致kube-ovn-cni无法找到设备。

现象：创建ProviderNetwork后，kubectl get providernetwork状态为NotReady，kube-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]节添加：
After=ovsdb-server.service
Wants=ovsdb-server.service
然后sudo systemctl daemon-reload && sudo systemctl restart openvswitch

5. 静态IP、QoS、流量镜像三大高阶功能失效：从Annotation校验失败到eBPF程序加载异常的逐层验证

Kube-OVN的静态IP、Pod级QoS、流量镜像等功能，全部依赖kube-ovn-controller监听Pod Annotation变更并触发下游操作。一旦Annotation格式错误、控制器缓存未刷新、或eBPF程序因内核版本不兼容而加载失败，这些功能就会“看起来配了，实际没生效”。下面给出每个功能的黄金验证法，跳过所有中间环节，直击最终效果。

5.1 静态IP：Annotation写对了，但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 --tail=50 | 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 --type='json' -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级QoS：ingress_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 --tail=100 | grep -i "bpf\|qos" # 报错"failed to load bpf program: permission denied" → 内核锁定eBPF（需`sysctl kernel.unprivileged_bpf_disabled=0`） # 临时开启（重启后失效） sudo sysctl kernel.unprivileged_bpf_disabled=0 # 验证QoS是否生效：在Pod内用iperf3测速 kubectl exec -it static-pod -- iperf3 -c 10.16.0.1 -t 10 # 若速率稳定在30Mbps左右（非30MB/s），说明生效

逻辑说明：ingress_rate=30单位是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是否正确） # 正确Annotation：ovn.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问题，请严格按此顺序执行：

1. 第一分钟：看Pod状态

   kubectl get pod -n kube-ovn --sort-by=.status.startTime | tail -10 # 重点关注：ovs-ovn（OVS状态）、kube-ovn-controller（控制平面）、vpc-nat-gw（LB核心） # 若ovs-ovn CrashLoopBackOff → 跳转至第2步；若controller Pending → 检查RBAC

2. 第二分钟：查关键组件日志

   # 取最新一个ovs-ovn Pod的日志，过滤ERROR和connection kubectl logs -n kube-ovn $(kubectl get pod -n kube-ovn -l app=ovs-ovn -o jsonpath='{.items[0].metadata.name}') -c ovs-ovn 2>&1 | grep -i -E "(error|fail|refuse|timeout)" | head -10 # 取controller日志，过滤你的Pod名（如static-pod） kubectl logs -n kube-ovn deploy/kube-ovn-controller --tail=50 | grep -A3 -B3 "static-pod"

3. 第三分钟：验底层网络状态

   # 登录对应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

4. 第四分钟：查配置一致性

   # 检查所有硬编码网卡名是否统一为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'

5. 第五分钟：做最小化验证

   # 创建一个最简Pod，测试基础网络 kubectl run test-pod --image=busybox -- sleep 3600 kubectl wait --for=condition=Ready pod/test-pod --timeout=60s kubectl exec test-pod -- ping -c 3 10.16.0.1 # 测试到ovn0网关

注意：若第5步失败，问题必在OVS/OVN底层；若成功但你的业务Pod失败，则问题在你的YAML配置（如Annotation拼写、子网选择）。

6.2 日志关键词速查表：看到这些词，立刻知道该查什么

6.3 我的血泪习惯：每次部署Kube-OVN前必做的三件事

从那以后我每次在新环境部署Kube-OVN，都强制走一遍这三步，哪怕客户说“时间紧不用检查”——因为省下的10分钟，往往要花2小时去救火：

1. 第一步：ip link show截图存档
   在所有Node节点执行ip link show > /tmp/node-$(hostname)-ifconfig.txt，存档真实网卡名。绝不凭记忆写eth0。

2. 第二步：ovs-vsctl show基线采集
   安装前先运行sudo ovs-vsctl show > /tmp/ovs-before.txt，安装后再跑一次对比，一眼看出br-int、ovn0是否创建成功。

3. 第三步：kubectl ko subnet list快照
   kubectl ko subnet list > /tmp/subnet-before.txt，创建子网后再次快照，用diff确认usedAddresses增量是否符合预期。

这三步加起来不到1分钟，却能帮你避开80%的“配置写对了但就是不生效”的玄学问题。希望帮到你。

本文还有配套的精品资源，点击获取