亚马逊VPC CNI插件中IP规则丢失问题分析与解决方案

问题背景

在运行亚马逊VPC CNI插件（amazon-vpc-cni-k8s）的Kubernetes集群中，当系统服务systemd-networkd重启时，会出现IP路由规则丢失的情况，导致Pod网络通信异常。这一问题在Ubuntu 22.04系统上尤为常见，特别是在使用kOps部署的集群中。

问题现象

当执行systemctl restart systemd-networkd命令后，系统会停止并重新启动所有辅助ENI接口。这一过程会导致以下网络配置发生变化：

1. 原有的IP路由规则被清空
2. 仅保留基本的默认路由规则
3. 虽然路由表内容仍然存在，但关联的规则已经丢失

具体表现为，原本应该通过特定ENI接口的Pod流量会被错误地路由到主网络接口，导致网络连接失败。

技术原理分析

亚马逊VPC CNI插件在节点上为每个Pod创建网络接口时，会设置特定的IP路由规则，确保Pod流量通过正确的ENI接口传输。这些规则包括：

1. 源IP规则：将来自Pod IP的流量定向到特定的路由表
2. 目标IP规则：确保发送到Pod IP的流量使用主路由表
3. 标记规则：处理带有特定标记的流量

当systemd-networkd服务重启时，它会重新初始化网络接口配置，但不会保留CNI插件设置的这些自定义规则。这是因为：

1. systemd-networkd的设计初衷是管理基础网络配置
2. CNI插件设置的规则被视为"临时"配置
3. 缺乏规则持久化机制

影响范围

这一问题主要影响以下环境：

1. 使用systemd-networkd作为网络管理器的Linux发行版
2. 特别是Ubuntu 22.04及更新版本
3. 使用kOps部署的集群（因为默认安装unattended-upgrades）
4. 任何会导致systemd-networkd重启的操作（如安全更新）

解决方案

临时解决方案

1. 重启CNI插件Pod：可以尝试重启节点上的VPC CNI插件Pod，但这并不总是能恢复规则
2. 手动恢复规则：在受影响节点上手动重新创建丢失的规则（不推荐用于生产环境）

长期解决方案

1. 禁用systemd-networkd对CNI接口的管理： 在/etc/systemd/network/目录下创建配置文件，排除CNI管理的接口

2. 配置系统自动更新策略： 修改unattended-upgrades配置，避免在关键时段自动重启网络服务

3. 等待CNI插件改进： 开发团队正在评估长期解决方案，可能会增加规则自动恢复功能

最佳实践建议

1. 在生产环境中，应谨慎安排系统更新，避免非计划的服务中断
2. 考虑使用监控工具检测节点网络规则状态
3. 对于关键业务集群，建议实施变更管理流程，评估更新影响
4. 保持CNI插件版本更新，以获取最新的稳定性和兼容性改进

总结

亚马逊VPC CNI插件与systemd-networkd服务的交互问题展示了容器网络配置管理中的复杂性。理解这一问题的根源有助于运维人员更好地规划集群维护策略，并为未来可能的架构改进做好准备。随着云原生技术的不断发展，这类基础设施层的兼容性问题将逐渐得到更完善的解决方案。