企业官网建设流程全解析

简介：本资源是一份面向Kubernetes运维工程师、云原生网络架构师及容器平台建设者的Kube-OVN深度技术文档，系统解析这一CNCF沙盒项目的原理、能力与落地实践。文档覆盖其作为SDN增强型容器网络方案的核心价值：在功能上支持子网管理、VPC多租户、跨集群互联、QoS与ACL等企业级特性；在性能上依托eBPF/DPDK优化实现接近主机网络的吞吐与延迟；在易用性上提供一键安装脚本、Grafana监控看板及kubectl-ko命令行工具。资源为1个1.77MB的Word文档（.docx），完整展开Kube-OVN三大组件体系——上游OVN/OVS服务、核心控制器kube-ovn-controller与CNI插件、以及监控运维工具链，并详述安装环境要求（K8s 1.19+CentOS 7.9）、各组件交互逻辑与典型功能验证项。目前已有433人学习下载，适合希望深入理解Kube-OVN架构设计、部署逻辑与生产运维要点的技术人员。

1. Kube-OVN：为什么一个“只是把 OVN 套进 Kubernetes”的项目，竟能在 eBPF 当道的今天稳坐 CNCF 沙盒、支撑万级 Pod 并提供子网级 QoS 和 VPC 多租户？

你可能已经用过 Cilium、Calico 或 Flannel——它们要么靠 eBPF 玩转数据面，要么靠 BGP 打通物理网络，但几乎没人能同时做到三件事：给每个 Namespace 分配独立子网、让 Pod 出向流量固定走某台节点的 IP（集中式网关）、还能对单个 Pod 做带宽+延迟+丢包三级 QoS 控制。Kube-OVN 就是那个“不声不响干完这三件”的项目。它没重写内核、没自研协议栈，而是把 OVN 这个成熟 SDN 控制器，用一套极其克制又精准的“语义翻译层”嵌进 Kubernetes 的资源生命周期里。这不是简单包装——当你在 YAML 里写ovn.kubernetes.io/ingress_rate=30，背后触发的是控制器生成 OVN 逻辑流表 → ovn-northd 编译为 SB 流 → ovn-controller 下发到本地 OVS → ovs-vswitchd 调用内核 tc 模块配置 HTB qdisc 的完整链路。更关键的是，它把 OVN 原本面向虚拟机的“网络拓扑描述语言”，映射成了 Kubernetes 原生对象（Subnet、VPC、IPPool）的声明式 API。这意味着你不用学 OVN 的ovn-nbctl命令，就能做 ACL、SNAT、EIP、流量镜像——所有操作都落在kubectl apply -f subnet.yaml这一行里。这种“能力下沉但接口上浮”的设计，正是它在云原生网络工具箱里不可替代的原因：它不争性能第一，但把 SDN 的工程确定性，第一次真正带进了 Kubernetes 的 Operator 范式。

2. OVN 与 Kubernetes 的语义鸿沟：kube-ovn-controller 如何把 Pod 创建事件翻译成 7 层网络策略？

OVN 是一个典型的“网络即代码”系统：它的 northbound DB（ovn-nb）存的是逻辑交换机、逻辑路由器、ACL 规则等抽象模型；southbound DB（ovn-sb）存的是这些逻辑模型编译后的分布式流表；而 ovn-northd 则是两者之间的“编译器”。Kubernetes 则完全不同：它只认 Pod、Service、NetworkPolicy 这些资源对象，所有网络行为都必须通过 CNI 插件在节点本地执行。这两套体系之间存在天然的语义断层——OVN 不知道什么是 “Pod IP”，Kubernetes 也不理解 “logical switch port binding”。kube-ovn-controller 的核心价值，就是在这条断层带上架起一座双向翻译桥。它不是简单地监听事件然后调用ovn-nbctl add-lsp，而是构建了一套完整的“资源状态机映射表”。

2.1 Pod 创建事件的七步翻译链：从 annotation 写入到 ovn0 路由注入

当 kubelet 调用 CNI 创建 Pod 时，流程远比想象中复杂：

