查看内核日志 dmesg -T，可以看到文章开头描述的信息：neighbour: arp_cache: neighbor table overflow!
以上实验说明了，不可回收的 ARP 表项打满 ARP 表会让新的表项无法插入，从而网络不通。
4.3 为什么相比 TKE 的全局路由模式和单网卡多 IP 模式，独立网卡模式更容易产生这个问题要回答这个问题，我们先简单看一下 TKE 各网络模式的原理介绍
全局路由模式该网络模式下，每个节点上的容器 IP 是预先分配到节点上的，这些 IP 同属一个子网，且每个节点就是一个小子网。我们知道，ARP 协议是为二层通信服务的，因此，该网络方案中，每个 Pod 的网络命名空间内的 ARP 表最大可能保存了节点上所有其他 Pod 的 ARP 表项，最后节点的 ARP 表项的数量最大即为 节点子网 IP 数的平方，如节点的子网大小是128，则其 ARP 表项最大可能为 127 的平方，约 16000。
共享网卡模式该网络模式下，每个节点会绑定辅助弹性网卡，节点上的 Pod 共享使用该辅助网卡，每个 Pod 内不会做网络包的路由，只会有一条 ARP 表项，实际的路由控制在节点的 default 命名空间内完成。因此，该网络模式下，ARP 缓存表几乎是共享的，又因为网卡只能属于 1 个子网，因此每个节点的 Pod ARP 缓存表只能存储一个子网的 IP-MAC 映射关系，至多数量为各网卡所在子网内 IP 的数量和，如子网是 /22，即含有约 1000 个 ip， 那么 arp 表项也大概有 1000，由于节点网卡配额一般不超过 10，因此该节点的最大 ARP 表项一般不超过 10000。
下一代网络方案——独立网卡模式独立网卡模式是 TKE 团队推出的下一代“零损耗”容器网络方案，其基本原理如下图所示：
即母机虚拟出的弹性网卡，直接置于容器中，使容器获得与 CVM 子机一样的网络通信能力和网络管理能力，大大提升了容器网络的数据面能力，真正做到“零损耗”。
目前，独立网卡网络方案已在 TKE 产品中开放白名单测试，欢迎内外部客户体验试用。
以上网络方案中，每个 Pod 都会独占一个网卡，也会拥有独立的命名空间和独立的 ARP 缓存表。而每个网卡都可以属于不同的子网。因此，在独立网卡模式里，ARP 缓存表项数量至多为同可用区的子网 IP 数量之和。这一数量量级是可以很轻易上万的，很容易就突破了默认的 ARP 缓存设置。也就触发了这个问题。
5. 解决方案从以上的分析可以看出，这个问题，调大垃圾回收的阈值，可以比较好的解决问题。因此，临时的解决方案，就是调大 ARP 缓存表的垃圾回收阈值：
echo 8192 > /proc/sys/net/ipv4/neigh/default/gc_thresh1echo 16384 > /proc/sys/net/ipv4/neigh/default/gc_thresh2echo 32768 > /proc/sys/net/ipv4/neigh/default/gc_thresh3 6. 总结ARP 缓存打满之后，Pod 就会网络不通。初看起来很简单，但是其背后的 ARP 缓存老化和垃圾回收机制也是比较复杂的。查询了很多资料，但是都对“垃圾回收阈值是对各命名空间的 ARP 表项累积值生效还是单独生效”，“垃圾回收会回收哪些表项”，“表项打满后的具体行为如何”等问题说不清、道不明。因此，笔者尝试通过几个小实验验证了具体的行为模式。相比直接阅读晦涩的内核源码，实验法也许也是一个研究问题和理解机制的捷径了。希望能够帮助到各位读者。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！