Karpenter与Cilium在EKS Overlay模式下的节点注册问题解析

背景概述

在AWS EKS环境中使用Karpenter进行节点自动伸缩时，结合Cilium CNI的Overlay网络模式，可能会遇到新创建的EC2实例无法正常注册到Kubernetes集群的情况。这类问题通常表现为：

• Karpenter成功创建了EC2实例
• 但节点未出现在kubectl get nodes输出中
• Cilium DaemonSet未能调度到新节点

问题本质

这种现象的核心原因是网络连通性问题。在Overlay模式下，Cilium依赖VPC网络的正常通信来完成节点注册和组件部署。当新增VPC CIDR后，如果未同步更新相关安全组规则，会导致以下关键通信中断：

1. 新节点无法与EKS控制平面建立连接
2. Cilium Agent无法从新节点下载所需镜像
3. 节点注册所需的kubelet通信被阻断

典型配置要点

VPC端点安全组配置

必须确保以下流量的通畅：

• 新节点所在子网到EKS API服务的443端口
• 新节点到ECR服务的HTTPS访问（用于拉取Cilium等组件镜像）
• 节点间Overlay网络所需的VXLAN/UDP端口（默认为8472）

Karpenter节点模板注意事项

在配置Karpenter Provisioner时，需要特别注意：

1. 安全组必须包含EKS集群默认安全组
2. 子网选择应覆盖所有新增CIDR范围
3. IAM角色需要包含必要的EC2和EKS权限

排查方法论

基础检查项

1. 确认EC2实例状态为"running"
2. 检查实例系统日志是否有kubelet启动错误
3. 验证安全组出站规则是否允许访问EKS API端点

高级诊断手段

1. 通过SSH连接到问题节点检查：
   • kubelet服务状态
   • 到API服务器的网络连通性
   • 必要的IAM角色附加情况
2. 检查CloudTrail日志中是否有被拒绝的API调用
3. 分析VPC流日志中的异常连接

最佳实践建议

网络规划建议

1. 提前规划好VPC CIDR扩展方案
2. 建立安全组变更管理流程
3. 对EKS相关安全组打上专用标签

自动化防护措施

1. 使用Terraform等IaC工具管理安全组规则
2. 配置Config规则监控EKS相关网络配置
3. 为Karpenter设置节点健康检查机制

总结思考

这类基础设施级问题往往需要从整体架构视角进行排查。在实际运维中，建议建立完善的变更记录和影响评估机制，特别是在修改VPC网络配置时，需要同步考虑所有依赖组件的影响范围。通过基础设施即代码和自动化测试可以有效降低此类问题的发生概率。