eksctl 0.11.0 版本深度解析：Fargate 支持落地与 Windows 节点组能力增强

云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载本篇文章围绕 eksctl 0.11.0 版本的官方发布说明展开逐一拆解该版本引入的核心特性、体验改进与关键缺陷修复包括 AWS Fargate 配置支持#1623、Windows 节点组的taints与maxPodsPerNode配置能力#1604、App Mesh 节点策略中 Cloud Map 集成所需权限的补齐#1610以及--only-missing过滤器、git commit 日志等实用改进。读完本文你将清楚了解这些能力对应的配置文件写法、命令行用法及其在 eksctl 源码中的具体实现位置可直接对照仓库代码进行实践与验证。一、版本概览0.11.0 的核心变化0.11.0 是 eksctl 早期发展中的一个关键里程碑其核心变化可归纳为三条主线Fargate 支持落地#1623用户可以在 ClusterConfig 中声明fargateProfiles让工作负载调度到 AWS Fargate 上无需管理节点组Windows 节点组配置能力补齐#1604为 Windows 节点组支持nodegroup.taints和nodegroup.maxPodsPerNode两个常用字段App Mesh 节点策略增强#1610在 App Mesh 的 IAM 节点策略中追加servicediscovery:ListServices权限以支持 App Mesh 控制器的 Cloud Map 集成。此外该版本还包含若干改善体验的改进项和一批针对性 Bug 修复。下面逐一展开。二、核心特性Fargate 配置支持2.1 什么是 Fargate 支持0.11.0 引入了对 AWS Fargate 的支持对应 issue #1623。在此之前eksctl 创建集群主要围绕 EC2 节点组展开从 0.11.0 开始用户可以在同一份 ClusterConfig 中声明一个或多个 Fargate profile由 AWS Fargate 按 profile 中的命名空间与标签选择器selector来决定哪些工作负载运行在无服务器计算之上。在源码层面FargateProfile类型定义位于 pkg/apis/eksctl.io/v1alpha5/types.go其结构如下type FargateProfile struct { // Name of the Fargate profile. Name string json:name // PodExecutionRoleARN is the IAM roles ARN to use to run pods onto Fargate. PodExecutionRoleARN string json:podExecutionRoleARN,omitempty // Selectors define the rules to select workload to schedule onto Fargate. Selectors []FargateProfileSelector json:selectors // Subnets which Fargate should use to do network placement of the selected workload. Subnets []string json:subnets,omitempty // Used to tag the AWS resources Tags map[string]string json:tags,omitempty // The current status of the Fargate profile. Status string json:status }配套的选择器类型FargateProfileSelectortypes.go由必需的Namespace和可选的Labels构成用于决定哪些命名空间下的哪些负载会被调度到 Fargate。2.2 配置文件写法多 Fargate profile 示例仓库自带的官方示例 examples/16-fargate-profile.yaml 完整展示了 0.11.0 起支持的 Fargate 配置方式包含两个 profileapiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cluster-16 region: ap-northeast-1 nodeGroups: - name: ng-1 instanceType: m5.large desiredCapacity: 1 fargateProfiles: - name: fp-default selectors: # All workloads in the default Kubernetes namespace will be # scheduled onto Fargate: - namespace: default # All workloads in the kube-system Kubernetes namespace will be # scheduled onto Fargate: - namespace: kube-system - name: fp-dev selectors: # All workloads in the dev Kubernetes namespace matching the following # label selectors will be scheduled onto Fargate: - namespace: dev labels: env: dev checks: passed tags: env: dev name: fp-dev关键点说明fargateProfiles是一个列表允许同时声明多个 profile每个 profile 通过selectors定义其调度范围selector 只需提供namespace即可匹配该命名空间下的所有负载附加labels后可进一步按标签精确匹配上例中dev命名空间下带envdev与checkspassed标签的负载才会被调度到 Fargatetags用于给该 profile 关联的 AWS 资源打标签集群仍可保留普通节点组如示例中的ng-1Fargate 与 EC2 节点组可共存于同一集群。2.3 命令行创建eksctl create fargateprofile除了在 ClusterConfig 中声明0.11.0 还提供了独立的eksctl create fargateprofile命令。该命令的 CLI 参数在 pkg/ctl/cmdutils/fargate.go 中注册包括参数说明--nameFargate profile 的名称--namespace要调度到 Fargate 的工作负载所在 Kubernetes 命名空间--labels-l要调度到 Fargate 的工作负载的 Kubernetes 标签选择器--tags-t用于标记 AWS 资源的标签例如eksctl create fargateprofile \ --cluster cluster-16 \ --name fp-dev \ --namespace dev \ --labels envdev,checkspassed \ --tags envdev,namefp-dev从源码看--name、--namespace、--labels三个参数与 ClusterConfig 文件是互斥的见 fargate.go 中fargateProfileFlagsIncompatibleWithConfigFile的定义避免输入重复冲突而使用纯命令行方式时eksctl 会基于这些 flag 构造出等价的FargateProfile对象fargate.go再走与配置文件相同的校验流程。2.4 修复多 Fargate profile 的创建问题#16280.11.0 的 Bug 修复列表特别标注了「修复eksctl create fargateprofile在使用包含多个 Fargate profile 的配置文件时的问题」#1628。结合源码可以还原这一修复的意义eksctl create fargateprofile命令的加载器会遍历 ClusterConfig 中的全部FargateProfiles并逐一调用Validate()见 fargate.go因此在多 profile 场景下每个 profile 的名称、选择器都必须正确解析与校验。该修复确保了 2.2 节示例中fp-default、fp-dev这种多 profile 配置能被稳定创建而不是只处理第一个 profile。三、Windows 节点组taints与maxPodsPerNode支持#16043.1 特性内容0.11.0 为 Windows 节点组补齐了两个此前仅在 Linux 节点组可用的字段#1604nodegroup.taints为节点打污点taint控制哪些 Pod 可以被调度到该节点组nodegroup.maxPodsPerNode限制单个节点上可运行的 Pod 数量上限。在类型定义中Taints字段位于 pkg/apis/eksctl.io/v1alpha5/types.go类型为[]NodeGroupTaintMaxPodsPerNode字段位于 types.go类型为int。3.2 配置示例在 ClusterConfig 中可这样为 Windows 节点组配置nodeGroups: - name: ng-windows amiFamily: WindowsServer2019FullContainer instanceType: m5.large desiredCapacity: 2 maxPodsPerNode: 30 taints: - key: dedicated value: windows effect: NoSchedulemaxPodsPerNode: 30表示该节点组每台节点最多运行 30 个 Podtaints中的key/value/effect与 Kubernetes 原生 taint 语义一致effect可取NoSchedule、PreferNoSchedule或NoExecute。3.3 底层校验逻辑在 pkg/apis/eksctl.io/v1alpha5/validation.go 中可以看到maxPodsPerNode的校验规则其值不能为负数maxPodsPerNode cannot be negative。同时当使用自定义 AMIcustom AMI时该字段会被限制使用validation.go因为自定义 AMI 场景下 Pod 数量上限通常由 AMI 内的引导配置决定这与 Linux 节点组的行为保持一致。在引导脚本侧pkg/nodebootstrap/assets/scripts/bootstrap.helper.sh 中的注释说明--max-pods作为 CLI 参数已被弃用maxPodsPerNode是替代方案相关测试managed_al2_test.go也覆盖了maxPodsPerNode的设置场景印证了该字段会真实写入节点引导参数。四、App Mesh 节点策略补充 Cloud Map 集成权限#16104.1 变更内容0.11.0 在 App Mesh 的节点 IAM 策略中追加了servicediscovery:ListServices权限#1610目的是让 App Mesh 控制器能够与 AWS Cloud Map 进行集成。4.2 源码证据该策略在 CloudFormation 构建层生成定义于 pkg/cfn/builder/statement.go 的appMeshStatements函数。完整权限列表为servicediscovery:CreateService, servicediscovery:DeleteService, servicediscovery:GetService, servicediscovery:GetInstance, servicediscovery:RegisterInstance, servicediscovery:DeregisterInstance, servicediscovery:ListInstances, servicediscovery:ListNamespaces, servicediscovery:ListServices, servicediscovery:GetInstancesHealthStatus, servicediscovery:UpdateInstanceCustomHealthStatus, servicediscovery:GetOperation, route53:GetHealthCheck, route53:CreateHealthCheck, route53:UpdateHealthCheck, route53:ChangeResourceRecordSets, route53:DeleteHealthCheck,其中servicediscovery:ListServicesstatement.go正是 0.11.0 新增的动作。当用户通过 eksctl 创建启用了 App Mesh 集成的节点组时生成的 CloudFormation 栈会为节点角色附加这一策略从而允许 App Mesh 控制器发现 Cloud Map 中注册的服务实现服务网格与 Cloud Map 的联动。五、改进项only-missing过滤器与工程体验优化5.1 托管节点组的only-missing过滤器#15930.11.0 为托管节点组managed nodegroup的操作引入了--only-missing过滤器支持并支持「追加 globs」append globs语法#1593。--only-missing的语义是仅对「配置文件中定义了、但集群中不存在」的资源执行操作。此前该过滤器已用于 IAM Service Account 的删除流程见 pkg/ctl/delete/iamserviceaccount.go 与 pkg/ctl/cmdutils/filter/iamserviceaccount_filter.go0.11.0 将其扩展到托管节点组场景。从节点组删除命令的实现看--only-missing定义于 pkg/ctl/delete/nodegroup.gofs.BoolVar(options.onlyMissing, only-missing, false, Only delete nodegroups that are not defined in the given config file)典型用法eksctl delete nodegroup --cluster cluster-16 --config-file config.yaml --only-missing含义仅删除配置文件中未定义、但实际存在于集群中的节点组从而让集群节点组与配置文件保持严格一致过滤器的行为在 pkg/ctl/cmdutils/filter/nodegroup_filter_test.go 中有对应测试覆盖。5.2 版本信息日志无 tag 时输出 git commit#1614此前当 eksctl 从非正式发布的构建运行时例如直接基于 master 分支构建--version输出无法精确定位到对应代码。0.11.0 起若版本 tag 不存在eksctl 会在日志中输出 git commit hash#1614。对应实现位于 pkg/version/version.goInfo结构体包含Version、PreReleaseID与BuildMetadata内含GitCommit与BuildDateGetVersion()在非 RC 版本且gitCommit/buildDate均存在时会以版本号commit.builddate的形式追加构建元数据。其中gitCommit变量由链接器在构建时注入定义见 pkg/version/generate/release_generate.go。这一改动让用户在排查问题时可以准确报告所运行二进制对应的源码版本。5.3 测试超时与多 OS 构建#1613、#1612#1613提升了 public/private endpoint 相关测试的超时时间。这与 VPC 端点、API Server 访问配置相关的集成测试稳定性有关避免在真实 AWS 环境中因网络配置生效较慢导致测试误报失败#1612为 Makefile 增加了多 OS 构建规则便于在 Linux、macOS、Windows 等不同平台产出 eksctl 二进制配合 pkg/version/generate/release_generate.go 的版本生成流程服务于发布流程。六、其他 Bug 修复除 2.4 节的多 Fargate profile 修复外0.11.0 还修复了以下问题#1598修复了 eks-managed-nodegroups 文档仓库中对应 userdocs/src/usage/ 目录中的失效链接保证托管节点组使用指南可正常跳转#1594根据具体命令选择合适的 CLI 参数——在--name与--cluster之间做区分。此前部分命令对「节点组名」和「集群名」的参数使用存在混用0.11.0 起各命令按语义使用正确参数例如集群相关命令使用--cluster而节点组、Fargate profile 等具名资源使用--name#1557修复了 VPC 相关的测试用例确保 VPC 导入、子网等场景的测试与当前实现保持一致。七、升级建议与验证方法7.1 升级方式0.11.0 为正式发布版本可通过官方发布流程获取二进制或在已有源码基础上构建git clone https://gitcode.com/gh_mirrors/ek/eksctl cd eksctl make build构建后可通过eksctl version验证版本号及 git commit 信息当无版本 tag 时输出将包含 commit hash这正是 #1614 引入的能力。7.2 快速验证清单对照本文内容可依次验证Fargate使用 examples/16-fargate-profile.yaml 创建集群观察fp-default与fp-dev两个 profile 是否均被成功创建对应 #1623、#1628 的修复Windows 节点组按第三节示例配置maxPodsPerNode与taints验证eksctl create cluster生成的 CloudFormation 中是否包含对应节点引导参数对应 #1604App Mesh创建启用了 App Mesh 的节点组后在 CloudFormation 输出的节点 IAM 策略中确认存在servicediscovery:ListServices对应 #1610only-missing在配置文件中定义若干节点组后运行eksctl delete nodegroup --only-missing验证只删除未定义的节点组对应 #1593。八、总结eksctl 0.11.0 是一个功能密度很高的版本Fargate 支持让 eksctl 从「EC2 节点组编排工具」迈向「可同时管理 EC2 与无服务器工作负载」的统一入口Windows 节点组的taints/maxPodsPerNode补齐了跨平台节点组配置的一致性App Mesh 策略的补充则完善了服务网格与 Cloud Map 的集成链路。与此同时--only-missing过滤器、git commit 日志、参数语义修复等改进共同提升了日常使用的可操作性与可排查性。对于希望深入理解实现细节的读者建议重点关注 pkg/apis/eksctl.io/v1alpha5/types.go配置模型、pkg/ctl/cmdutils/fargate.goFargate 命令解析与校验、pkg/cfn/builder/statement.goIAM 策略生成以及 pkg/version/version.go版本信息这些文件共同构成了 0.11.0 各项变更的源码级落点。赞分享云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载相关推荐eksctl 0.20.0 版本全解析GovCloud 区域支持、节点组弹性伸缩边界与 IAM 服务账户管理增强eksctl 0.20.0 版本全解析GovCloud 区域支持、节点组弹性伸缩边界与 IAM 服务账户管理增强 导读 本文围绕 eksctl 0.20.0云原生容器编排DevOpseksctl 0.178.0 版本深度解析修复 AL2023 节点组的 kubeletExtraConfig 支持并升级 aws-nodeVPC CNI至 1.18.1eksctl 0.178.0 版本深度解析修复 AL2023 节点组的 kubeletExtraConfig 支持并升级 aws nodeVPC CNI云原生容器编排DevOpseksctl 0.15.0 版本解读KMS 加密、中国区域支持与 Bottlerocket 节点组eksctl 0.15.0 版本解读KMS 加密、中国区域支持与 Bottlerocket 节点组 eksctl 0.15.0 是 eksctl 迈向全球区云原生容器编排DevOps创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考