1. 事件捕获：kube-ovn-controller监听Pod资源的ADDED事件，检查其spec.nodeName和metadata.namespace；
2. 子网定位：根据 Namespace 关联的SubnetCRD（或 fallback 到默认子网），获取 CIDR、gateway、exclude_ips 等参数；
3. IPAM 分配：调用内置内存型 IPAM（非 etcd 后端），从子网空闲池中分配 IP，并检查是否被IPPool预留；
4. 逻辑端口创建：调用ovn-nbAPI 创建logical_port，绑定到对应logical_switch，设置addresses=["0a:00:00:00:00:01 10.16.0.5"]；
5. ACL 注入：若该 Subnet 启用了disableGatewayCheck: true或关联了NetworkPolicy，则生成acl规则并附加到逻辑交换机；
6. 静态路由同步：为该 Pod IP 向join逻辑路由器添加static_route，确保 Node→Pod 可达；
7. Annotation 回写：将分配的 IP、子网网关、DNS 配置等写入 Pod 的annotations，例如：

   annotations: ovn.kubernetes.io/ip_address: "10.16.0.5" ovn.kubernetes.io/mac_address: "0a:00:00:00:00:01" ovn.kubernetes.io/subnet: "ovn-default" ovn.kubernetes.io/gateway: "10.16.0.1"

   这些 annotation 是kube-ovn-cni启动时唯一依赖的数据源——它不查 etcd、不连 API Server，只读 annotation 并执行本地 OVS 配置。

提示：这个 annotation 回写机制是 Kube-OVN 的关键设计取舍。它避免了 CNI 插件在每次调用时都需访问 Kubernetes API Server（高并发下易成为瓶颈），但也意味着如果 controller 崩溃且未完成回写，CNI 将因 missing annotation 而失败。生产环境务必启用--enable-leader-election。

2.2 NetworkPolicy 到 OVN ACL 的映射：为什么它比 Calico 更接近“网络工程师直觉”？

Kubernetes 的NetworkPolicy是一个极度简化的模型：只支持podSelector+namespaceSelector+ports。而 OVN 的acl支持完整的五元组匹配、allow-related、drop动作、log标记、甚至基于reg0寄存器的状态跟踪。kube-ovn-controller 的翻译不是“一对一硬编码”，而是做了语义升维：

最关键的是，它把NetworkPolicy的spec.podSelector和spec.namespaceSelector编译为 OVN 的address_set，而非硬编码 IP 列表。这意味着当一个 Pod 被删除或新建时，kube-ovn-controller只需更新address_set成员，无需重刷整条 ACL——OVN 的address_set是 southbound DB 中的一等公民，ovn-controller 会自动将其编译为高效的ct_state匹配规则。这种设计让 ACL 更新延迟稳定在毫秒级，远优于 Calico 的 iptables 链遍历方案。

2.3 VPC 多租户的底层实现：不是命名空间隔离，而是逻辑路由器级切片

Kube-OVN 的 VPC 并非简单的标签隔离，而是直接复用 OVN 的logical_router抽象。每个 VPC 对应一个独立的logical_router（如vpc-prod），其下挂载多个logical_switch（即 Subnet），并通过logical_router_port连接join逻辑路由器实现跨 VPC 通信。这种设计带来两个硬性保障：

• 路由隔离：不同 VPC 的logical_router之间默认无路由，除非显式创建static_route或policy_route；
• NAT 独立：每个 VPC 可配置独立的nat表，snat规则只作用于本 VPC 下的 Subnet 出向流量，dnat_and_snat可为 EIP 提供双向地址转换。

验证这一点只需一条命令：

# 查看 vpc-prod 的 NAT 规则 ovn-nbctl --db=tcp://127.0.0.1:6641 list nat | grep "vpc-prod" # 输出示例： # _uuid : 1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p # external_ip : "203.0.113.10" # logical_ip : "10.100.0.0/16" # type : "snat" # uuid : 7p6o5n4m3l2k1j0i9h8g7f6e5d4c3b2a1

你会发现external_ip和logical_ip完全属于 VPC 上下文，与 Kubernetes 的Namespace无任何耦合。这才是真正的多租户——不是靠 RBAC 控制谁能看哪个 Subnet，而是网络平面本身已物理隔离。

2.4 避坑：kube-ovn-controller 启动失败的五大血泪现场

Kube-OVN 的控制器看似“一键安装”，但实际部署中 80% 的问题都卡在 controller 启动阶段。以下是真实环境中高频踩坑点，按现象→原因→解决结构整理：

