社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
对Linux网络一直不太清晰，整理一下最近的一个案例。
所有实机（包括宿主）、虚机、容器都至少有两个IP，数据网IP和业务网IP。部分机器有多个IP，分别位于不同的vlan。接手了一坨机器，包括KVM宿主和docker宿主。虚机和容器都是通过Linux内核网桥与其他机器交换。其中KVM的宿主敲定用macvtap+vhost的模式升级，解决大量小包时的性能下降问题。
docker的宿主情况复杂一些。每个容器有4个网卡，数据网卡、业务网卡、HAvlan网卡、还有一个备用网卡。分别桥接到dockerbr0-3上，docker网络模式是none。容器内数据网业务网的IP和路由都是容器start后，通过entrypoint在添加网卡和路由配置文件。HA IP和路由是后添加的，通过docker exec配置HA网卡。宿主网络：
容器有4个网卡，宿主两个物理网卡，一个vlan网卡，vlanid 255。
随着规模扩张，需要增加多个HA vlan，vlanid（255-455），每个容器还是只有一个HAIP。由于之前的设计的升级方案是：增加一个havlan，对应创建一个新docker bridge，容器也增加一个网卡。当时这样设计的原因不太清楚了，可能是1、没想到vlan增长这么快，按原来的速度，两个vlan能cover两年；2，方便统一管理，启停一致，逻辑简单；3，主要还是因为拿不到IP管理权限，docker管理平台不知道容器的haip是什么，在哪个vlan。不管什么原因，总之现状很明显，原有升级方案不适合当前需求。
原有的方案不能满足需求，由于非技术原因（主要是安全和权限），我们也不能绑定容器与ha网桥，只能在宿主内寻求解决方案。
第一种方案，宿主网络环境不变，dockerbr0和dockerbr1分别作为数据网和业务网，dockerbr2和dockerbr3不再工作，通过容器内做vlan网卡的方式划分vlan。这个方案的优点是规范，宿主网桥只做转发，不再处理vlan tag，vlan之间严格隔离。缺点是需要修改haip配置的逻辑，需要考虑兼容升级。
第二种方案，修改宿主网络，dockerbr0和dockerbr1分别作为数据网和业务网不变，将宿主所有ha vlan网卡绑定到dockerbr2。这个方案的优势是除了宿主配置做一些更新，不需要修改任何线上逻辑。缺点是任何vlan的广播包都会在dockerbr2内传播到其他vlan。一般情况下没有影响，但是当一个vlan存在广播风暴时都会影响到所有vlan。
像图中，如果宿主网卡收到一个451的广播包，会交给eth0.451解tag，转发到bridge。由于是广播包，bridge会把包复制到每个端口，包括eth0.455。eth0.455会把广播包打上455的tag，转发到vlan 455。最终导致vlan455收到vlan451的广播包。
运维不会冒险。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
