简介本资源是一份面向Kubernetes运维工程师、云原生网络架构师及容器平台开发者的Kube-OVN深度技术文档系统解析这一CNCF沙盒项目的网络设计哲学与工程实践。文档覆盖其三大核心优势依托OVN/OVS实现的子网管理、VPC多租户、跨集群互联等丰富SDN功能通过eBPF/DPDK/SmartNIC优化达成的近主机网络级性能以及一键安装脚本、Grafana监控看板、kubectl-ko命令行工具等带来的极简运维体验。资源为1个1.77MB的Word文档.docx完整展开组件架构ovn-central/kube-ovn-controller/kube-ovn-cni等、安装环境要求K8s 1.19CentOS 7.9、各模块职责与交互逻辑并附功能验证清单LoadBalancer/EIP/SNAT/静态IP/Pod级QoS。目前已有433人学习下载是理解Kube-OVN控制面与数据面协同机制、落地生产级容器网络的高价值参考材料。1. Kube-OVN 安装不是“一键就完事”而是“版本锁死内核适配网卡认亲”的三重校验你刚在 Centos7.9 上跑通了 Kubernetes 1.19Docker 19.03 也稳如老狗正准备用wget https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.11/dist/images/install.sh bash install.sh一键拉起 Kube-OVN——结果kube-ovn-cni在节点上卡在ContainerCreatingovs-vswitchd日志疯狂刷failed to open datapath: No such file or directorykubectl ko get subnet返回空连默认子网都看不见。这不是脚本坏了是你没过 Kube-OVN 的「准入三问」你的 kernel 真的能 loadopenvswitch模块吗你的物理网卡名真是eth0吗你装的 release-1.11 真和 k8s 1.19 的 API 兼容吗Kube-OVN 不是普通 CNI它是 OVN/OVS 这套 SDN 黑匣子和 Kubernetes 控制面的硬耦合体版本错一位、内核缺一个 symbol、网卡名写错一个字母整个网络平面就直接静音。它适合谁适合那些已经踩过 Flannel 性能瓶颈、Cilium eBPF 调试黑洞、Calico BGP 配置迷宫的中大型集群运维也适合需要子网隔离、静态 IP、集中式网关审计、流量镜像对接 NPM 的金融/政企场景。别把它当玩具装它是一套带状态的网络操作系统——装之前先校准环境比敲回车重要十倍。2. 环境准备CentOS 7.9 Kernel 5.4.243 的硬性通关清单Kube-OVN 对底层依赖极其苛刻尤其在 CentOS 7.9 这类长期支持但内核陈旧的系统上。release-1.11 明确要求 kernel ≥ 5.4而官方 CentOS 7 默认 kernel 是 3.10.x必须手动升级。这不是可选项是启动ovs-vswitchd的前提。下面列出所有不可跳过的前置动作每一步失败都会导致后续组件静默崩溃。2.1 升级内核至 5.4.243-1.el7.elrepo.x86_64强制CentOS 7.9 自带 kernel 无法加载openvswitch内核模块ovs_kmodovs-ovnDaemonSet 会因modprobe: FATAL: Module openvswitch not found直接 CrashLoopBackOff。必须使用 ELRepo 仓库安装匹配的高版本内核# 启用 ELRepo 仓库 sudo rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-4.el7.elrepo.noarch.rpm # 安装指定 kernel 版本注意必须与项目正文完全一致 sudo yum --enablerepoelrepo-kernel install kernel-ml-5.4.243-1.el7.elrepo.x86_64 # 查看已安装内核确认 5.4.243 存在 sudo awk -F\ $1menuentry {print $2} /etc/grub2.cfg # 输出应包含CentOS Linux (5.4.243-1.el7.elrepo.x86_64) 7 (Core) # 设置新内核为默认启动项关键否则重启后还是 3.10 sudo grub2-set-default CentOS Linux (5.4.243-1.el7.elrepo.x86_64) 7 (Core) # 生成新 grub 配置 sudo grub2-mkconfig -o /boot/grub2/grub.cfg # 重启并验证 sudo reboot # 重启后执行 uname -r # 必须输出5.4.243-1.el7.elrepo.x86_64提示grub2-set-default后必须执行grub2-mkconfig否则配置不生效。很多翻车案例都是因为只改了 default 但没刷新 grub.cfg导致重启后 kernel 版本未变ovs-vswitchd仍报错。2.2 加载并固化 openvswitch 内核模块Kernel 5.4.243 提供了openvswitch模块但默认不自动加载。ovs-ovnPod 启动时会调用modprobe openvswitch若失败则立即退出# 手动加载测试 sudo modprobe openvswitch # 若无报错说明模块可用 # 将模块加入开机自动加载列表 echo openvswitch | sudo tee -a /etc/modules-load.d/openvswitch.conf # 验证是否已加载 lsmod | grep openvswitch # 应输出类似openvswitch 180224 0 # nf_nat 16384 2 openvswitch,nf_nat_ipv4 # nf_conntrack 131072 5 nf_nat,xt_conntrack,nf_nat_ipv4,openvswitch,nf_conntrack_ipv4注意lsmod输出中openvswitch后面的数字是模块大小字节0表示无其他模块依赖它正常。若显示nf_conntrack或nf_nat依赖数为0说明这些基础模块未加载需额外执行sudo modprobe nf_conntrack和sudo modprobe nf_nat并加入/etc/modules-load.d/。2.3 确认物理网卡名并预设 sysctl 参数Kube-OVN 安装脚本默认读取eth0作为物理网卡Provider Network但虚拟机中常见网卡名为ens33、enp0s3等。若不提前修正kube-ovn-cni初始化时会因找不到eth0而卡住Pod 一直ContainerCreating。同时OVS 高性能运行依赖特定内核参数# 1. 查看真实网卡名以 ens33 为例 ip -br a | awk {print $1} # 2. 创建 kube-ovn 专用 sysctl 配置文件 sudo tee /etc/sysctl.d/99-kube-ovn.conf EOF # 必须开启 IP 转发分布式/集中式网关依赖 net.ipv4.ip_forward 1 # 关闭 rp_filter避免 OVS 流表被反向路径过滤丢弃 net.ipv4.conf.all.rp_filter 0 net.ipv4.conf.default.rp_filter 0 # 提升连接跟踪数应对大规模 Pod net.netfilter.nf_conntrack_max 1000000 # 减少 TIME_WAIT 占用LB 场景高频 net.ipv4.tcp_fin_timeout 30 net.ipv4.tcp_tw_reuse 1 EOF # 3. 立即应用并持久化 sudo sysctl --system # 4. 验证关键参数 sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter # 输出应为net.ipv4.ip_forward 1net.ipv4.conf.all.rp_filter 0提示rp_filter0是 Kube-OVN 的硬性要求。OVN 的逻辑流表会主动修改数据包源/目的地址如 SNAT、DNAT若开启反向路径检查rp_filter1内核会因“回包路径不匹配”直接丢弃导致所有跨子网通信失败且无明确日志提示属于典型玄学故障。3. 安装部署从 release-1.11 脚本到生产就绪的七步落地Kube-OVN 的install.sh是个高度定制化的部署器它不只拉镜像还生成 ConfigMap、ServiceAccount、RBAC并注入物理网卡名、MTU、子网 CIDR 等关键参数。直接执行原始脚本大概率失败必须先做参数预检和本地化改造。3.1 下载并离线校验 install.sh 脚本不要直接wget bash先下载、检查、再执行。release-1.11 的脚本存在硬编码eth0和默认10.16.0.0/16子网需提前替换# 下载脚本到本地 wget https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.11/dist/images/install.sh -O kube-ovn-install.sh # 查看脚本关键变量搜索 PHYSICAL_INTERFACE、POD_CIDR grep -n PHYSICAL_INTERFACE\|POD_CIDR\|JOIN_SUBNET kube-ovn-install.sh # 典型输出 # 45:PHYSICAL_INTERFACE${PHYSICAL_INTERFACE:-eth0} # 48:POD_CIDR${POD_CIDR:-10.16.0.0/16} # 51:JOIN_SUBNET${JOIN_SUBNET:-100.64.0.0/16} # 使用 sed 替换为你的实际值假设物理网卡是 ens33Pod 网段想用 172.16.0.0/16 sed -i s/eth0/ens33/g; s/10.16.0.0\/16/172.16.0.0\/16/g; s/100.64.0.0\/16/169.254.0.0\/16/g kube-ovn-install.sh # 再次确认替换成功 grep -E (PHYSICAL_INTERFACE|POD_CIDR|JOIN_SUBNET) kube-ovn-install.sh # 应输出PHYSICAL_INTERFACE${PHYSICAL_INTERFACE:-ens33} 等注意JOIN_SUBNET是 Kube-OVN 内部用于 Node-Pod 通信的固定子网不能与POD_CIDR冲突。169.254.0.0/16是 IANA 保留的 link-local 网段专为此设计强烈建议保持此值不要随意改成10.0.0.0/16等常用网段否则可能与宿主机路由冲突。3.2 执行安装并监控核心组件状态执行前确保kubectl已配置且能访问集群docker正常运行# 赋予执行权限并运行加 -x 查看详细执行过程便于排错 chmod x kube-ovn-install.sh bash -x ./kube-ovn-install.sh # 安装完成后立即检查命名空间和核心 Pod 状态 kubectl get ns kube-ovn kubectl get pod -n kube-ovn -o wide预期健康状态所有 PodSTATUSRunningREADY1/1NAMEREADYSTATUSRESTARTSAGEIPNODEkube-ovn-cni-xxxxx1/1Running02m192.168.56.11node1kube-ovn-controller-xxxxxxxxxx-xxxxx1/1Running02m192.168.56.11node1ovn-central-xxxxxxxxxx-xxxxx1/1Running02m192.168.56.11node1ovs-ovn-xxxxx1/1Running02m192.168.56.11node1提示若ovs-ovnPod 处于CrashLoopBackOff第一反应不是重装而是查kubectl logs -n kube-ovn ovs-ovn-pod-name。90% 的原因是modprobe openvswitch失败或PHYSICAL_INTERFACE名错误。日志里会明确打印Failed to initialize ovsdb-server: ... no such device。3.3 验证 CNI 插件是否正确注入到节点kube-ovn-cni的核心任务是将二进制文件复制到每个节点的/opt/cni/bin/并确保kubelet能调用它。检查任一工作节点# 登录到 worker 节点如 node1 ssh node1 # 检查 CNI 二进制是否存在且可执行 ls -l /opt/cni/bin/kube-ovn* # 应输出-rwxr-xr-x 1 root root ... /opt/cni/bin/kube-ovn # 检查 CNI 配置文件 cat /etc/cni/net.d/01-kube-ovn.conflist # 关键字段应包含 # name: kube-ovn, # cniVersion: 0.3.1, # plugins: [ { type: kube-ovn }, { type: portmap } ] # 检查 kubelet 是否使用此配置查看 kubelet 启动参数 ps aux | grep kubelet | grep cni # 应包含--cni-bin-dir/opt/cni/bin --cni-conf-dir/etc/cni/net.d注意01-kube-ovn.conflist是 multi-plugin 配置它调用kube-ovn插件完成 IP 分配和 OVS 配置再调用portmap插件处理 HostPort。若portmap缺失hostNetwork: true的 Pod 可能无法映射端口。4. 常见问题排查五个血泪经验总结的“必现坑”安装 Kube-OVN 最痛苦的不是不会装而是装完了不知道哪里坏了。下面五条是我在三个不同客户集群里反复踩出的坑按现象、原因、解决三步给出可立即执行的命令。4.1 现象kubectl ko get subnet返回空default子网不存在原因kube-ovn-controller启动失败未能创建默认子网。常见于ovn-nb数据库连接超时或 RBAC 权限不足。排查# 查看 controller 日志 kubectl logs -n kube-ovn deploy/kube-ovn-controller | tail -20 # 若出现 failed to list *v1.Subnet: Unauthorized说明 RBAC 问题 # 若出现 failed to connect to ovn-nb: connection refused说明 ovn-central 未就绪解决# 1. 确保 ovn-central Pod Running kubectl get pod -n kube-ovn -l appovn-central # 2. 检查 ovn-central Service 是否存在且 ClusterIP 可达 kubectl get svc -n kube-ovn ovn-nb kubectl get endpoints -n kube-ovn ovn-nb # 3. 若 endpoints 为空重启 ovn-central kubectl rollout restart deploy -n kube-ovn ovn-central4.2 现象Pod 一直处于ContainerCreatingkubectl describe pod显示FailedCreatePodSandBox原因kube-ovn-cni未正确注入或 CNI 配置错误kubelet调用 CNI 时超时。排查# 查看 kubelet 日志在对应 node 上执行 journalctl -u kubelet -n 100 --no-pager | grep -i cni\|ovn # 典型错误networkPlugin cni failed to set up pod ... failed to find plugin \kube-ovn\解决# 1. 确认 /opt/cni/bin/kube-ovn 存在且有执行权限见 3.3 节 # 2. 检查 /etc/cni/net.d/ 下是否有 01-kube-ovn.conflist非 .conf # 3. 若有多个 conflist重命名其他文件如 10-flannel.conflist → 10-flannel.conflist.bak # 4. 重启 kubelet 强制重载 CNI sudo systemctl restart kubelet4.3 现象ovs-vsctl show无输出ovs-vswitchd进程不存在原因ovs-ovnDaemonSet 中的容器启动时openvswitch内核模块未加载或ovsdb-server数据库初始化失败。排查# 查看 ovs-ovn Pod 日志 kubectl logs -n kube-ovn ds/ovs-ovn # 若出现 ovsdb-server: unix:/var/run/ovs/db.sock: failed to connect说明数据库未启动 # 若出现 modprobe: ERROR: could not insert openvswitch说明内核模块问题解决# 1. 在节点上手动加载模块见 2.2 节 sudo modprobe openvswitch # 2. 检查 /var/run/openvswitch/ 目录权限ovs-ovn 容器需写入 sudo chown -R root:root /var/run/openvswitch/ sudo chmod -R 755 /var/run/openvswitch/ # 3. 删除 ovs-ovn Pod 强制重建 kubectl delete pod -n kube-ovn -l appovs-ovn4.4 现象LoadBalancer Service 创建后外部无法访问test-pod状态为containerCreating原因multus-cni未安装或macvlanCNI 配置缺失导致 LB 依赖的多网卡功能不可用。排查# 检查 multus 是否安装 kubectl get crd network-attachment-definitions.k8s.cni.cncf.io # 检查 macvlan 配置文件是否存在 ls /etc/cni/net.d/*macvlan*解决# 1. 安装 multus使用官方 manifest kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset-thick.yml # 2. 创建 macvlan 配置假设物理网卡 ens33 cat EOF | kubectl apply -f -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 } } EOF### 4.5 现象子网配置中 physicalInterface: ens33 生效但 Pod 网络不通ping 跨节点 Pod 失败 - **原因**物理网卡 ens33 未配置 IP 或处于 DOWN 状态OVS 无法绑定。 - **排查** bash # 在节点上检查网卡状态 ip link show ens33 # 若 state DOWN则需启用 sudo ip link set ens33 up # 若无 IP需配置仅用于管理不影响 OVS 流量 sudo ip addr add 192.168.56.11/24 dev ens33解决# 确保网卡 UP 且有链路层地址MAC sudo ip link set ens33 up # 检查 OVS 是否已创建 bridge 并 attach ovs-vsctl show | grep -A5 Bridge \br-int\ # 应看到 Port ens33 类似行5. 功能验证用 8 个最小化命令覆盖全部核心能力装完只是开始验证才是交付。下面 8 个命令每个都对应一个 Kube-OVN 的招牌功能全部通过才算真正跑通。它们不依赖 Grafana 或复杂 YAML全是kubectlcurlping的组合拳新手也能秒懂。5.1 验证默认子网与 Pod IP 分配基础连通性这是所有功能的地基。创建一个 Pod检查它是否从default子网获得 IP并能 ping 通同子网其他 Pod# 1. 创建测试 Pod kubectl run nginx-test --imagenginx:alpine -n default # 2. 获取其 IP 和所在节点 NGINX_POD$(kubectl get pod nginx-test -o jsonpath{.metadata.name}) NGINX_IP$(kubectl get pod nginx-test -o jsonpath{.status.podIP}) NODE_NAME$(kubectl get pod nginx-test -o jsonpath{.spec.nodeName}) # 3. 创建第二个 Pod 并 ping 第一个验证同子网互通 kubectl run busybox-test --imagebusybox:1.35 --rm -it --restartNever -- sh -c ping -c 3 $NGINX_IP # 4. 验证子网信息 kubectl ko get subnet default # 输出应包含CIDR: 172.16.0.0/16, Gateway: 172.16.0.1, UsedIPs: 2技巧kubectl ko get subnet是 Kube-OVN 专属命令比kubectl get subnet更直观。若此处UsedIPs为 0说明 Pod 未真正接入 Kube-ovn 网络回到第 4 节排查 CNI。5.2 验证静态 IP 分配精准控制Kube-OVN 允许为 Pod 指定固定 IP避免服务发现混乱。通过 annotation 实现无需改 Deployment# 删除之前的 nginx-test kubectl delete pod nginx-test # 重新创建并指定静态 IP kubectl run nginx-static --imagenginx:alpine \ --overrides{spec:{template:{metadata:{annotations:{ovn.kubernetes.io/ip_address:172.16.10.100}}}}} \ -n default # 验证 IP 是否为指定值 kubectl get pod nginx-static -o jsonpath{.status.podIP} # 应输出172.16.10.100 # 检查该 IP 是否被子网标记为已分配 kubectl ko get subnet default -o yaml | grep 172.16.10.100 # 应在 usedIPs 列表中出现注意静态 IP 必须在子网 CIDR 范围内且不能是网关如172.16.0.1或网络/广播地址。ovn.kubernetes.io/ip_address是唯一有效 annotation拼写错误会导致忽略。5.3 验证集中式网关安全审计刚需让所有 Pod 出外网流量走固定节点的 IP满足白名单和审计要求。需先创建一个集中式子网# 1. 创建集中式子网指定 gatewayNode 为 master1 cat EOF | kubectl apply -f - apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: centralized-subnet spec: cidr: 172.16.20.0/24 gateway: 172.16.20.1 gatewayNode: master1 gatewayType: centralized natOutgoing: true EOF # 2. 创建 Pod 并指定该子网 kubectl run nginx-central --imagenginx:alpine \ --overrides{spec:{template:{metadata:{annotations:{ovn.kubernetes.io/subnet:centralized-subnet}}}}} \ -n default # 3. 在 master1 节点上抓包确认所有出向流量源 IP 为 master1 的管理 IP # 登录 master1执行 sudo tcpdump -i ens33 -n src host 172.16.20.2 -c 5 # 应看到数据包源 IP 是 master1 的 ens33 IP如 192.168.56.10而非 Pod IP提示gatewayNode必须是集群中真实存在的节点名kubectl get node输出且该节点需有ovs-ovn和kube-ovn-cni正常运行。natOutgoing: true是开启 SNAT 的开关。5.4 验证 EIP 与 SNAT对外服务与访问外网EIPElastic IP将 Pod IP 映射到宿主机 IP实现外部直接访问SNAT 让 Pod 访问外网时使用宿主机 IP# 1. 为 nginx-static Pod 绑定 EIP需先有 LoadBalancer Service kubectl expose pod nginx-static --port80 --typeLoadBalancer --namenginx-lb # 2. 查看 LB Service 的 External-IP通常是节点 IP kubectl get svc nginx-lb -o jsonpath{.status.loadBalancer.ingress[0].ip} # 3. 在集群外机器上 curl 该 IP:80应返回 nginx 欢迎页 # curl http://EXTERNAL-IP:80 # 4. 验证 SNAT在 nginx-static Pod 内访问公网检查源 IP kubectl exec nginx-static -- curl -s http://httpbin.org/ip | jq -r .origin # 输出应为 master1 或 worker 节点的公网 IP即 SNAT 后的 IP而非 Pod IP注意EIP 依赖multus和macvlan若curl失败请先确认 4.4 节的 multus 安装。httpbin.org/ip是验证 SNAT 的黄金标准它返回请求的真实源 IP。5.5 验证 Pod 级 QoS带宽限制Kube-OVN 支持对单个 Pod 入口/出口带宽限速通过 annotation 配置# 1. 为 nginx-static 添加入口限速 30Mbps kubectl annotate pod nginx-static ovn.kubernetes.io/ingress_rate30 --overwrite # 2. 在另一台机器上用 iperf3 测试带宽需提前安装 iperf3 # 在 client 机器执行 iperf3 -c NGINX_STATIC_POD_IP -p 80 -t 30 -i 5 # 观察 Bandwidth 行应稳定在 ~30Mbits/sec # 3. 移除限速并验证恢复 kubectl annotate pod nginx-static ovn.kubernetes.io/ingress_rate- iperf3 -c NGINX_STATIC_POD_IP -p 80 -t 30 -i 5 # Bandwidth 应飙升至节点网卡上限如 1Gbps技巧ovn.kubernetes.io/ingress_rate单位是 Mbps兆比特每秒不是 MB/s。-表示删除 annotation。QoS 限速在ovs-ovn的qos表中生效可用ovs-ofctl dump-flows br-int | grep qos查看流表。5.6 验证流量镜像安全与 NPM 对接将 Pod 的所有进出流量复制到指定网卡供 Wireshark 或 Suricata 分析# 1. 为 nginx-static 启用镜像到节点的 ens33 网卡 kubectl annotate pod nginx-static ovn.kubernetes.io/mirrorens33 --overwrite # 2. 在 nginx-static 所在节点上用 tcpdump 抓镜像流量 # 登录该节点执行 sudo tcpdump -i ens33 -n host 172.16.10.100 -c 10 # 应捕获到 10 个数据包源或目的为 172.16.10.100 # 3. 从集群外访问 nginx-static确认镜像包增加 curl http://NGINX_STATIC_POD_IP sudo tcpdump -i ens33 -n host 172.16.10.100 -c 5 # 新增的 5 个包应包含 HTTP 请求/响应注意流量镜像会消耗 CPU生产环境建议只对关键 Pod 开启。镜像目标网卡ens33必须与物理网卡同名且不能是lo或ovs虚拟网卡。5.7 验证子网管理与 Namespace 绑定多租户隔离Kube-OVN 的子网是全局资源可绑定到 Namespace实现网络策略隔离# 1. 创建新 Namespace kubectl create ns tenant-a # 2. 将 centralized-subnet 绑定到该 Namespace kubectl ko subnet-bind centralized-subnet -n tenant-a # 3. 在 tenant-a 中创建 Pod验证其 IP 来自 centralized-subnet kubectl run nginx-tenant --imagenginx:alpine -n tenant-a kubectl get pod -n tenant-a nginx-tenant -o jsonpath{.status.podIP} # 应输出172.16.20.xcentralized-subnet 的 CIDR # 4. 尝试从 default 命名空间 ping 该 Pod应失败子网间默认隔离 kubectl run busybox-default --imagebusybox:1.35 --rm -it --restartNever -n default -- sh -c ping -c 2 172.16.20.2 # 应显示 timeout证明子网隔离生效提示kubectl ko subnet-bind是绑定快捷命令。若要解绑执行kubectl ko subnet-unbind centralized-subnet -n tenant-a。子网隔离由 OVN ACL 流表实现无需额外 NetworkPolicy。5.8 验证多网络插件 IPAMMacvlan 场景Kube-OVN 可为 Macvlan 等第三方 CNI 提供 IP 分配避免 IP 冲突# 1. 创建 Macvlan NetworkAttachmentDefinition复用 4.4 节配置 # 2. 创建 Pod 并指定使用 macvlan-conf 网络 cat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: macvlan-pod namespace: default annotations: k8s.v1.cni.cncf.io/networks: macvlan-conf spec: containers: - name: alpine image: alpine:latest command: [/bin/sh, -c, sleep 3600] EOF # 3. 检查 Pod 是否获得 IP来自 Kube-OVN 管理的子网 kubectl get pod macvlan-pod -o jsonpath{.status.networks[0].ipAddress} # 应输出一个有效的 IP且该 IP 应在 default 子网的 usedIPs 中 kubectl ko get subnet default -o yaml | grep IP注意k8s.v1.cni.cncf.io/networksannotation 是 Multus 标准Kube-OVN 通过kube-ovn-cni拦截此请求并分配 IP。若此处 IP 为空说明 Multus 未正确调用 Kube-OVN CNI检查/etc/cni/net.d/下的 multus 配置。6. 验证收尾从kubectl ko到ovs-vsctl的三层信任链装完、配完、验完最后一步不是庆祝而是建立一套可持续的信任机制。我给自己定的铁律是每次集群变更升级 kernel、添加节点、调整子网都必须跑通这三组命令它们构成了 Kube-OVN 健康度的黄金三角——上层是kubectl ko的语义化视图中层是ovn-nbctl的逻辑网络快照底层是ovs-vsctl的物理设备状态。漏掉任何一层都可能埋下静默故障。6.1 第一层kubectl ko—— 人眼可读的网络事实kubectl ko是 Kube-OVN 的灵魂 CLI它把 OVN 的复杂状态翻译成运维语言。每天晨会前我必跑这三条# 1. 确认所有子网在线且 IP 充足UsedIPs TotalIPs kubectl ko get subnet -A # 2. 确认所有节点上的 ovs-ovn Agent 在线STATUSReady kubectl ko 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