现象一：controller Pod 一直 CrashLoopBackOff，日志显示failed to get node xxx: nodes "xxx" not found
→ 原因：kube-ovn-controller启动时需 ListWatchNode资源以初始化节点信息，但集群中存在已删除但未彻底清理的 Node 对象（如kubectl delete node xxx后未清 etcd）。OVN 的node对象与 KubernetesNode强绑定，缺失会导致初始化失败。
→ 解决：kubectl get node -o wide确认所有 Node 状态为Ready；若存在NotReady且无法恢复，先kubectl delete node xxx，再手动清理 OVN NB DB 中残留记录：ovn-nbctl --db=tcp://127.0.0.1:6641 remove node xxx other_config ovn-node-id。

现象二：controller 日志反复打印failed to sync subnet xxx: context deadline exceeded
→ 原因：SubnetCRD 的 finalizer 未被正确移除，常见于强制删除 Subnet 后残留finalizer.ovn.kubernetes.io/subnet。controller 会不断尝试 reconcile 该资源，但因 finalizer 存在而阻塞。
→ 解决：kubectl patch subnet xxx -p '{"metadata":{"finalizers":null}}' --type=merge强制清除 finalizer；随后检查ovn-nbctl list logical_switch | grep xxx确认对应逻辑交换机已删除。

现象三：controller 启动后不处理任何 Pod 事件，kubectl get po -n kube-ovn显示 controller Running，但ovn-nbctl list logical_port为空
→ 原因：kube-ovn-controller默认使用--kubeconfig指向/etc/kubernetes/admin.conf，但在某些发行版（如 RKE2）中该路径不存在，或权限不足（/etc/kubernetes为 root:root 且 600 权限）。controller 因无法加载 kubeconfig 而静默降级为只读模式。
→ 解决：修改 Deployment，显式挂载 kubeconfig 并设置--kubeconfig=/etc/kube-ovn/kubeconfig；或改用 serviceaccount token 方式认证（推荐）。

现象四：controller 日志出现failed to create logical port for pod xxx: port xxx already exists
→ 原因：Pod 被快速重建（如 Deployment rollout），旧 Pod 的逻辑端口未及时清理，新 Pod 请求同名端口（OVN 要求logical_port.name全局唯一）。根本原因是kube-ovn-cni的 DEL 操作失败（如节点宕机），导致ovn-nb中残留端口。
→ 解决：手动清理：ovn-nbctl --db=tcp://127.0.0.1:6641 lsp-del k8s-pod-xxx；长期方案是启用--enable-delete-logical-port-retry参数并调大重试间隔。

现象五：controller 启动后持续报failed to update node xxx: Operation timed out
→ 原因：ovn-central组件（ovn-nb/ovn-sb）响应缓慢，通常因ovn-nbDB 过大（>10MB）或ovn-sb流表爆炸（>5000 条）。Kube-OVN 默认未开启ovn-nb的--db-limit，历史配置堆积导致 GC 延迟。
→ 解决：重启ovn-central并添加启动参数：--db-limit=10000000（限制 DB 大小为 10MB）；定期执行ovn-nbctl --db=tcp://127.0.0.1:6641 purge清理已删除资源。

3. 数据面真相：kube-ovn-cni 如何绕过 iptables，用 OVS+tc 实现 Pod 级 QoS 和流量镜像？

如果说kube-ovn-controller是大脑，那kube-ovn-cni就是手脚——它不参与决策，只负责把 controller 下发的 annotation，翻译成节点本地可执行的网络指令。但这个“翻译”过程绝非简单调用ip link add。它深度介入 Linux 网络栈，用 OVS 替代传统 bridge，用 tc 替代 iptables，用ovn0网卡打通容器与主机网络。这种设计让 Kube-OVN 在数据面获得了远超标准 CNI 的控制粒度。

3.1 CNI ADD 流程的八层穿透：从 veth pair 到 ovn0 路由表

当kubelet调用kube-ovn-cni的ADD方法时，它执行的是一套精密的“网络装配流水线”：

1. veth 创建：生成vethXXX（容器侧）和vethYYY（主机侧）pair，设置vethXXX的 netns 为 Pod 容器；
2. OVS 端口绑定：将vethYYY添加为 OVS bridgebr-int的 port，并设置external_ids:pod_name=xxx标签；
3. MAC/IP 配置：从 Pod annotation 读取ovn.kubernetes.io/mac_address和ovn.kubernetes.io/ip_address，配置vethXXX的 MAC 和 IP；
4. ovn0 网卡初始化：检查ovn0是否存在，若不存在则创建ovs-vsctl add-br ovn0，并为其分配join子网的 IP（如100.64.0.2/16）；
5. 路由注入：向主机路由表添加10.16.0.0/16 via 100.64.0.1 dev ovn0（指向 join 逻辑路由器），确保 Pod→Node 可达；
6. ARP 代理启用：echo 1 > /proc/sys/net/ipv4/conf/ovn0/proxy_arp，使ovn0能响应 Pod IP 的 ARP 请求；
7. QoS 初始化：若 annotation 中存在ovn.kubernetes.io/ingress_rate，则在vethYYY上创建htbqdisc 并设置rate；
8. DNS 注入：将ovn.kubernetes.io/dns_server写入/etc/resolv.conf（若 Pod 未显式指定）。

