EKSCTL项目中使用Fargate部署CoreDNS的调度问题分析

问题背景

在AWS EKS环境中，当用户尝试通过eksctl工具创建同时包含Fargate配置文件和CoreDNS插件的集群时，可能会遇到CoreDNS Pod无法正常调度的问题。具体表现为：当Fargate配置文件中包含特定标签选择器时，CoreDNS Pod会卡在Pending状态，需要手动重启部署才能解决。

问题现象

用户在使用eksctl创建集群时，如果在Fargate配置文件中为kube-system命名空间指定了eks.amazonaws.com/component: coredns标签选择器，CoreDNS Pod会在Fargate配置文件完全激活前就被创建出来。由于此时Fargate节点尚未就绪，这些Pod会一直处于Pending状态。

技术分析

正常行为模式

在标准的Fargate集群创建过程中，eksctl会按照以下顺序执行操作：

1. 创建集群控制平面
2. 安装核心插件（包括CoreDNS）
3. 等待控制平面就绪
4. 创建Fargate配置文件
5. 确保CoreDNS可调度到Fargate节点上

当Fargate配置文件中不包含任何标签选择器时，eksctl会额外执行一个步骤来确保CoreDNS能够被正确调度到Fargate节点上。

异常行为模式

当Fargate配置文件中包含标签选择器时，调度流程出现异常：

1. CoreDNS插件在Fargate配置文件创建前就被安装
2. CoreDNS Pod立即被创建，但由于没有匹配的节点（既无EC2节点，Fargate节点也未就绪）而处于Pending状态
3. Fargate配置文件创建完成后，已存在的Pod不会自动重新调度

解决方案

目前有两种可行的解决方案：

1. 手动重启CoreDNS部署：在集群创建完成后，执行以下命令强制重新调度CoreDNS Pod：

   kubectl rollout restart deployment coredns -n kube-system
   

2. 修改Fargate配置文件：移除Fargate配置文件中的标签选择器，让eksctl自动处理CoreDNS的调度时机。例如：

   fargateProfiles:
     - name: main
       selectors:
         - namespace: kube-system
   

底层原理

这个问题本质上涉及Kubernetes调度器的工作机制和AWS Fargate的特殊性：

1. 调度器行为：Kubernetes调度器在Pod创建时进行一次调度决策，除非Pod被删除重建，否则不会重新评估调度位置。

2. Fargate特性：Fargate节点不像传统EC2节点那样预先存在，而是在匹配的Pod需要调度时才会动态创建。

3. 标签选择器的影响：当Fargate配置中包含标签选择器时，eksctl无法准确判断何时是安装CoreDNS的最佳时机，导致安装顺序出现问题。

最佳实践建议

对于需要在Fargate上运行CoreDNS的用户，建议：

1. 如果不需要特殊的标签选择，优先使用不包含标签的Fargate配置文件。

2. 如果必须使用标签选择器，在集群创建后检查CoreDNS Pod状态，必要时手动重启部署。

3. 考虑在CI/CD流程中加入状态检查步骤，确保CoreDNS正常运行后再继续后续部署。

这个问题展示了在混合使用Kubernetes原生调度机制和云服务商特定功能时可能遇到的边缘情况，理解这些交互行为对于构建稳定的云原生基础设施至关重要。