企业官网建设流程全解析

• 云原生
• 容器编排
• DevOps

eksctl v0.184.0 是 Amazon EKS 官方 CLI 的一个重要版本，其核心变化在于默认网络插件（default networking addons）的创建方式：集群创建时默认插件由"EKS 自动安装的自管理插件"切换为"以 EKS 托管插件（EKS addons）方式安装"，并通过addonsConfig.disableDefaultAddons赋予用户完全关闭默认插件的灵活性。本文基于当前仓库的源码、配置与用户文档，逐项解析该版本的 Feature、Improvements 与 Maintenance 变更，帮助读者理解升级后的行为差异，并掌握实际配置方法。

版本概览

此外，维护者向社区贡献者 @moreandres 表达了感谢。

核心 Feature：默认网络插件创建灵活性（#7866）

背景：从自管理插件到 EKS 托管插件

在介绍新特性前，先理解 EKS 的默认插件模型。创建集群时，EKS 会默认安装三个网络相关插件：

• kube-proxy
• aws-node（即 VPC CNI）
• coredns

在 v0.184.0 之前，eksctl 创建的集群中这些插件以**自管理插件（self-managed addons）**的形式运行，即 manifest 直接部署在集群内。v0.184.0 起，只要未显式设置addonsConfig.disableDefaultAddons: true，eksctl 会把这些默认插件统一安装为EKS 托管插件（EKS addons），走eksctl create addon同一条托管链路（见 addons.md）。

这一行为在 createAddonTask.Do 中体现：所有 addon 通过addonManager.Create创建，且eks-pod-identity-agent会被优先创建，因为其他 addon 可能依赖其 IAM 权限。

addonsConfig.disableDefaultAddons配置项

新增的核心配置项定义在 addon.go：

// AddonsConfig holds the addons config. type AddonsConfig struct { // AutoApplyPodIdentityAssociations specifies whether to automatically apply pod identity associations // for supported addons that require IAM permissions. AutoApplyPodIdentityAssociations bool `json:"autoApplyPodIdentityAssociations,omitempty"` // DisableDefaultAddons enables or disables creation of default networking addons when the cluster // is created. // By default, all default addons are installed as EKS addons. DisableDefaultAddons bool `json:"disableDefaultAddons,omitempty"` }

对应的 JSON Schema 描述为："enables or disables creation of default networking addons when the cluster is created. By default, all default addons are installed as EKS addons."，默认值为false（见 schema.json）。

典型使用场景：如果你希望使用 Cilium、Calico 等其他 CNI 插件，可以创建一个"不包含任何默认网络插件"的集群：

# cluster.yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cilium-cluster region: us-west-2 addonsConfig: disableDefaultAddons: true nodeGroups: - name: ng-1 instanceType: m5.large desiredCapacity: 2

eksctl create cluster -f cluster.yaml

如果只想保留 CoreDNS 和 kube-proxy、去掉 VPC CNI，可以显式列出需要的 addon 并同时设置disableDefaultAddons：

addonsConfig: disableDefaultAddons: true addons: - name: kube-proxy - name: coredns

eksctl create cluster -f cluster.yaml

源码实现：默认 addon 的自动补齐逻辑

CreateAddonTasks是集群创建流程中组装 addon 任务的核心函数（tasks.go）。其逻辑要点：

1. 当cfg.AddonsConfig.DisableDefaultAddons为false（默认）时，遍历api.KnownAddons中的默认 addon 白名单，把用户未显式指定的默认 addon 自动追加到安装列表，并记录到autoDefaultAddonNames，供日志提示使用。
2. 当DisableDefaultAddons为true时，仅安装用户显式配置的 addon；此时若集群启用了 Auto Mode 且没有节点组，会输出提示：默认 EKS addon 对 Auto Mode 集群并非必需，可考虑设置addonsConfig.disableDefaultAddons: true，或用eksctl delete addon删除。
3. 按CreateBeforeNodeGroup标记将 addon 拆分为"节点组创建前（preAddons）"与"节点组创建后（postAddons）"两组任务，确保顺序正确。
4. 若集群启用了 IAM OIDC 且包含vpc-cniaddon，会追加一个"update VPC CNI to use IRSA if required"任务，等待 VPC CNI 变为 Active 后再为其配置 IRSA。

在 cluster.go 中，创建集群时调用CreateAddonTasks，并对自动补齐的默认插件输出日志：

preNodegroupAddons, postAddons, updateVPCCNITask, autoDefaultAddons := addon.CreateAddonTasks(...) if len(autoDefaultAddons) > 0 { logger.Info("default addons %s were not specified, will install them as EKS addons", strings.Join(autoDefaultAddons, ", ")) }

默认 addon 白名单

默认 addon 集合定义在 known_addons.go 中，通过KnownAddons映射标记IsDefault：

HasAllDefaultAddons与HasDefaultNonAutoAddon是围绕该白名单的辅助判断函数，前者在 addon_helper.go 中被用于校验 addon 输出是否完整。

无 VPC CNI 裸集群的约束