整个过程不碰iptables一条规则——所有转发、NAT、ACL 都由 OVS 流表完成。这是性能的关键：OVS 的 datapath 在内核态，流表匹配是哈希查找，而 iptables 是链式遍历。

3.2 Pod 级 QoS 的 tc 实现：为什么 ingress_rate 不是“限速”，而是“整形”？

Kube-OVN 的ovn.kubernetes.io/ingress_rate注解，常被误解为“限制 Pod 入向带宽”。实际上，它实现的是Ingress Traffic Shaping，底层完全依赖 Linux tc 的ingressqdisc +ifb（Intermediate Functional Block）设备：

# kube-ovn-cni 执行的命令链（简化） tc qdisc add dev ifb0 root handle ffff: ingress tc filter add dev ifb0 parent ffff: protocol ip u32 match ip dst 10.16.0.5/32 flowid 1:1 tc qdisc add dev ifb0 parent 1:1 handle 10: htb default 30 tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 30mbit ceil 30mbit

但注意：ifb0是一个虚拟设备，所有进入主机的流量需先被重定向至此。kube-ovn-cni通过tc filter将目标为该 Pod IP 的流量重定向到ifb0，再在ifb0上应用htb整形。这带来两个关键事实：

• 它只影响入向流量：Pod 出向（egress）不受此注解控制，需用ovn.kubernetes.io/egress_rate（底层为htbonvethYYY）；
• 它不降低延迟，但增加缓冲：htb会排队等待发送，若流量突发超过rate，数据包将在ifb0队列中等待，导致 bufferbloat。这也是文档中提到“QoS 带来 5%~10% CPU 开销”的主因——CPU 花在队列管理和定时器上。

提示：ingress_rate的单位是mbit（兆比特/秒），不是MiB/s。若你设ingress_rate=30，实际限速为30/8 = 3.75 MiB/s。很多用户因单位混淆导致限速效果“看起来没生效”。

3.3 流量镜像的 OVS 实现：为什么它比 eBPF 抓包更稳定但更重？

流量镜像（Traffic Mirroring）功能允许将 Pod 的进出流量复制一份到指定主机网卡（如eth0），供 Wireshark 或 NPM 工具分析。Kube-OVN 的实现不依赖 eBPF，而是用 OVS 的mirroraction：

# kube-ovn-cni 为 Pod A 启用镜像到 eth0 的命令 ovs-vsctl --may-exist add-port br-int mirror-eth0 -- set interface mirror-eth0 type=system options:mirror-of=eth0 ovs-ofctl add-flow br-int "table=0, priority=100, in_port=1, actions=mirror:mirror-eth0,normal"

这里mirror-eth0是一个虚拟 port，其options:mirror-of=eth0表示将流量镜像到物理eth0。OVS 的mirror是 datapath 层特性，所有匹配流表的包都会被克隆并发送到镜像端口。

优势在于稳定性：它不依赖内核版本（eBPF 需 4.15+），不涉及复杂的程序加载，且镜像流量与原始流量完全隔离。但代价是性能开销更大——每个镜像包都要经历一次完整的网络栈（从 OVS 到eth0的dev_queue_xmit），CPU 消耗比 eBPF 的bpf_clone_redirect()高 3~5 倍。这也是官方文档强调“5%~10% 额外 CPU 消耗”的依据。

3.4 避坑：kube-ovn-cni 配置失败的四大玄学时刻

kube-ovn-cni的问题往往表现为 Pod 卡在ContainerCreating，日志却只有CNI plugin failed这样模糊提示。以下是必须掌握的排查路径：

现象一：Pod 一直处于ContainerCreating，kubectl describe po xxx显示Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox
→ 原因：kube-ovn-cni二进制文件未正确复制到/opt/cni/bin/，或权限不对（需+x）。常见于手动修改kube-ovn-cniDaemonSet 的hostPath挂载路径错误。
→ 解决：登录节点执行ls -l /opt/cni/bin/kube-ovn-cni，确认存在且可执行；若缺失，检查 DaemonSet 的volumeMounts是否挂载了cni-bin-dirvolume。

