为何EKS启用Addons速度极慢？aws-ebs-csi-driver部署耗时咨询

自部署与EKS Addon部署的实践对比 #

多个生产环境实测的体验差异如下：

• 耗时表现：通过Terraform拉起EKS Addon版本的aws-ebs-csi-driver，常规耗时在12-18分钟区间，偶发排队高峰时耗时会突破20分钟，很容易超过流水线临时令牌的有效期，触发权限类报错；通过FluxCD、Helm直接在集群部署同版本驱动，整体耗时仅30秒到1分钟，耗时仅取决于集群节点拉取镜像的速度，无额外等待开销。
• 能力与成本差异：
  • EKS Addon作为托管能力，默认会自动匹配兼容当前EKS版本的驱动版本，支持一键关联AWS预置的IAM权限策略，减少了版本兼容校验、权限配置的工作量；但实际使用中版本更新节奏比社区官方Helm Chart慢1-2个小版本，自定义配置（比如调整DaemonSet资源限制、自定义存储类参数、开启额外特性开关）只能通过configuration_values字段传值，灵活性很差，部署卡顿时没有渠道查看控制面侧的任务执行日志，排障难度高。
  • 自部署模式支持全量自定义配置，版本可以跟随社区迭代，所有部署事件、工作负载日志都在集群内可查，排障路径清晰；额外成本仅为需要自行核对驱动版本与EKS版本的兼容关系，手动配置驱动工作负载所需的IAM权限。
• 选型建议：频繁创建销毁的测试环境、对交付速度敏感的流水线场景优先选择自部署模式，避免阻塞交付流程；生产环境如果自定义配置需求少、希望减少组件维护工作量，可以选择EKS Addon，但需要在Terraform配置中给Addon资源设置至少20分钟的超时时间，同时配置流水线令牌自动续期或长有效期凭证，规避部署过程中的权限过期问题。

EKS Addons安装流程的底层逻辑 #

目前AWS未公开EKS Addons的完整底层实现，但从实际运行观测、已披露的服务架构信息，可以确认以下运行逻辑：

• EKS Addons的部署调度逻辑运行在AWS侧独立的托管服务集群上，不属于用户租户的EKS控制面组件，用户发起的Addon安装、更新请求会先进入异步任务队列排队，不会直接下发到用户集群，这也是为什么在Terraform模块、用户集群内找不到插件相关调度逻辑引用的原因。
• 任务出队后不会直接下发资源，会先完成多轮前置校验：包括集群版本与Addon版本的兼容性校验、集群VPC与托管服务的网络连通性校验、Addon所需IAM权限的有效性校验，校验环节加上排队等待的时间占总部署时长的80%以上，这个阶段用户集群内不会产生任何和Addon相关的资源。
• 校验通过后，托管服务才会向用户集群的API Server下发Addon对应的Manifest资源，之后会以固定30秒的间隔轮询集群内Addon对应工作负载的就绪状态，直到所有Pod达到Ready状态，才会将Addon状态标记为部署完成，这个固定轮询间隔也会额外拉长整体部署耗时。

实测如果遇到Addon部署超过20分钟未完成的情况，可以通过修改Addon的任意配置（比如更新一个无关的configuration_values参数）触发任务重新入队，多数场景下可以避开排队高峰，缩短部署时间。

内容的提问来源于stack exchange，提问作者Piotr