Linkerd CNI插件在AWS EKS集群中的部署问题及解决方案

问题背景

在AWS EKS环境中部署Linkerd CNI插件版本2025.3.1时，用户遇到了与之前版本13760类似的问题。当尝试将linkerd-cni从v2025.2.3升级到v2025.3.1时，DaemonSet的首次Pod启动失败，导致整个升级过程受阻。

错误现象

部署过程中，Kubernetes事件日志显示以下关键错误信息：

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "41b3c75a...": plugin type="linkerd-cni" name="linkerd-cni" failed (add): Unauthorized

环境信息

• Kubernetes版本：AWS EKS 1.31
• Linkerd版本：v2.17.1
• Linkerd CNI版本：v2025.3.1
• 操作系统：Bottlerocket

问题分析

通过深入分析，我们发现问题的根源在于CNI配置文件中存在冲突。在AWS EKS环境中，当同时使用Cilium和AWS CNI插件时，Linkerd CNI插件的配置可能导致授权问题。具体表现为：

1. 节点上的/etc/cni/net.d/目录包含三个关键文件：

   • 05-cilium.conflist
   • 10-aws.conflist
   • ZZZ-linkerd-cni-kubeconfig

2. 在05-cilium.conflist文件中，存在对Linkerd CNI插件的引用，这导致了插件初始化时的授权冲突。

解决方案

对于使用Bottlerocket操作系统的AWS EC2实例，可以按照以下步骤解决问题：

1. 获取每个EC2实例的shell访问权限
2. 执行enter-admin-container命令进入管理容器
3. 编辑/.bottlerocket/rootfs/etc/cni/net.d/05-cilium.conflist文件
4. 移除文件中与linkerd-cni相关的插件配置
5. 在EKS中重启对应的linkerd-cni Pod

需要注意的是，这个过程需要在集群中的每个节点上逐一执行，同时确保每次只处理一个节点，以避免服务中断。

技术原理

Linkerd CNI插件作为服务网格的一部分，负责处理Pod间的网络通信。当多个CNI插件共存时，可能会出现配置冲突。在这种情况下，Cilium CNI插件配置中包含了Linkerd CNI的引用，导致授权检查失败。

Bottlerocket作为专门为容器工作负载设计的操作系统，其文件系统结构与传统Linux发行版有所不同。解决方案中提到的路径/.bottlerocket/rootfs/是访问主机文件系统的特殊方式。

最佳实践建议

1. 在升级Linkerd CNI插件前，建议先备份所有CNI配置文件
2. 考虑使用自动化工具批量处理多节点配置变更
3. 对于生产环境，建议先在测试环境中验证升级过程
4. 定期检查CNI插件间的兼容性，特别是当使用多个网络插件时

总结

Linkerd CNI插件在特定环境下的部署问题通常与CNI配置冲突有关。通过理解底层网络插件的工作原理和交互方式，可以有效地解决这类问题。本文提供的解决方案不仅适用于所述版本，其思路也可应用于类似的CNI插件冲突场景。