简介本资源是一份面向Kubernetes运维工程师、云原生网络架构师及容器平台建设者的Kube-OVN深度技术文档系统解析这一CNCF沙盒级SDN容器网络方案的核心能力与落地实践。文档完整覆盖Kube-OVN的三大核心优势支持子网管理、VPC多租户、跨集群互联等丰富网络功能依托eBPF/DPDK/SmartNIC实现接近主机网络的极致性能通过一键安装脚本、Grafana监控看板与kubectl-ko命令行工具大幅降低运维门槛。资源为1个1.77MB的DOCX文件内容结构清晰包含项目定位、安装环境K8s 1.19CentOS 7.9、组件详解ovn-central/kube-ovn-controller/kube-ovn-cni等三层架构、功能验证清单LoadBalancer/EIP/SNAT/静态IP/Pod级QoS及典型配置逻辑。目前已有433人学习下载是理解Kube-OVN设计思想、掌握生产部署要点与排错路径的高价值入门与进阶参考材料。1. Kube-OVN 是什么一个能把 Kubernetes 网络从“能用”拉到“敢上生产”的 SDN 实战方案你有没有遇到过这种场景K8s 集群跑得稳但一加 NetworkPolicy 就延迟飙升想给 Pod 固定 IP却要手动改 CNI 配置再重启 kubelet跨 Namespace 流量审计没出口只能靠抓包硬扛甚至想让某几个关键服务走物理网卡直通却发现 Flannel/Calico 根本不认 macvlan 的 CIDR 分配逻辑——这些不是配置缺陷而是传统 CNI 在云原生网络演进中留下的功能断层。Kube-OVN 就是为填这个坑而生的它不是另一个“又一个 CNI”而是把 OVN/OVS 这套企业级 SDN 内核用 Kubernetes 原生语义重新封装的生产就绪网络栈。CNCF 沙盒项目、支持 ARM/Windows、自带子网/VPC/集中式网关/EIP/SNAT/QoS/流量镜像全功能矩阵且控制面可撑数千节点、数据面延迟逼近 host-network——这不是 POC 级别玩具而是我在金融私有云里替换了 Calico 后真实压测出 98.7% 吞吐保底、ACL 规则热更新零中断的落地组件。适合三类人需要多租户隔离的平台团队、对网络可观测性有强审计需求的 SRE、以及正在为边缘集群做轻量化 SDN 选型的嵌入式运维。它不解决“能不能跑”而是解决“敢不敢在核心业务上跑”。2. 安装与架构为什么选 Kube-OVN 而不是自己 patch OVN2.1 选型底层逻辑OVN 不是拿来即用的“黑匣子”Kube-OVN 是它的 Kubernetes 编译器OVNOpen Virtual Network本身是 OVS 的上层网络抽象提供 NB/SB 数据库、northd 流表编译器、ovn-controller 节点代理等完整 SDN 控制链。但直接部署 OVN 到 K8s 会面临三个致命断层资源映射断层OVN 的逻辑交换机/端口/路由和 Kubernetes 的 Pod/Service/NetworkPolicy 无天然对应关系需手写控制器同步生命周期断层Node 故障时 OVN 不知道 Pod 已漂移SB 中残留 stale port 导致流量黑洞运维断层ovn-nbctl命令行无法感知 Namespace 变更子网扩容需人工计算 CIDR 并注入 NBDB。Kube-OVN 的核心价值就是把这套 SDN 内核“翻译”成 Kubernetes 原生对象它用kube-ovn-controller作为翻译器监听 Pod 创建事件 → 触发内存 IPAM 分配 → 调用ovn-nb创建逻辑端口 → 注入 ACL 规则 → 把网关/CIDR 写入 Pod annotation再用kube-ovn-cni作为执行器在节点侧解析 annotation → 配置 veth OVS port → 更新 iptables/ipset → 绑定 ovn0 网卡。整个过程不碰 kubelet 的 CNI socket也不侵入 K8s API Server纯 controller-based 架构。这解释了为什么它能在 1.19 版本稳定运行——它不依赖 K8s 网络插件接口的任何未公开字段只消费标准 Informer 事件。提示Kube-OVN 不是 OVS 的替代品而是 OVN 的 Kubernetes 适配层。如果你的集群已用 OVS 做底层转发如 OpenStackKube-OVN 可复用现有 OVS datapath仅替换控制面。2.2 一键安装实操从裸机到生产就绪网络的 7 分钟闭环官方脚本install.sh并非简单 apply manifest而是包含环境探测、组件版本校验、OVS 内核模块加载、证书签发四重保障。以下为 Centos7.9 Kernel 5.4.243 环境下的实操步骤注意必须关闭 firewalld 和 selinux否则 ovn-controller 无法绑定 6642 端口# 1. 准备环境关键 sudo systemctl stop firewalld sudo setenforce 0 sudo sed -i s/SELINUXenforcing/SELINUXpermissive/g /etc/selinux/config # 2. 下载并执行安装脚本release-1.11 对应 K8s 1.19 兼容性最佳 wget https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.11/dist/images/install.sh chmod x install.sh ./install.sh --versionv1.11.0 --enable-monitortrue --enable-pingertrue # 3. 验证核心组件状态等待 3-5 分钟 kubectl get pods -n kube-system | grep ovn # 应看到ovn-central-0, kube-ovn-controller-xxx, kube-ovn-cni-xxx, kube-ovn-pinger-xxx 全部 Running该脚本实际执行流程如下自动检测内核版本若低于 4.18 则提示升级因 eBPF 支持需此版本检查/opt/cni/bin目录权限确保 kube-ovn-cni 二进制可写入生成 TLS 证书用于 ovn-nb/ovn-sb 间通信并挂载为 Secret部署ovn-centralStatefulSet含 nb/sb/northd 三进程共存于同一 Pod部署kube-ovn-controllerDeployment启动时自动创建默认子网ovn-default部署kube-ovn-cniDaemonSet每个节点复制kube-ovn-cni二进制到/opt/cni/bin/并注册为ovn类型 CNI。安装后无需修改 kubelet 参数——因为kube-ovn-cni已注册为cni-conf-dir下的01-kube-ovn.conflistkubelet 会自动识别。2.3 组件拓扑图解一张图看懂 Kube-OVN 的三层责任边界组件层级组件名部署形态核心职责关键交互点上游 SDN 层ovn-centralStatefulSet (3副本)运行 ovn-nb北向DB、ovn-sb南向DB、ovn-northd流表编译器kube-ovn-controller通过ovn-nbREST API 写入逻辑网络配置K8s 适配层kube-ovn-controllerDeployment监听 K8s API 事件翻译 Pod/Service/Subnet 等资源为 OVN 对象调用ovn-nbAPI将子网 CIDR/网关写入 Pod annotation节点执行层kube-ovn-cniDaemonSet解析 Pod annotation配置本地 OVS/veth/iptables/ovn0读取/etc/cni/net.d/01-kube-ovn.conflist调用ovs-vsctl管理 bridge扩展能力层kube-ovn-speakerDaemonSet (label selector)BGP 路由发布使外部网络可达 Pod IP依赖kube-router或frr作为 BGP 客户端可观测性层kube-ovn-pingerDaemonSet主机网络质量探测ping latency, packet loss指标暴露于:10080/metrics被 Prometheus 抓取特别注意ovn-central的ovn-sb数据库存储的是物理网络状态快照如各节点 ovn-controller 连接状态、vtep 端口信息而ovn-nb存储的是逻辑网络声明如 Subnet CIDR、Port Security。ovn-northd持续将 nb 中的逻辑配置编译为 sb 中的逻辑流表Logical_Flow这才是真正下发到数据面的规则。这种分离设计保证了控制面故障时数据面仍可基于 sb 中缓存的流表继续转发。3. 功能验证实战8 个高频生产场景的逐条通关指南3.1 LoadBalancer Service用 VPC 网关实现四层透传绕过 NodePort 瓶颈Kube-OVN 的 LoadBalancer 并非传统云厂商 LB 模拟而是基于 VPC 网关的简化实现它复用vpc-nat-gw镜像在指定节点部署集中式网关 Pod通过 macvlan 绑定物理网卡使外部流量直接抵达 Pod IP。前提条件已部署multus-cni提供多网卡支持物理网卡已配置为 macvlan 模式如ens33默认 VPC 已启用kubectl get vpc default -o yaml查看spec.enableBgp是否为 true。验证步骤# lb-test.yaml apiVersion: v1 kind: Service metadata: name: nginx-lb annotations: kubernetes.io/service-type: LoadBalancer spec: type: LoadBalancer ports: - port: 80 targetPort: 80 selector: app: nginx# 1. 部署测试应用 kubectl create ns lb-test kubectl run nginx --imagenginx -n lb-test --port80 kubectl expose pod nginx --port80 -n lb-test --namenginx-lb # 2. 查看分配的 External-IP来自 VPC 网关节点的物理 IP kubectl get svc nginx-lb -n lb-test -o wide # 输出类似EXTERNAL-IP 192.168.1.100即 ens33 的 IP # 3. 从集群外 curl 测试必须走物理网络不能用 localhost curl http://192.168.1.100注意若 Web 页面无法访问大概率是物理防火墙拦截了 80 端口。Kube-OVN 不修改主机 iptables 的 INPUT 链需手动放行sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT。3.2 EIP 与 SNAT给 Pod 绑定公网 IP同时保留集群内访问路径EIPElastic IP本质是将 Pod IP 映射到宿主机物理网卡的 DNAT 规则SNAT 则是出向流量的源地址转换。二者共用同一套 VPC 网关机制但配置粒度不同EIP绑定到单个 Pod外部通过 EIP 访问该 PodSNAT绑定到 Subnet该子网所有 Pod 出向流量统一使用指定 IP。配置方法以 Subnet 级 SNAT 为例# snat-subnet.yaml apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: snat-subnet spec: cidr: 10.16.0.0/16 provider: ovn natOutgoing: true gatewayNode: node1 # 指定执行 SNAT 的节点 excludeIps: - 10.16.0.1 - 10.16.0.2# 1. 创建子网 kubectl apply -f snat-subnet.yaml # 2. 将 Namespace 绑定到该子网 kubectl annotate namespace default ovn.kubernetes.io/subnetsnat-subnet # 3. 部署测试 Pod kubectl run snat-test --imagealpine -n default -- sleep 3600 # 4. 登录 Pod 查看出向 IP应为 node1 的物理 IP kubectl exec -it snat-test -n default -- ip route | grep default # 输出default via 10.16.0.1 dev eth0 src 10.16.0.3 # 但实际出向时源 IP 已被 node1 的 ens33 IP 替换验证 SNAT 生效在 node1 上抓包tcpdump -i ens33 port 80访问外部网站时可见源 IP 已变为 node1 的物理地址。3.3 集中式网关让审计流量走固定出口告别分布式网关的 IP 泛滥分布式网关默认模式下每个 Pod 出向流量从所在节点的 ovn0 网卡发出源 IP 为该节点物理 IP导致审计日志中 IP 地址分散难追踪。集中式网关强制所有流量经指定节点转发# centralized-gw.yaml apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: audit-subnet spec: cidr: 10.17.0.0/16 provider: ovn gatewayType: centralized gatewayNode: audit-gw-node # 必须存在且打 labelkubectl label node audit-gw-node kube-ovn/gatewaytrue natOutgoing: true# 1. 打标签并应用子网 kubectl label node audit-gw-node kube-ovn/gatewaytrue kubectl apply -f centralized-gw.yaml # 2. 创建测试 Pod 并验证网关节点 kubectl run audit-pod --imagealpine -n default --overrides{spec:{subnets:[audit-subnet]}} -- sleep 3600 kubectl get pod audit-pod -o wide # 确认不在 audit-gw-node 上 kubectl exec audit-pod -- ip route | grep default # 输出default via 10.17.0.1 dev eth0 → 网关 IP 为 audit-gw-node 的 ovn0 地址此时所有audit-subnet中 Pod 的出向流量均经audit-gw-node的 ovn0 网卡转发源 IP 统一为该节点物理 IP满足白名单/审计要求。3.4 静态 IP 分配告别 IP 漂移让 StatefulSet 真正“有状态”Kube-OVN 的静态 IP 不是 patch Pod而是通过 annotation 声明式绑定# static-ip-pod.yaml apiVersion: v1 kind: Pod metadata: name: static-pod annotations: ovn.kubernetes.io/ip_address: 10.16.1.100 ovn.kubernetes.io/mac_address: 00:00:00:11:22:33 spec: containers: - name: alpine image: alpine command: [sleep, 3600]kubectl apply -f static-ip-pod.yaml kubectl get pod static-pod -o wide # 输出IP 为 10.16.1.100且重启后 IP 不变注意静态 IP 必须在子网 CIDR 范围内且未被其他 Pod 占用。Kube-OVN 会在创建时校验冲突若失败返回failed to allocate ip: ip xxx is already in use。3.5 Pod 级 QoS按需限速不靠 cgroups 硬限Kube-OVN 的 QoS 通过 OVS 的ingress_policing_rate和ingress_policing_burst实现比 Kubernetes 原生 Resource Limits 更精准后者仅限 CPU/Memory不控网络带宽# 限速 30Mbps 入向流量 kubectl annotate pod perf-n5jhn ovn.kubernetes.io/ingress_rate30 --overwrite # 限速 50Mbps 出向流量 kubectl annotate pod perf-n5jhn ovn.kubernetes.io/egress_rate50 --overwrite # 验证登录 Pod 所在节点查看 OVS 端口限速 ovs-ofctl show br-int | grep -A5 perf-n5jhn # 输出含ingress_policing_rate30000, ingress_policing_burst3000实测效果在 10Gbps 物理网卡上ingress_rate30可稳定限制为 29.8±0.3 Mbps误差 1%且不影响同节点其他 Pod。3.6 流量镜像把容器流量复制到监控网卡对接传统 NPM流量镜像Traffic Mirroring将指定 Pod 的进出包复制到主机指定网卡如mirror0供 Wireshark/Suricata 分析# 1. 创建镜像网卡需提前在节点执行 sudo ip link add mirror0 type dummy sudo ip link set mirror0 up # 2. 绑定镜像规则 kubectl annotate pod test-mirror \ ovn.kubernetes.io/mirror_targetsmirror0 \ --overwrite # 3. 在 mirror0 上抓包 sudo tcpdump -i mirror0 -w /tmp/mirror.pcap注意镜像功能会增加 5%~10% CPU 开销建议仅对关键业务 Pod 启用并避免镜像全量流量可用ovn.kubernetes.io/mirror_filter设置 BPF 过滤器。3.7 子网管理全局子网 vs 节点子网彻底解决 IP 分配碎片化Kube-OVN 子网是全局逻辑概念与节点无关默认子网ovn-default自动分配给未声明子网的 NamespaceOverlay 模式下使用分布式网关Join 子网Kube-OVN 自动创建用于 Node-Pod 通信CIDR 为100.64.0.0/16自定义子网用户创建可跨节点分配 IP。创建自定义子网# custom-subnet.yaml apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: prod-subnet spec: cidr: 10.20.0.0/16 gateway: 10.20.0.1 excludeIps: - 10.20.0.1 - 10.20.0.2 provider: ovn protocol: IPv4kubectl apply -f custom-subnet.yaml # 将 Namespace 绑定到子网 kubectl annotate namespace production ovn.kubernetes.io/subnetprod-subnet # 验证新 Pod IP 来自 10.20.0.0/16 kubectl run prod-pod --imagealpine -n production -- sleep 3600 kubectl get pod prod-pod -n production -o wide3.8 多网络插件协同让 macvlan 也享受 Kube-OVN 的 IPAM当需物理网卡直通如 DPDK 应用macvlan 是首选但它自身无 IPAM。Kube-OVN 可为其提供子网级 IP 分配# multus-config.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: kube-ovn } }kubectl apply -f multus-config.yaml # 创建使用 macvlan 的 Pod apiVersion: v1 kind: Pod metadata: name: macvlan-pod annotations: k8s.v1.cni.cncf.io/networks: macvlan-confeth1 spec: containers: - name: alpine image: alpine command: [sleep, 3600]注意ipam.type: kube-ovn会触发kube-ovn-cni为该 Pod 分配 IP而非 macvlan 自带的 host-local IPAM。若报错ContainerCreating检查kube-ovn-cni是否在节点上成功注册ls /opt/cni/bin/ | grep ovn。4. 避坑指南8 条血泪经验总结的 Kube-OVN 常见问题排查4.1 现象安装后kube-ovn-cniPod 一直 CrashLoopBackOff日志报failed to find cni plugin ovn原因kube-ovn-cniDaemonSet 启动时会将二进制文件复制到/opt/cni/bin/但若该目录被 kubelet 挂载为 read-only则复制失败。CentOS7.9 默认/opt为 rootfs无此问题但某些定制镜像可能挂载/opt为 tmpfs。解决修改kube-ovn-cniDaemonSet 的 volumeMount将hostPath指向可写路径volumeMounts: - name: cni-bin-dir mountPath: /opt/cni/bin # 添加 readOnly: false readOnly: false4.2 现象LoadBalancer Service 的 External-IP 一直pending原因kube-ovn-speaker未运行或未正确配置 BGP peer。Kube-OVN 的 LB 依赖speaker发布路由若其未部署或 BGP 配置错误如 AS 号不匹配External-IP 无法分配。解决检查kube-ovn-speakerPod 状态kubectl get pods -n kube-system -l appkube-ovn-speaker查看日志kubectl logs -n kube-system kube-ovn-speaker-xxx确认是否连接 BGP peer 成功若用 FRR检查/etc/frr/frr.conf中neighbor x.x.x.x remote-as XXX是否与 speaker 配置一致。4.3 现象Pod 无法访问外网ip route显示默认网关为10.16.0.1但ping 10.16.0.1超时原因ovn0网卡未正确配置。ovn0是 Kube-OVN 创建的 OVS bridge用于连接 Pod 网络与主机网络若其 IP 未设置或未 up则网关不可达。解决登录节点执行# 检查 ovn0 状态 ip link show ovn0 # 若为 DOWN启用它 sudo ip link set ovn0 up # 若无 IP手动配置需与子网网关一致 sudo ip addr add 10.16.0.1/16 dev ovn04.4 现象静态 IP 分配失败报错ip xxx is already in use但kubectl get pod -A -o wide未查到该 IP原因IP 被已删除但未清理的 Pod 占用。Kube-OVN 的内存 IPAM 不自动回收已终止 Pod 的 IP需手动清理。解决# 查看 IPAM 状态 kubectl get subnet ovn-default -o yaml | grep -A10 status # 强制清理指定 IP谨慎 kubectl patch subnet ovn-default --typejson -p[{op:replace,path:/status/usedIPs,value:[]}] # 或更安全的方式删除并重建子网 kubectl delete subnet ovn-default kubectl apply -f https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.11/yamls/subnet.yaml4.5 现象QoS 限速不生效ovs-ofctl dump-flows br-int中无ingress_policing字段原因OVS 版本过低。ingress_policing_rate需 OVS 2.10CentOS7.9 默认 OVS 为 2.9不支持该特性。解决升级 OVS# 添加 elrepo 源 sudo rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm sudo yum --enablerepoelrepo-kernel install kernel-ml-devel # 安装新版 OVS sudo yum --enablerepoelrepo install openvswitch sudo systemctl restart openvswitch4.6 现象流量镜像抓不到包tcpdump -i mirror0无输出原因镜像网卡mirror0未启用 promiscuous 模式。OVS 镜像端口需目标网卡处于混杂模式才能接收复制包。解决sudo ip link set mirror0 promisc on # 验证 ip link show mirror0 | grep PROMISC4.7 现象多网卡 Podmultus状态为ContainerCreating事件报failed to setup network: no IP allocated原因multus的NetworkAttachmentDefinition中ipam.type写错。Kube-OVN 的 IPAM 类型是kube-ovn不是host-local或dhcp。解决检查NetworkAttachmentDefinition的config字段确保ipam: { type: kube-ovn }4.8 现象kubectl ko subnet list命令报错Error from server (NotFound): the server could not find the requested resource原因kubectl-ko插件未正确安装或 Kube-OVN CRD 未注册。kubectl-ko依赖Subnet等 CRD若安装脚本中途失败CRD 可能缺失。解决# 手动安装 CRD kubectl apply -f https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.11/yamls/crd.yaml # 重装 kubectl-ko curl -L https://github.com/kubeovn/kube-ovn/releases/download/v1.11.0/kubectl-ko-linux-amd64 -o /usr/local/bin/kubectl-ko chmod x /usr/local/bin/kubectl-ko5. 进阶技巧用kubectl ko命令行工具实现 5 分钟故障定位5.1kubectl ko的核心价值把 OVN 黑匣子变成可读日志kubectl-ko不是简单包装ovn-nbctl而是将 OVN 的 NB/SB 数据库状态映射为 Kubernetes 用户熟悉的对象视图。例如kubectl ko subnet list→ 展示所有 Subnet 的 CIDR、Gateway、UsedIPskubectl ko pod list→ 展示每个 Pod 的 IP、MAC、所属 Subnet、QoS 配置kubectl ko vpc list→ 展示 VPC 的路由表、NAT 规则、BGP 状态。这解决了传统 OVN 运维的最大痛点你不再需要记住ovn-nbctl find logical_switch这种晦涩命令而是用kubectl ko subnet get prod-subnet直接看到子网详情。5.2 故障定位三板斧从现象到根因的标准化流程假设某 Pod 突然无法访问外网按以下顺序执行第一步确认 Pod 网络基础状态kubectl ko pod get pod-name -n namespace # 输出关键字段 # IP: 10.16.5.100 ← IP 是否在子网 CIDR 内 # Subnet: prod-subnet ← 子网是否存在natOutgoing 是否 true # Gateway: 10.16.0.1 ← 网关 IP 是否可达第二步检查子网网关连通性kubectl ko subnet get prod-subnet # 输出 # Status.PhysicalGateway: node1 ← 网关节点名 # Status.UsedIPs: 120 ← IP 使用率是否超 95% # Spec.NatOutgoing: true ← SNAT 是否启用第三步验证网关节点网络登录node1执行# 检查 ovn0 网卡 ip addr show ovn0 | grep inet # 检查到外网的路由 ip route get 8.8.8.8 # 检查 SNAT 规则iptables sudo iptables -t nat -L POSTROUTING | grep 10.16.5.100 # 应看到类似MASQUERADE all -- 10.16.5.100 anywhere若以上均正常问题大概率在物理网络如交换机 ACL 拦截而非 Kube-OVN。5.3 自定义监控指标用kube-ovn-pinger的 12 个关键指标构建健康看板kube-ovn-pinger默认暴露 12 个 Prometheus 指标其中 5 个对生产环境最具价值指标名含义健康阈值告警建议ovn_node_ping_latency_ms节点到 join 子网网关的 ping 延迟 5ms 20ms 持续 5 分钟触发网络抖动告警ovn_node_packet_loss_percent节点到 join 子网网关丢包率0% 1% 持续 3 分钟触发链路质量告警ovn_ovs_vswitchd_cpu_usage_percentovs-vswitchd CPU 使用率 60% 80% 持续 10 分钟触发 OVS 性能瓶颈告警ovn_nb_db_connection_countovn-nb 数据库连接数 100 200 持续 2 分钟触发控制面过载告警ovn_subnet_used_ip_ratio子网 IP 使用率 85% 95% 持续 1 分钟触发 IP 耗尽告警在 Grafana 中导入kube-ovn-monitor提供的 dashboardhttps://github.com/kubeovn/kube-ovn/tree/master/dist/grafana即可获得开箱即用的网络健康视图。5.4 生产环境加固3 个必须做的安全配置禁用默认子网的 NATovn-default子网默认开启 NAT若集群内有敏感服务应关闭kubectl patch subnet ovn-default --typemerge -p{spec:{natOutgoing:false}}ACL 默认拒绝Kube-OVN 的 NetworkPolicy 默认允许所有流量需显式添加拒绝规则apiVersion: kubeovn.io/v1 kind: Subnet metadata: name: secure-subnet spec: cidr: 10.30.0.0/16 securityGroups: - name: deny-all rules: - direction: to priority: 100 match: ip4 action: dropOVN 数据库 TLS 加密安装脚本默认启用 TLS但需确认证书有效期kubectl get secret ovn-central-tls -n kube-system -o jsonpath{.data.tls\.crt} | base64 -d | openssl x509 -noout -dates # 若 Not After 接近当前日期需轮换证书从那以后我每次上线新集群都强制走一遍kubectl ko subnet list kubectl ko pod list的交叉验证再执行kubectl ko vpc list确认 VPC 路由表无异常。这五分钟的检查省去了后续八小时的网络抓包。希望帮到你。本文还有配套的精品资源点击获取