内核缺陷触发的NodePort服务63秒延迟问题

我们有一个新创建的TKE 1.3.0集群，使用基于Galaxy + Flannel（VXLAN模式）的容器网络，集群由三个二层互通的Master节点 10.0.0.11、 10.0.0.12、 10.0.0.13组成。在访问宿主机端口为 30153的NodePort类型的Service时，出现了很有趣的现象：

1. 在节点 10.0.0.11、 10.0.0.13节点上 curl http://localhost:30153，有50%几率卡住
2. 在节点 10.0.0.12上 curl http://localhost:30153，100%几率卡住
3. 从集群内部，访问非本节点的30153端口，畅通
4. 从集群外部，访问任意节点的30153端口，畅通

三个节点本身并无差异，卡住几率不同，可能和服务的端点（Endpoint，即Pod）的分布情况有关。

NodePort服务的定义如下：

该服务的端点有两个：

可以看到，端点在10.0.0.11、10.0.0.13上分别有一个。假设容器网络存在问题，只能访问本机的Pod，则能解释前面的卡住现象 —— 10.0.0.12上没有端点，因此一直卡住。10.0.0.11、10.0.0.13分别占有50%端点，因此50%几率卡住。

但是，我们在任意节点直接访问Pod，发现都是畅通的：

这说明故障和容器网络没有直接关系。 

我们在10.0.0.11向localhost:30153发起请求，并且抓取卡住时的封包：

可以注意到：

1. 当Service负载均衡到本机的Pod时畅通，负载均衡到其它节点的Pod时卡住。这就是50%卡住的原因
2. 并非彻底卡死，在63秒后，SYN成功

从上面的抓包结果分析，我们初步判断故障和iptables没有关系。iptables导致的问题可能是无限卡死直到超时（静默的丢弃了报文）、ICMP错误、TCP RST等，通常不会出现过了一段时间自动恢复的情况。

然后，这个故障很特别，它的确是由iptables规则所触发的。我们是后来查找资料才发现的这一事实，这里先列出相关的规则。其中PREROUTING阶段的规则如下：

我们可以看到，如果服务端点不在本机，发往localhost:30153的封包，会被先打上0x4000标记，然后DNAT到服务端点的IP:PORT（例如172.29.2.3:9153），这会保证封包从flannel.1发出。

POSTROUTING阶段的规则如下：

可以看到，这里做了SNAT，任何具有0x4000标记的封包，都被SNAT，确保使用flannel.1的地址作为源IP。

经过反复测试， 发现卡住时，总是会消耗63秒左右，然后接收到响应。

63秒这个数字，和TCP默认的SYN重试机制有关。SYN如果没有收到ACK，发送端会自动重发SYN，每次重试的延迟时间指数增长，依次为1, 2, 4, 8, 16, 32，这会引发合计63秒的总延迟。

令人费解的是，为什么63秒之后，不是超时，而是连接成功？

从上文抓取的TCP封包看，服务端的Pod网卡没有收到前面6次SYN，这些封包应该在链路的某个位置被丢弃了。

在VXLAN模式下，上面抓的TCP封包，会封装在UDP报文中，并通过节点物理网卡的8472端口发出。我们从外层报文的角度分析一下

可以看到，请求端/服务端的UDP报文相互呼应， 至少可以说，请求端的全部报文都送到了服务端。

但是，前面5次重试的UDP报文都被标注了bad udp cksum，最后一次UDP报文没有chksum，连接成功建立。有理由怀疑，故障和chksum有关系。

通过查阅VXLAN的RFC，在VXLAN Frame Format一章中，关于UDP封包的Checksum，具有如下说明：

UDP Checksum应该以零传递。接收端接收到零Checksum的UDP包后，它必须接受，用于解包（decapsulation）。但是，如果发送端的确提供了非零Checksum，那么它必须是正确的、基于整个封包进行计算的 —— 包括IP头、UDP头、VXLAN头，以及最里层的MAC帧。接收端可以对非零Checksum进行校验，或者不去校验。但是，如果进行了校验，且校验结果不正确，则必须丢弃UDP封包

RFC说的很明确，如果Checksum是错误的，并且进行了校验，则封包会被丢弃。带入我们的场景中，可以推测，服务端内核丢弃了那些bad udp cksum的封包，因而服务端的Pod网卡一直没有收到SYN。

那么，Checksum为什么会错了呢？根源应该在内核。

