TKE 容器网络中的 ARP Overflow 问题探究及其解决之道

作者朱瑜坚，腾讯云后台开发工程师，熟悉 CNI 容器网络相关技术，负责腾讯云 TKE 的容器网络的构建和相关网络组件的开发维护工作，作为主力开发实现了 TKE 下一代容器网络方案。

1. 问题背景

1.1 问题描述

最近，某内部客户的 TKE VPC-CNI 模式的独立网卡集群上出现了 pod 间访问不通的情况，问题 pod ping 不通任何其他 pod 和节点。

查看 dmesg 内核日志，有如下报错信息：neighbour: arp_cache: neighbor table overflow!(下图为后续复现的日志截图)

并且，这个集群规模较大，约有 1000 个节点，30000 个 pod，基本可以怀疑是由于集群规模较大，导致 ARP 表项过多，从而引起 ARP Overflow 的问题。

1.2 名词解释

名词	说明
TKE	全称 Tencent Kubernetes Engine, 腾讯云容器服务，是基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务
VPC-CNI 模式	是容器服务 TKE 基于 CNI 和 VPC 弹性网卡实现的容器网络能力
Pod	Pod 是 kubernetes 的基本资源管理单位，拥有独立的网络命名空间，1个 Pod 可包含多个容器

2. 问题初步分析

从如上报错信息可知，这个问题的基本原因在于 ARP 缓存表打满了。这里涉及到内核的 ARP 缓存垃圾回收机制。当 ARP 表项太多且又没有可回收的表项的时候，新表项就会无法插入。

这就导致网络包发送时无法找到对应的硬件地址(MAC)。使得网络包不能发送。

那么具体什么情况会导致新表项无法插入呢？回答这个问题，我们需要先深入了解一下 ARP 缓存老化及垃圾回收机制。

3. ARP 缓存老化回收机制

3.1 ARP 缓存表项状态机

如上图，是整个 ARP 表项的生命周期及其状态机。

我们知道，对于 TCP/IP 网络包发送时，网络栈需要对端的 MAC 地址才能让网络包转换成二层的数据结构——帧，从而在网络中传输。而对于不同广播域的 IP 地址，其对端 MAC 地址为网关，发送端会将网络包发给网关让其转发，而对于同广播域中的 IP 地址，其对端 MAC 地址即与 IP 地址对应。

而通过 IP 地址找到 MAC 地址就是 ARP 协议的主要工作内容。ARP 协议的工作过程此处不再赘述，而通过 ARP 协议找到 IP 地址对应的 MAC 地址后，会将该对应关系存储在本机上一段时间，以减少 ARP