现象二：Pod 启动成功但无法访问 ClusterIP Service，curl http://10.96.0.1:443超时
→ 原因：kube-ovn-cni未正确配置ovn0网卡的proxy_arp，导致 Service 的 ClusterIP（如10.96.0.1）ARP 请求无响应。
→ 解决：sysctl -w net.ipv4.conf.ovn0.proxy_arp=1；永久生效：echo "net.ipv4.conf.ovn0.proxy_arp = 1" >> /etc/sysctl.conf && sysctl -p。

现象三：启用 QoS 后，Pod 网络完全中断，ping全丢
→ 原因：tcqdisc 配置错误导致veth设备异常。最常见是ingress_rate设置过低（如1kbit），触发 Linux 内核的qdisc错误处理机制，使整个设备停摆。
→ 解决：tc qdisc show dev vethYYY查看当前 qdisc；若输出异常（如qdisc noqueue），执行tc qdisc del dev vethYYY root清理；重新设置合理值（最小建议100kbit）。

现象四：流量镜像开启后，宿主机eth0收到大量ARP请求，且源 MAC 为00:00:00:00:00:00
→ 原因：OVSmirroraction 在克隆包时未重写源 MAC，导致镜像包的eth_src为零，触发 ARP 泛洪。这是 OVS 2.12 以下版本的已知 bug。
→ 解决：升级 OVS 至 2.13+；或临时禁用镜像功能，改用ovs-appctl ofproto/trace进行单包调试。

4. 控制平面优化：ovn-northd 如何把 Kubernetes 的“松散事件”编译成 OVN 的“确定性流表”？

OVN 的 northbound DB（ovn-nb）是一个高度抽象的逻辑网络描述，而 southbound DB（ovn-sb）则是可执行的分布式流表。ovn-northd就是连接两者的“编译器”——它持续监听 ovn-nb 的变更，将其翻译为 ovn-sb 中的logical_flow。Kube-OVN 的性能优势，一半来自kube-ovn-controller的轻量设计，另一半正来自它对ovn-northd编译过程的深度干预。

4.1 流表裁剪：为什么 Kube-OVN 的 ovn-sb 流表数量比原生 OVN 少 40%？

原生 OVN 为兼容 OpenStack Neutron，生成大量通用流表（如lr_in_dnat、lr_out_snat），即使集群未启用 DNAT/SNAT 功能，这些流表仍存在并参与匹配。Kube-OVN 通过--enable-ovn-northd-optimization参数，在ovn-northd启动时注入定制化编译规则：

• 条件编译：若Subnet.spec.natOutgoing == false，则跳过生成lr_out_snat相关流表；
• 合并匹配：将多个acl规则中相同的match字段（如ip4.src == 10.16.0.0/16）合并为一条流表，用reg0寄存器标记动作；
• 删除冗余：移除所有priority=0的默认drop流表，改由kube-ovn-controller在创建 ACL 时显式插入priority=1000的drop规则。

效果显著：在 1000 节点、5000 Pod 的集群中，原生 OVN 的ovn-sb流表数约 12000 条，而 Kube-OVN 仅为 7200 条。流表越少，ovn-controller下发到各节点的增量同步越快，ovs-vswitchd的流表匹配延迟越低。

4.2 缓存机制：kube-ovn-controller 如何用三层缓存对抗 Kubernetes API Server 的抖动？

Kubernetes API Server 在高负载下可能出现timeout或503，若kube-ovn-controller每次都实时查询，会导致网络配置延迟飙升。Kube-OVN 构建了三层缓存体系：

最关键的优化在 Level 2：kube-ovn-controller不直接调用ovn-nbctl，而是维护一个map[string]*nbdb.LogicalSwitch结构体缓存。当需要检查某个logical_port是否存在时，先查 cache；若 miss，则批量拉取ovn-nb中所有logical_port并更新 cache。这使得在 5000 Pod 场景下，ovn-nbctl调用次数从每秒 200+ 降至平均 3 次/分钟。

4.3 集中式网关的流表真相：为什么它能让 Pod 出向流量“固定走某台节点”？

集中式网关（Centralized Gateway）是 Kube-OVN 的标志性功能。它的实现并非在某台节点上部署一个“网关 Pod”，而是通过 OVN 的logical_router+chassis绑定机制：

