作者朱瑜坚,腾讯云后台开发工程师,熟悉 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 协议的通信频