Tunnel与Route两条网络路线的取舍，及为什么选择相对冷门的MacVLAN

容器网络方案大体可以分成隧道类（Tunnel，如Weave、OVS）和路由类（Route，如MacVLAN、Calico）两条路线，两者各有明确的短板。隧道方案的灵活度更高（不依赖物理网络拓扑），但会带来两个实际问题：一是性能损耗，比如Weave通过UDP封装数据包再广播给其他节点，封包解包的过程本身就有开销，大多数OVS方案实测会影响20%~30%的吞吐性能，严重到有的公司为此专门上了FPGA硬件加速；二是调试困难，隧道的灵活性建立在主机间的隧道封装之上，一旦出问题，很难快速判断故障究竟出在底层物理链路还是隧道封装本身这一层。路由方案虽然性能更好，但也有自己的代价：需要在Container Host上运行高权限进程去Hook系统API；因为依赖物理链路，在公有云上想给同类容器开辟新子网做二层隔离基本做不到；如果是基于BGP的Calico这类方案，路由信息的生效时间差也可能给容器应用之间的状态同步带来问题。权衡下来，团队选择了路由方案里理解和逻辑上相对最简单的MacVLAN——虽然这个方案在业界不算热门，但换来了几个实打实的好处：因为网络栈完全独立，可以很容易在二层直接做基于IP的QoS限流控制，不需要像其他方案那样依赖tc甚至修改内核去实现限流（改内核意味着要长期自行维护这份改动）；性能上比Weave这类隧道方案表现好得多；二层隔离本身也带来了额外的安全性。这个案例给出的选型经验是：面对多个都有明显缺陷的候选方案，与其寻找一个”完美无缺”的方案（往往不存在），不如清楚列出每条技术路线各自的代价，再结合自己团队实际能承受哪类代价（是能接受维护高权限Hook进程和公有云限制，还是能接受隧道带来的性能损耗和调试难度）来做取舍，”简单、理解成本低”本身也是一项值得纳入权衡的重要维度，而不只是看功能是否强大。