共计 3258 个字符，预计需要花费 9 分钟才能阅读完成。
这篇文章主要介绍“怎么跨过 Docker 集群网络 Weave 遇到的坑”，在日常操作中，相信很多人在怎么跨过 Docker 集群网络 Weave 遇到的坑问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么跨过 Docker 集群网络 Weave 遇到的坑”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
前 言
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-
skb- sp = NULL;
#endif}
（图 4：内核版本不同造成设置不同）
虽然新的内核版本中存在该问题，不过内核本身没有问题，还是 Weave 用户态管理 datapath 程序与内核适配上出现问题 (它并不是使用 ovs-switchd），在 OVS 中对 tunnel 类型可以设置为 df_default=false 进行分片。
解决方法
保证接口的 MTU 值为默认为 1500。
到此，关于“怎么跨过 Docker 集群网络 Weave 遇到的坑”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
