3、OVS高级特性：OpenFlow流表、QoS限速、VLAN隔离、隧道封装（Geneve/VXLAN）
好，咱们进入第三讲。前面两章我们把OVS的基本架构和安装部署聊透了，这一章，我带你看看OVS真正硬核的地方——那些在生产环境中能帮你解决实际问题的“高级特性”。
说实话，很多刚接触OVS的朋友，觉得它就是个“高级点的Linux Bridge”。嗯，这么理解也没错，但只对了一半。OVS真正的灵魂，在于它可编程的数据平面。说白了，就是你能通过OpenFlow流表，像写程序一样控制网络包的走向。这感觉，就像从手动挡换到了自动驾驶，爽快感完全不一样。
3.1 OpenFlow流表：网络包的“交通指挥员”
OpenFlow是什么？你可以把它想象成给交换机下发指令的“遥控器”。传统交换机，转发逻辑是固化在硬件里的，你改不了。但OVS不一样，它把转发决策权交给你了。你写规则，它执行。
每条流表规则，本质上就是一个“if-then”语句：如果匹配到某个条件，那么执行某个动作。
核心概念：流表由多条流表项组成。每条流表项包含：匹配字段（Match Fields）、优先级（Priority）、计数器（Counters）、指令（Instructions）和超时时间（Timeouts）。
我在项目中遇到过最典型的场景，就是做精细化流量调度。比如，我想让来自某个Pod的流量，强制走特定的出口网卡。用iptables也能做，但维护起来简直是噩梦。用OpenFlow，几行命令就搞定了。
来看个例子，让来自源IP 10.0.0.1的流量，全部丢弃：
ovs-ofctl add-flow br0 "priority=100,ip,nw_src=10.0.0.1,actions=drop"简单吧？但别小看这条命令。它背后是OVS在数据路径里插入了一条快速匹配规则。你想想看，如果这个流量是恶意攻击流量，你只需要在控制平面下发一条流表，数据平面就能立刻生效，这比在宿主机上写一堆复杂规则要优雅得多。
我个人习惯，在调试网络问题时，先用 ovs-ofctl dump-flows br0 看看当前流表状态。这能帮你快速定位问题——到底是流量没匹配上，还是匹配后执行了错误的动作。
小技巧：流表匹配是“最长前缀匹配”原则。优先级越高，越先匹配。如果两条规则优先级相同，则匹配更具体的那个。我曾经因为优先级设置错误，导致一条本该生效的规则被另一条更宽泛的规则覆盖了，排查了半天。嗯，血的教训。
3.2 QoS限速：别让“吵闹的邻居”影响你
在Kubernetes集群里，多租户场景下，最怕什么？怕某个Pod疯狂占带宽，把整个Node的网络打满。这就是经典的“吵闹的邻居”问题。
OVS的QoS功能，就是用来解决这个问题的。它通过流量整形（Traffic Shaping）和策略（Policing）两种方式，来限制某个端口的带宽。
我建议你优先使用Ingress Policing（入方向限速），因为它实现简单，对CPU开销小。配置起来也很直接：
ovs-vsctl set Interface veth0 ingress_policing_rate=10000
ovs-vsctl set Interface veth0 ingress_policing_burst=1000上面这条命令，把veth0接口的入方向带宽限制在了10Mbps（10000 Kbps），突发流量限制在1000 Kb。注意，这里的单位是Kbps，别搞错了。
但如果你需要更精细的控制，比如限制某个特定流的带宽，那就得上QoS队列了。这需要结合OpenFlow流表一起用。
举个例子，我想让来自10.0.0.0/24网段的流量，走一个限速队列：
# 创建QoS和队列
ovs-vsctl set Port eth0 qos=@newqos -- \
--id=@newqos create QoS type=linux-htb other-config:max-rate=1000000 \
queues=0=@q0 -- \
--id=@q0 create Queue other-config:min-rate=100000 other-config:max-rate=500000
# 添加流表，将匹配的流量送入队列0
ovs-ofctl add-flow br0 "priority=100,ip,nw_src=10.0.0.0/24,actions=enqueue:eth0:0"这里我用了HTB（Hierarchical Token Bucket）队列算法，它支持分层限速，非常灵活。你在生产环境中，可以根据业务优先级，给不同租户分配不同的队列。
注意：QoS功能会消耗一定的CPU资源。如果集群规模很大，建议只在关键端口上启用，不要全局开启。我曾经在一个2000节点的集群上，因为误开了所有端口的QoS，导致OVS的CPU使用率飙升到80%。嗯，那天的On-Call体验，记忆犹新。
3.3 VLAN隔离：传统网络与云原生的桥梁
VLAN，这玩意儿在传统网络里已经用了二十年了。但在Kubernetes里，它依然有不可替代的价值。特别是当你需要和外部物理网络打通时，VLAN是最简单、最兼容的方案。
OVS对VLAN的支持非常完善。你可以把OVS的端口配置成Access口或Trunk口。Access口就是打上固定VLAN标签，Trunk口则允许携带多个VLAN的流量通过。
配置一个Access口：
ovs-vsctl add-port br0 vlan10 tag=10 -- set Interface vlan10 type=internal这样，所有从vlan10接口进出的流量，都会被自动打上VLAN 10的标签。在Kubernetes里，我经常用这种方式，把某个Namespace的Pod流量，映射到物理网络的特定VLAN里。
配置Trunk口稍微复杂一点，需要用到trunk参数：
ovs-vsctl add-port br0 eth0 trunks=10,20,30这样，eth0口就能同时承载VLAN 10、20、30的流量。OVS会根据数据包里的VLAN标签，自动进行转发。
我个人经验是，VLAN隔离在混合云场景下特别好用。比如，你的Kubernetes集群需要和机房里的一台老式数据库通信，那台数据库只认VLAN。你只需要在OVS上配好对应的VLAN端口，Pod就能像访问本地服务一样访问它。
避坑指南：我曾经遇到过一个问题，Pod能ping通同VLAN的其他Pod，但就是访问不了外部网络。排查了半天，发现是OVS的VLAN配置和物理交换机的VLAN配置不一致。记住，OVS只是虚拟交换机，它最终还是要和物理网络打交道的。两边的VLAN配置必须完全对齐，否则就会出现“能通但又不完全通”的诡异现象。
3.4 隧道封装：Geneve与VXLAN的抉择
最后，我们聊聊隧道封装。这是Overlay网络的基石。Kubernetes里，Flannel、Calico、Weave这些CNI插件，底层几乎都离不开隧道技术。
OVS支持多种隧道协议，但最常用的就是VXLAN和Geneve。VXLAN是老牌选手，稳定可靠，几乎所有交换机都支持。Geneve是后起之秀，更灵活，支持更多的元数据封装。
配置一个VXLAN隧道：
ovs-vsctl add-port br0 vxlan0 -- set interface vxlan0 type=vxlan options:remote_ip=192.168.1.100 options:key=100这条命令创建了一个VXLAN隧道，对端IP是192.168.1.100，VNI（VXLAN Network Identifier）是100。VNI就是Overlay网络的“VLAN ID”，用来隔离不同的租户网络。
Geneve的配置类似，只是类型换成geneve：
ovs-vsctl add-port br0 geneve0 -- set interface geneve0 type=geneve options:remote_ip=192.168.1.100 options:key=100那么问题来了，生产环境到底选哪个？
我个人的建议是：
- 如果你需要和硬件交换机互通，选VXLAN。因为硬件交换机对VXLAN的解封装支持更成熟。
- 如果你需要传递更多的元数据（比如Pod的标签、安全策略），选Geneve。它的头部更灵活，可以携带TLV（Type-Length-Value）选项。
- 如果你在公有云上跑，优先看云厂商支持什么。比如AWS的VPC就原生支持VXLAN，你用Geneve反而会增加复杂度。
我记得有一次，帮一个客户做跨机房集群互联。他们用了VXLAN，但发现性能始终上不去。后来排查发现，是物理网卡不支持VXLAN的硬件卸载。换成支持Checksum Offloading的网卡后，性能直接翻倍。所以，隧道封装虽然方便，但性能开销是真实存在的。有条件的话，一定要开启硬件卸载。
总结一下：OpenFlow流表给了你控制权，QoS限速保证了公平性，VLAN隔离连接了传统网络，隧道封装构建了Overlay世界。这四个特性，是OVS在Kubernetes CNI领域立足的根本。下一章，我们就要把这些特性串起来，真正动手写一个CNI插件了。
好了，这一章的内容就到这里。有什么问题，欢迎在评论区交流。我们下章见。