如果disableDefaultAddons: true且同时禁用了 Auto Mode、也没有显式指定vpc-cni，则集群将处于"无 VPC CNI"的裸状态。此时 validateBareCluster 会拒绝在创建阶段携带以下字段，需要在集群创建成功后再补充：

• nodeGroups/managedNodeGroups
• fargateProfiles
• karpenter
• gitops
• iam.serviceAccounts
• iam.podIdentityAssociations

错误信息会明确提示"please remove these fields and add them back after cluster creation is successful"。

对既有命令的影响：eksctl utils update-*停用

这是升级用户最需要关注的行为变更（addons.md、addon-upgrade.md）：

eksctl now installs default addons as EKS addons instead of self-managed addons during cluster creation ifaddonsConfig.disableDefaultAddonsis not explicitly set to true.

因此，对v0.184.0 及以上版本创建的集群，以下命令不再适用：

eksctl utils update-aws-node eksctl utils update-coredns eksctl utils update-kube-proxy

应改用托管插件管理命令：

eksctl update addon --name vpc-cni --cluster <clusterName> --version latest eksctl get addon --cluster <clusterName> eksctl delete addon --cluster <clusterName> --name <addon-name>

需要说明的是：addon-upgrade.md中关于utils update-*的手动更新指南仅对v0.184.0 之前创建的集群（自管理插件）依然有效，属于遗留场景。

Improvement：停止使用 P2 实例（#7826）

P2 系列 GPU 实例（如p2.xlarge、p2.8xlarge、p2.16xlarge）即将在 AWS 退役。为此，eksctl v0.184.0 从实例类型数据中移除了 P2 家族。

从当前仓库的实例类型数据 instance_types.go 看，GPU 实例列表只保留了仍在服役的当前代家族，例如：

• p3dn.24xlarge、p4d.24xlarge、p4de.24xlarge
• p5.4xlarge、p5.48xlarge、p5e.48xlarge、p5en.48xlarge
• p6-b200.48xlarge、p6-b300.48xlarge

P2 已不在其中。这一点在 ssm_resolver_test.go 的测试注释中也有印证：测试曾以p3作为 NVIDIA 实例的示例，但因 p3 已退役并从生成的实例数据中移除，导致测试失效，现改用g5.xlarge作为当前代家族的示例。

对用户的实际影响：如果你的节点组配置中仍然引用 P2 实例类型，将无法再通过 eksctl 解析对应的 GPU AMI（AMI 解析依赖 ssm_resolver.go 中的实例类型判断）。请迁移到g4dn、g5或p4d/p5等当前代 GPU 实例。

Improvement：日志中使用字符串替代包装错误（#7838）

该变更将日志输出中的错误处理方式从"包装错误（wrapping error）"改为"直接使用错误字符串"。这类改动通常在日志链路中降低格式化开销，并避免在日志中出现重复的错误上下文前缀，使排查信息更干净、更易读。它属于不影响功能行为、只改善可观测性的内部优化。

Maintenance：修复 SDK 分页器 mock（#7850）

该 PR 修复了 AWS SDK 分页器（paginator）相关 mock 的问题。eksctl 的测试大量依赖 mockprovider 提供的 AWS API mock，分页器 mock 的正确性直接影响涉及列表类 API（如列举 addon、实例类型、节点组等）的单元测试与集成测试的可靠性。修复后这些 mock 与 SDK v2 的分页接口保持一致，降低测试误报风险。

Maintenance：调度 Pod 到无并发操作的节点组（#7834）

该变更调整了 Pod 调度策略，将 Pod 调度到当前没有并发操作执行的节点组上。从源码结构看，这与 drain、nodegroup 操作 相关的并发编排有关：在节点组进行扩容、缩容、更新等并发操作时，将 Pod 调度到空闲节点组可以避免与进行中的操作相互干扰，提升集群运维的稳定性。

升级建议

1. 更新 eksctl：升级到 v0.184.0 后创建的新集群，默认插件均以 EKS 托管插件管理，后续请统一使用eksctl create/get/update/delete addon管理这些插件，不要再用eksctl utils update-*。
2. 使用第三方 CNI：需要 Cilium/Calico 等自定义网络方案时，配置addonsConfig.disableDefaultAddons: true，并注意裸集群创建阶段的字段限制。
3. 清理退役实例：检查现有节点组配置，将 P2 实例替换为当前代 GPU 实例类型。
4. 验证插件状态：集群创建后可执行kubectl get pods -n kube-system确认aws-node、coredns、kube-proxy等插件 Pod 均处于 Running 状态。

总结

eksctl v0.184.0 通过默认网络插件的"EKS 托管化"与disableDefaultAddons灵活性，解决了长期困扰用户的"默认插件不可关闭、无法自由接入第三方 CNI"的痛点，但也带来插件管理命令体系的变化（utils update-*→update addon）。同时，P2 实例退役清理与若干维护性修复，使该版本在功能、兼容性与工程质量上形成了完整的升级闭环。相关源码与配置均可通过 addon.go、tasks.go、known_addons.go 以及 addons.md 深入查阅。

• 云原生
• 容器编排
• DevOps