1. 用户在SubnetCRD 中设置gatewayType: centralized和gatewayNode: node-01；
2. kube-ovn-controller在ovn-nb中为该 Subnet 创建logical_router_port，并设置options:redirect-chassis="node-01"；
3. ovn-northd编译时，为所有匹配该 Subnet CIDR 的出向流量生成lr_out_snat流表，其actions字段包含redirect-chassis("node-01")；
4. ovn-controller在node-01上下发该流表，其他节点则下发drop。

这意味着：当 Pod A（在 node-02）访问外网时，数据包先到达node-02的br-int，匹配lr_out_snat流表后，被redirect-chassis动作强制转发到node-01的br-int，再由node-01执行 SNAT 和出网。整个过程对 Pod 透明，且redirect-chassis是 OVN 原生特性，无额外封装开销。

4.4 避坑：ovn-northd 高 CPU 占用的三大根源

ovn-northd是纯用户态进程，但 CPU 占用过高会拖慢整个控制平面。以下是典型场景：

现象一：ovn-northdCPU 持续 90%+，ovn-sb流表数正常（<10000）
→ 原因：ovn-northd的--run-timeout参数过小（默认 30 秒），导致其频繁重启并重载 DB，引发 CPU 尖峰。
→ 解决：在ovn-centralDeployment 中添加--run-timeout=300（5 分钟）。

现象二：ovn-northd日志反复打印could not find chassis for logical port xxx
→ 原因：某节点ovn-controller崩溃或网络中断，ovn-sb中该节点的chassis记录未及时清理，ovn-northd持续尝试匹配失败。
→ 解决：ovn-sbctl list chassis查看所有 chassis；手动删除失效节点：ovn-sbctl destroy chassis <uuid>。

现象三：ovn-northd启动后立即 OOM Killed
→ 原因：ovn-nbDB 过大（>50MB），ovn-northd加载时内存暴涨。常见于未清理历史logical_port（如kubectl delete po --all后未删 OVN 端口）。
→ 解决：ovn-nbctl --db=tcp://127.0.0.1:6641 purge清理；长期启用--db-limit=20000000（20MB）。

5. 生产就绪的边界：从 LoadBalancer 到 EIP，Kube-OVN 如何用 VPC 网关复用实现企业级网络暴露？

Kube-OVN 的LoadBalancer类型 Service 并非像 MetalLB 那样通过 BGP/ARP 宣告 IP，而是复用其 VPC 网关能力，构建了一条“Service → VPC Gateway → 物理网络”的暴露链路。这种设计牺牲了部分灵活性（如不支持任意 IP），但换来了与企业现有网络架构的无缝集成——你可以把LoadBalancer的 IP 直接加入防火墙白名单，因为它的出向 IP 就是物理网关的 IP。

5.1 LoadBalancer Service 的四层编译：从 Service 对象到 VPC Gateway 的 NAT 规则

当用户创建type: LoadBalancer的 Service 时，kube-ovn-controller的处理流程如下：

1. Service 类型识别：检测spec.type == "LoadBalancer"且status.loadBalancer.ingress为空（即未被外部 LB 分配 IP）；
2. EIP 分配：从IPPool或Subnet中分配一个外部可达 IP（如203.0.113.10），并创建EIPCRD；
3. VPC Gateway 绑定：将该 EIP 绑定到defaultVPC 的vpc-nat-gwDeployment（一个运行在特定节点的 Pod）；
4. OVN NAT 规则生成：在vpc-default的logical_router上添加两条规则：
   • dnat_and_snat：external_ip=203.0.113.10, logical_ip=10.96.1.100, type=dnat_and_snat（DNAT 到 ClusterIP）
   • snat：external_ip=203.0.113.10, logical_ip=10.16.0.0/16, type=snat（SNAT 出向流量）

关键点在于：vpc-nat-gwPod 并非传统意义上的“网关”，它只是一个hostNetwork: true的容器，其作用仅仅是持有203.0.113.10这个 IP 并运行keepalived实现 VIP 高可用。真正的 DNAT/SNAT 由 OVN 的logical_router完成，vpc-nat-gw只负责接收203.0.113.10的 ARP 响应和初始连接。

5.2 EIP 与 SNAT 的协同：为什么同一个 IP 既能做 DNAT 又能做 SNAT？

EIP（Elastic IP）在 Kube-OVN 中是一个 CRD，其核心字段为spec.v4Ip和spec.vpc。当它被绑定到 VPC 后，kube-ovn-controller会同时创建dnat_and_snat

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