现代操作系统都支持某些形式的Network Offloading，将某些工作委托给网卡完成，从而减轻CPU的负担。从内核代码的演变情况来看，这种Offloading的种类越来越丰富。

Checksum就可以Offload给网卡来完成，这样，IP、TCP和UDP的Checksum，会在报文即将从网络接口发送出去的时候进行计算。Offloading需要内核的TCP/IP栈、设备驱动、硬件正确的配合才能完成。

通过查阅资料，我们了解到，内核中存在一个和VXLAN处理有关的缺陷，该缺陷会导致Checksum Offloading不能正确完成。这个缺陷仅仅在很边缘的场景下才会表现出来。

在VXLAN的UDP头被NAT过（见下文的二次SNAT问题）的前提下，如果：

1. VXLAN设备禁用（这是RFC的建议）了UDP Checksum
2. VXLAN设备启用了Tx Checksum Offloading

就会导致生成错误的UDP Checksum。

前面提到内核缺陷必须在VXLAN的UDP封包被NAT时，才会触发。那么，在源、目标地址都是宿主机网段的情况下，为什么还对UDP封包进行NAT呢？

在上文的iptables分析中我们看到，访问localhost:30153的封包，会被：

1. DNAT到服务端Pod的地址，这保证封包能够通过flannel.1发出
2. 打上0x4000标记，这个标记会在随后的POSTROUTING阶段，用于进行SNAT。使用flannel.1的地址作为源地址

被DNAT+SNAT后的内层TCP报文，进入flannel.1接口，进而在内核的VXLAN驱动中处理，封装为UDP报文。需要注意，iptables打标记，我们期望是针对内层报文的。然而，内层封包被VXLAN处理后包裹了外层UDP，重新进入网络栈，内核自动将0x4000标记关联到外层UDP报文上，这导致了额外的一次SNAT：

在Kubernetes 1.16.0之前的版本，Kube Proxy做SNAT（ -j MASQUERADE）时，没有使用 --random-fully参数。这意味着第二次SNAT不会有任何效果，因为内核会在Masquerading时尝试保持源端口不变，与此同时，源端口已经是期望的地址了。

但是，使用了--random-fully参数后，情况变得不同。该参数会强制的进行随机的源端口映射。这就触发了上文提到的内核缺陷。

这是SNAT目标的一个参数，它会使用伪随机数生成器，自动产生一个端口，来替换NAT前的端口。根据文档，它需要内核3.14+才能支持。

然而，我们用的是CentOS 7，内核版本是 3.10.0-1127.13.1.el7.x86_64，照理说应该不支持这个特性。

在宿主机上，用iptables-save导出规则，也是看不到--random-fully的。但是，从Kube Proxy容器里面导出规则，却能看见：

原因可能是两个iptables的版本不同。有一点可以明确，--random-fully在我们的环境下的确产生了影响，因为禁用该参数后，问题就消失了。

既然故障的根源是内核中，和Offloading有关的缺陷，因此，禁用Offloading是最直接的手段：

这个命令执行的时机很重要，如果主机重启，Flannel创建网卡后，才能执行该命令，否则会提示找不到设备。

有两种方式防止对VXLAN的UDP封包进行SNAT。第一种是禁用--random-fully参数。这种做法印证了上文关于此参数的猜测。

第二种，将发往8472端口的UDP封包，做一个重置标记的操作。Kubernetes社区就是这种做法。

查看Kubernetes v1.18.5的Changelog，可以发现PR 92035修复了这个故障。这个PR会在不需要0x4000标记时，将其清除。

在Kubelet初始化期间，会在NAT表创建KUBE-MARK-MASQ、KUBE-MARK-DROP、KUBE-POSTROUTING等链，并添加一些规则。该PR对这部分的逻辑进行了修改：

此外，该PR还对Kube Proxy的iptables/ipvs相关模块进行了类似修改，这里就不张贴代码了。

已知内核版本5.6.13, 5.4.41, 4.19.123, 4.14.181修复了上文提到的内核缺陷，但是CentOS 7何时修复未知，可能需要自行Patch。

所谓Checksum是一个固定长度的字段，网络协议使用该字段来纠正某些传输错误。

Checksum通常是基于某些报文字段来计算摘要信息，算法决定了Checksum的可靠性和计算成本。IP协议仅仅使用报文头，而大部分L4协议，同时使用报文头、报文体。

在IPv4（IPV6没有IP Checksum）中，IP Checksum是16bit字段，信息来自IP头所有字段。在任一跳发现Checksum错误，都会导致静默的丢弃，而不产生ICMP报文 —— L4协议需要考虑这种静默丢弃的可能并进行相应处理，例如TCP在ACK没有及时收到时会进行重传。

