混搭容器造成在线Redis事故问题是，现在有一个redis3.0的集群节点，是部署在bareredis或者host网络模式下的容器redis（基本和bareredis差不多），需要将它们换成macvlan网络模式的redis容器来展示我们的dockerizedredis集群很高档。这件事几个月前做过一次，没有任何压力。然而，这次却出了问题。（这个脚本是错误的！）于是开始在上面提到的redis集群中添加两个macvlan容器作为slave节点，打算后面用failover替换master。大概十多分钟后，群里炸了，说是取不到数据，或者格式不对。。。上线后发现原来在添加slave节点的集群连接到了另外一个集群。集群的节点混合在一起。这里先说说redis集群协议。两个服务正常的集群可以直接通过一个clustermeet合并成一个cluster，然后slot分配就乱了。。。首先当然是应急恢复线业务，先拉一个新的cluster出来（幸好，该集群的数据不需要持久化）。结果新的集群刚出来，又被合并到上面的集群中。（这时候满脑子都是某个科教片两个星系合并的视频，满天都是爆炸！（脑洞大开然后集群节点，发现里面几个节点的地址cluster已经改成了172.17.x.x，应该是docker的内部网段地址，所以响应，可能是docker网络配置有问题，握手流量发错了节点，然后把那些节点合并了这时候来不及新建网段了（我也给@小六哦啦啦先生打了个电话。。。）换个思路，把新的redis部署到另一个端口上，形成一个集群，观察了一会，这个方法奏效了-.-!!恢复了，被炸飞了跳进线上业务，开始排查问题，线索是看到的172.17.x.x网段clusternodesbefore.testconfirmedit.从docker容器连接到hostmachine，主机接受将获得172.17。地址x.x.而容器中的路由表是这样的。确实，如果宿主机的IP是10.100.1.100，那么流量走的是eth0，也就是172.17.x.x网卡。（10.222.0.0/16是容器的macvlan地址）然后才明白172.17.x.x的网卡地址在不同的物理机上可能是一样的。也就是说，遇到的问题可能是以下过程引起的。四个redis#a#b#c#d#a#b是两个主机网络的redis，在同一个集群中，#d是macvlan部署的redis，在另一个集群中#c是空闲的redis，这就发生了拥有与#d相同的eth0地址#c通过eth0向#a发送握手#a确认，此时，它认为#c的地址为172.17.0.55#a向#b广播新的节点地址#b向172.17.0.55发送握手请求，然而，这个地址在它对应的机器上是#d，然后两个集群就混在一起了。这也解释了为什么几个月前这样做时没有问题。应该庆幸当时没有同地址的集装箱；这也解释了我想知道为什么不是每个纯macvlan模式的redis集群都被枪杀。后来在测试机房找了两个网卡一模一样的容器，按照上面的思路搭建集群，再次尝试。不要这样混搭Bypass：端口号不一样如何更改默认路由：默认使用vlan网卡，但是这样的话就不能访问外网了，这对于redis来说是没有问题的，但其他业务可能不行添加路由：其实可以在容器中添加一条路由10.100.0.0/16，经过vlan，宿主机接受到的地址将是最佳vlan网络的地址卡在电脑房。此方案@CMGS正在评估中EOF原文链接：http://m.douban.com/note/520415058/?bid=Mk5VloIg3M8&from=groupmessage&isappinstalled=0&ADUIN=187366795&ADSESSION=1444702325&ADTAG=CLIENT.QQ.5431_.0&ADPUBNO=26497
