这篇文章主要介绍“怎么跨过Docker集群网络Weave遇到的坑”，在日常操作中，相信很多人在怎么跨过Docker集群网络Weave遇到的坑问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么跨过Docker集群网络Weave遇到的坑”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
专注于为中小企业提供网站制作、做网站服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业定结免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了上千余家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
前 言
Weave作为Docker（一个开源的应用容器引擎）跨主机集群网络解决方案的一种，可以用于连接部署在多台主机上的Docker容器，使用网络的应用程序不必去配置端口映射、链接等信息。另外，Weave的通信支持加密，用户可以从一个不受信任的网络连接到主机。
Weave在控制层和Calico类似，在数据层通过UDP封装实现L2 overlay。Weave在1.2 版本之前都是通过usersapce实现，在Weave-1.2版本之后，Weave结合了内核Open vSwitch模块，实现了Open vSwitch datapath（ODP）功能，结合kernel的vxlan特性，在网络性能上有较大提升。
由于ODP功能与内核相关模块结合较为紧密，因此在实际使用中可能会遇到一些与内核相关的“坑”。本文描述的这两个问题都跟内核有关系。
坑一：使用Weave FastDb造成网络中断
问题描述
在Weave的1.2版本之后，考虑到原先sleeve模式网络性能较差，故增加FastDb模式，该模式也成为Weave启动时的默认模式。在FastDb模式中使用了kernel中的Open vSwitch模块，做报文封装时使用vxlan协议。在使用qemu-kvm创建的云主机上，如果安装CentOS7.0，内核版本为kernel-3.10.123，那么在启动Weave并使用FastDb模式时，会造成virtio_net虚拟网卡无法发送数据，进而导致整个虚拟机的网络中断。
问题分析
导致网络断开的原因是由于触发了内核的一个bug，该内核bug的commit链接地址http://t.cn/Ro53BsH。
触发该bug主要是因为Weave在初始化时会发送一个60000字节的UDP数据包进行PMTU探测，并且 Weave发送使用的套接字为raw socket，导致virtio_net使用的内存被污染，具体表现就是无法通知到宿主机上vhost获取数据，在接口上看到发送报文的计数始终不会增加。
该问题不是只有Weave才能触发，用普通应用程序建立socket时使用raw socket,并且发送的数据大于接口的MTU值，接口的UFO功能是打开的，这些情况下都极有可能触发该问题，造成网络中断。
（图1：FastDb模式的数据流原理）
解决方法
1、升级内核，保证内核版本大于等于3.13；
2、关闭虚拟机网卡的ufo特性；
3、CentOS7.1的kernel-3.10.229内核已经修复了该问题。
（图2：guest通知vhost读取数据流程）
坑二：Weave无法使用FastDb模式
问题描述
在内核版本CentOS Linux (3.10.0-327.10.1.el7.x86_64) 7 (Core)上 ，Weave版本大于1.2，如果云主机的MTU值为1450或者小于1474，Weave启动时无法正常选择Fast Data Path模式。在Weave启动后一直选择sleeve模式，本应该默认模式为FastDb，该问题也和内核的版本相关。
问题分析
Weave的Fast Data Path路径使用到ODP技术，也就是内核中的OVS模块，在Container中直接发送数据包到ovs模块。在启动Weave时，会自动选择使用sleeve模式还是FastDb模式，这里通过发送心跳包来决定。出现该问题时，在云主机通过Docker logs Weave日志可以看到出错信息："FastDb timed out waiting for vxlan heartbeat"。
heartbeat数据包是一个UDP包，目的端口号为6784，在某些云主机上接口的MTU值为1454，但在发送UDP的heartbeat数据包时，发送的是1474字节，这样就会对报文在IP层进行分片，而在主机上发现心跳报文发送不出去，当MTU的值修改为1500后，就可以发送出去。
在MTU为1454的情况下，会出现下面的ICMP错误报文：
（图3: 出现的错误ICMP报文）
上面出现错误的ICMP报文是内核中的ip_fragment函数调用ICMP_send函数发送的：
if (unlikely(((iph->frag_off & htons(IP_DF)) && !skb->ignore_df) ||
(IPCB(skb)->frag_max_size &&
IPCB(skb)->frag_max_size > mtu))) {
IP_INC_STATS(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
ICMP_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
htonl(mtu));
kfree_skb(skb);
return -EMSGSIZE;}
通过上述代码可以看出，如果出现错误ICMP报文，下面的判断条件iph->frag_off & htons(IP_DF)) && !skb->ignore_df 需要成立。通过对抓取的报文分析可知iph->frag_off & htons(IP_DF))的值为真，那么skb->ignore_df值需要为0，而此处的关键在于skb->ignore_df的值是何时赋值为0的。
通过分析Weave发送心跳包的流程可知，在vxlan_tnl_send函数中，对skb->ignore_df赋值为1，最后调用tunnel的发送函数iptunnel_xmit时，调用了skb_scrub_packet函数，在该函数中又重新对skb->ignore_df赋值为0（kernel版本为：3.10.0-327.el7），造成后续发送报文时，ICMP目的不可达，并且错误码为ICMP_FRAG_NEEDED的报文。
void skb_scrub_packet(struct sk_buff *skb, bool xnet){
skb->tstamp.tv64 = 0;
skb->pkt_type = PACKET_HOST;
skb->skb_iif = 0;
skb->ignore_df = 0;
skb_dst_drop(skb);
secpath_reset(skb);
nf_reset(skb);
nf_reset_trace(skb);
if (!xnet)
return;
skb_orphan(skb);
skb->mark = 0;
}
上面代码是CentOS7的3.10.0-327.el7，而在一些旧内核版本3.10.0-123.el7上，iptunnel_xmit调用的是secpath_reset(skb)函数，该函数并没有对skb->local_df（低版本内核使用local_df）进行重新初始化，也就是skb->local_df值仍旧为1，因此在该版本上不会出现上述问题。
static inline void
secpath_reset(struct sk_buff *skb){
#ifdef CONFIG_XFRM
secpath_put(skb->sp);
skb->sp = NULL;
#endif}
（图4：内核版本不同造成设置不同）
虽然新的内核版本中存在该问题，不过内核本身没有问题，还是Weave用户态管理datapath程序与内核适配上出现问题(它并不是使用ovs-switchd），在OVS中对tunnel类型可以设置为df_default=false进行分片。
解决方法
保证接口的MTU值为默认为1500。
到此，关于“怎么跨过Docker集群网络Weave遇到的坑”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