IP数据报在经过每一跳时，都需要更新Checksum，至少TTL的变化需要重新计算Checksum。除了TTL，IP头还可能因为以下原因变化：

1. NAT导致的地址变化
2. IP选项处理
3. IP分片

计算IP Checksum时，报文被分隔为16bit的小段，将这些小段相加并取反（ones-complemented），就得到最后的Checksum。在Linux中，可能分隔为32bit甚至64bit的小段，以提升计算速度，但是取反操作前需要一个额外的折叠（csum_fold）操作。

由于IP Checksum仅仅牵涉到报文头，成本很低，Linux总是在CPU中进行计算，不会Offload给硬件。

L4协议的Checksum牵涉完整报文，包括L4报文头、L4报文体、以及所谓的伪头（pseudoheader）。伪头其实就是IP头中的源地址、目的地址、以及之后的32bit。

IP层在NAT等场景下，需要对IP头进行变更，这会导致L4协议计算的Checksum失效。如果没有更新失效的Checksum，则在IP报文传输的每一跳都不会发现错误，因为中间路由仅仅会校验IP Checksum。结果就是，只有目的地内核才能在L4发现这一情况。我们可以了解到Checksum算法具有可逆性，因此NAT这样导致很少字段变化的情况下，更新Checksum不需要从头计算。

前面提到过，L4的Checksum计算涉及完整报文，成本较高。因此Linux支持将L4的Checksum委托给硬件完成，这就是Checksum Offloading。

设备能否支持Checksum Offloading，是通过 net_device->features标记传递给内核的：

1. NETIF_F_HW_CSUM 驱动能够为任何协议组合、协议层计算IP Checksum
2. NETIF_F_IP_CSUM 驱动支持L4（仅限于TCP/UDP over IPv4）的Checksum计算
3. NETIF_F_IPV6_CSUM 驱动支持L4（仅限于TCP/UDP over IPv6）的Checksum计算
4. NETIF_F_NO_CSUM 表示设备明确知道不需要计算Checksum，通常用于loopback设备
5. NETIF_F_RXCSUM  驱动进行接收封包的Checksum Offloading，仅仅用于禁用设备的RX Checksum

skb->ip_summed字段存放了Checksum的状态，其含义在接收封包、发送封包期间有所不同。

在接收封包期间：

1. CHECKSUM_NONE 提示设备没有对封包进行Checksum校验，可能由于缺少相关特性
2. CHECKSUM_UNNECESSARY 提示内核不再需要对Checksum进行校验
3. CHECKSUM_COMPLETE 提示设备已经提供了完整的L4 Checksum，L4代码只需要加上伪头即可进行校验

在发送封包期间：

1. CHECKSUM_NONE 提示内核已经完全处理好Checksum了，设备不需要做任何事情
2. CHECKSUM_UNNECESSARY 意义和CHECKSUM_NONE相同
3. CHECKSUM_PARTIAL  提示内核已经完成伪头部分的Checksum，驱动必须计算从 skb->csum_start到封包结尾部分的Checksum，并且将其存放在 skb->csum_start + skb->csum_offset这个位置
4. CHECKSUM_COMPLETE  不使用

可以看到，在发送封包时，如果skb->ip_summed的值为CHECKSUM_PARTIAL，则意味着内核要求驱动Checksum Offloading。

基于上面的认识，我们可以看一下本文牵涉到的内核缺陷到底是什么了：

当VXLAN端点的UDP被NAT的情况下，上述代码会执行。如果 VXLAN设备禁用了UDP Checksum，它会将udphdr->check置零。如果同时VXLAN设备还启用了Tx Checksum Offloading，skb->ip_summed的值就会是CHECKSUM_PARTIAL。这就是我们环境下的配置。

UDP Checksum被禁用情况下，udphdr->check是个零值，显然没有包含旧的伪头的Checksum信息，因为通过伪头计算的Checksum，至少协议类型部分（UDP 0x11）是非零。

因此，判断是否需要更新Checksum，应当只VXLAN接口是否禁用了UDP Checksum，禁用了就不应该更新。

1. TCP offloading on VXLAN.calico adaptor causing 63 second delays in VXLAN communications node->nodeport or node->clusterip:port
2. netfilter: nat: never update the UDP checksum when it's 0
3. kubelet, kube-proxy: unmark packets before masquerading them