云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载导读本文基于 eksctl 官方仓库中的 0.90.0 版本发布说明系统讲解该版本带来的三项关键变化新增propagateASGTags配置项自动将节点组的 labels 与 taints 转换为 Auto Scaling Group 标签让 Cluster Autoscaler 可以从 0 扩容、AWS SDK v2 的落地与 STS 服务的首批迁移以及 addon 无策略源场景的文档澄清。读完本文你将理解这些变化背后的源码实现原理并能在自己的节点组配置中直接使用这些新能力。版本概览eksctl 0.90.0 是一个小而关键的里程碑版本发布说明共包含 1 项功能、2 项改进其中 1 项为文档更新FeaturesAutomatically create ASG tags from a nodegroups labels and taints (#4962)ImprovementsSet up AWS SDK v2 and migrate STS service (#4926)DocumentationUpdate docs to mention what happens when you create an addon with no policy sources (#4999)其中 #4962 直接面向用户新增了一个配置能力是本文讲解的核心#4926 则是面向项目架构的长期基础设施改造#4999 是对已有行为的文档澄清。下文逐一展开。一、核心新功能propagateASGTags 自动生成 ASG 标签1.1 它解决什么问题Cluster Autoscaler 的从 0 扩容在 EKS 集群中当节点组使用 Cluster Autoscaler 且desiredCapacity为 0即节点组当前没有运行中的节点时Autoscaler 需要依赖Auto Scaling Group 上的标签来了解该节点组内节点应有的 labels 和 taints从而正确地为待调度 Pod 选择合适的节点组进行扩容。如果这些元数据没有以 ASG 标签的形式存在Autoscaler 就无法在0 节点状态下判断哪个节点组满足 Pod 的调度约束。在 0.90.0 之前用户需要在节点组配置中手工为每一个 label 和 taint 编写对应的 ASG 标签这是官方文档一直推荐的方案0.90.0 引入了propagateASGTags开关让 eksctl 在生成 CloudFormation 模板时自动完成这一映射。1.2 配置方式与完整示例propagateASGTags是一个布尔型字段同时适用于managed 与 unmanaged 节点组位于节点组定义中nodeGroups: - name: ng1-public instanceType: m5.xlarge desiredCapacity: 0 labels: my-cool-label: pizza taints: feaster: true:NoSchedule propagateASGTags: true对于managedNodeGroups写法完全一致只需把顶层键换成managedNodeGroups。启用后eksctl 会在生成的 CloudFormation 模板中自动为 ASG 追加如下格式的标签来源生成的 ASG 标签 Key示例nodegroup 的 labelk8s.io/cluster-autoscaler/node-template/label/label-keyk8s.io/cluster-autoscaler/node-template/label/my-cool-label: pizzanodegroup 的 taintk8s.io/cluster-autoscaler/node-template/taint/taint-keyk8s.io/cluster-autoscaler/node-template/taint/feaster: true:NoSchedule所有自动生成的标签都会带上PropagateAtLaunch: true确保标签在实例启动时传播到 EC2 实例上。1.3 源码实现剖析该功能的实现位于 pkg/cfn/builder/nodegroup.go 的模板构建逻辑中。标签前缀常量定义在文件头部const ( nodeTemplatePrefix k8s.io/cluster-autoscaler/node-template/ labelsPrefix nodeTemplatePrefix label/ taintsPrefix nodeTemplatePrefix taint/ )在AddResources流程中当检测到ng.PropagateASGTags开启时见 pkg/cfn/builder/nodegroup.go#L357-L370会调用GenerateClusterAutoscalerTags遍历节点组的 labels 与 taints逐个生成 ASG 标签并追加到节点组的标签列表中if api.IsEnabled(ng.PropagateASGTags) { var clusterTags []map[string]string GenerateClusterAutoscalerTags(ng, func(key, value string) { clusterTags append(clusterTags, map[string]string{ Key: key, Value: value, PropagateAtLaunch: true, }) }) tags append(tags, clusterTags...) ... }GenerateClusterAutoscalerTagspkg/cfn/builder/nodegroup.go#L379-L397同时支持NodeGroup与ManagedNodeGroup两种类型通过np.BaseNodeGroup().Labels取 labels并按节点组类型分支读取Taints字段其对应数据类型定义在 pkg/apis/eksctl.io/v1alpha5/types.go#L2143-L2147type NodeGroupTaint struct { Key string json:key,omitempty Value string json:value,omitempty Effect corev1.TaintEffect json:effect,omitempty }配置字段本身定义在 pkg/apis/eksctl.io/v1alpha5/types.go#L1999-L2001注释明确说明其作用Propagate all taints and labels to the ASG automatically.自动将全部 taints 与 labels 传播到 ASG。1.4 边界与限制50 个标签上限实现中有一个重要边界AWS ASG 的标签数量上限为50 个对应常量MaximumTagNumber 50见 pkg/cfn/builder/nodegroup.go#L30-L32。在追加传播标签后代码会检查总数是否超限超限时会直接返回错误if len(tags) MaximumTagNumber { return fmt.Errorf(number of tags is exceeding the configured amount %d, was: %d. ..., MaximumTagNumber, len(tags), len(clusterTags)) }原因在于节点组标签列表中已经固定包含Name标签与kubernetes.io/cluster/cluster-name: owned标签如果启用了 Autoscaler IAM 策略还会额外加上k8s.io/cluster-autoscaler/enabled与k8s.io/cluster-autoscaler/cluster-name两枚标签因此可用的传播标签余量实际不足 50 个。这一点在 pkg/cfn/builder/nodegroup_test.go#L1081-L1100 的测试用例中有完整覆盖构造 51 个 label 后断言模板构建报错信息包含 number of tags is exceeding the configured amount 50。对应的功能测试位于 pkg/cfn/builder/nodegroup_test.go#L1011-L1103验证了以下场景开启PropagateASGTags且有 labels/taints 时生成k8s.io/cluster-autoscaler/node-template/label/*与.../taint/*标签且PropagateAtLaunch为true关闭PropagateASGTags时跳过标签生成标签总数超过MaximumTagNumber时报错。1.5 用户文档中的完整上下文propagateASGTags的官方用户文档位于 userdocs/src/usage/autoscaling.md其中Scaling up from 0一节完整展示了三种做法手工编写 ASG 标签0.90.0 之前的方式把每个 label/taint 按k8s.io/cluster-autoscaler/node-template/label/key与.../taint/key格式逐一写进节点组的tags字段开启propagateASGTags: true自动传播0.90.0 新增并支持 managed 与 unmanaged 两类节点组配合eksctl create cluster --asg-access或节点组级iam.withAddonPolicies.autoScaler: true使 eksctl 同时写入k8s.io/cluster-autoscaler/enabled与k8s.io/cluster-autoscaler/clusterName标签保证 Autoscaler 能发现节点组。值得注意的是手工方式下 taint 的 Value 需要拼接为true:NoSchedule这种value:effect格式而自动传播方式下标签 Value 取自NodeGroupTaint.Value字段——文档示例中把 taint 简写为feaster: true:NoSchedule时传播生成的标签值即为true:NoSchedule。两种方式的标签格式保持一致可放心混用。二、架构改进AWS SDK v2 落地与 STS 服务迁移2.1 背景从 v1 到 v2 的长期演进0.90.0 的另一个重要改进是Set up AWS SDK v2 and migrate STS service (#4926)。从当前仓库的 go.mod 可以看到项目已引入完整的github.com/aws/aws-sdk-go-v2系列依赖如config、credentials、service/sts、service/cloudformation、service/ec2、service/eks、service/iam、service/ssm、service/outposts等且pkg目录下有 297 个 Go 文件直接使用 SDK v2。这标志着 eksctl 从 AWS SDK for Go v1 向 v2 迁移的工程化启动v2 提供了更现代的 API 风格context.Context贯穿、模块化拆分、灵活的配置加载为后续所有 AWS 服务逐步迁移奠定了基础。2.2 STS 服务的首批迁移实现STSAWS Security Token Service是第一个完成迁移的服务其抽象接口定义在 pkg/awsapi/sts.go当前接口只暴露了一个方法type STS interface { GetCallerIdentity(ctx context.Context, params *sts.GetCallerIdentityInput, optFns ...func(*sts.Options)) (*sts.GetCallerIdentityOutput, error) }客户端实例化与生命周期管理位于 pkg/eks/services_v2.go#L45-L78 的ServicesV2结构体中。两个值得注意的工程细节懒初始化 互斥锁ServicesV2用sync.Mutex保护所有 SDK 客户端的初始化见 pkg/eks/services_v2.go#L26-L43 的注释SDK clients are initialized lazily and guarded by a mutex避免并发场景下的竞态STS 禁用重试器STS 客户端特意配置了o.Retryer aws.NopRetryer{}并注释引用了 eksctl issue #705——这是为了避免 STS 调用在特定场景下被无谓地重试Endpoint 覆盖支持STS()通过getBaseEndpoint依次读取AWS_STS_ENDPOINT、AWS_ENDPOINT_URL_STS、AWS_ENDPOINT_URL环境变量便于本地开发与自定义 Endpoint 场景。此外ServicesV2还提供了STSPresigner()预签名 STS 客户端用于向 Kubernetes 集群内部传递 AWS 凭证的场景。2.3 STS 在关键调用链中的角色迁移后的 STS 服务被用于多个核心路径最典型的是集群 Provider 的认证检查checkAuth见 pkg/eks/api.go#L289-L299func (c *ClusterProvider) checkAuth(ctx context.Context) (*sts.GetCallerIdentityOutput, error) { output, err : c.AWSProvider.STS().GetCallerIdentity(ctx, sts.GetCallerIdentityInput{}) if err ! nil { return nil, fmt.Errorf(checking AWS STS access – cannot get role ARN for current session: %w, err) } ... }checkAuth返回的Arn与Account会被用于填充集群的 IAM Role ARN 与账号 ID见 pkg/eks/api.go#L143-L153。集成测试也直接使用 v2 的 STS 客户端例如 integration/tests/params.go#L278-L298 通过GetCallerIdentity解析用户 ID为测试集群名生成前缀。另外pkg/connector 中的 EKS Connector 凭证协商同样依赖STSPresigner与GetCallerIdentity见 pkg/connector/connector.go说明 STS 迁移已深入连接器这一独立模块。可以推断本次迁移选择 STS 作为突破口是因为它接口简单仅GetCallerIdentity一个核心操作且被集群创建、认证检查、集成测试等所有关键路径高频依赖先完成迁移可以立即验证 v2 的配置加载、重试策略、Endpoint 覆盖等机制为后续 CloudFormation、EC2、EKS 等重头服务的迁移趟平道路。三、文档改进addon 无策略源时的行为说明3.1 该 PR 澄清了什么第三个条目#4999是文档更新目的是回答一个高频疑问创建 addon 时如果没有指定任何 IAM 策略源会发生什么更新后的文档位于 userdocs/src/usage/addons.md#L60-L66明确给出了答案You can specify at most one ofattachPolicy,attachPolicyARNsandserviceAccountRoleARN. If none of these are specified, the addon will be created with a role that has all recommended policies attached.即 addon 定义中可配置三个互斥的策略源——attachPolicy内联策略文档、attachPolicyARNs托管策略 ARN 列表、serviceAccountRoleARN复用已存在的服务账户角色 ARN三选一如果三者都未指定addon 将使用附带全部推荐策略的 IAM 角色创建。该文档同一处还补充了一个重要提醒为 addon 附加策略要求集群已启用 OIDC否则传入的策略会被忽略。完整的 addon 配置示例含三个策略源选项与可选的version、tags字段见 userdocs/src/usage/addons.md#L20-L58。相关实操命令包括# 创建集群时一并创建 addon eksctl create cluster -f config.yaml # 集群创建后显式创建 addon eksctl create addon -f config.yaml eksctl create addon --name vpc-cni --version 1.7.5 --service-account-role-arn role-arn3.2 为什么这个澄清重要对于 vpc-cni、aws-ebs-csi-driver 这类官方 addonAWS EKS 平台本身维护着推荐策略清单。在未提供任何策略源的情况下走推荐策略路径意味着用户可以在不手工编写 IAM 策略的前提下安全地创建官方 addon这是开箱即用体验的关键一环。文档将这一隐式行为显式化降低了用户对我的 addon 为什么自动获得了一个角色的困惑。四、致谢与版本演进脉络0.90.0 的发布说明末尾向贡献者 midgleyc 致以感谢。从版本演进脉络看0.90.0 处于 eksctl 功能快速迭代与架构现代化并行推进的时期propagateASGTags的能力在后续版本中持续演进——例如 0.99.0、0.109.0、0.117.0 的发布说明中仍有关于 Cluster Autoscaler 标签传播相关调整的提及说明该特性已成为 Autoscaler 工作流的基础设施AWS SDK v2 迁移自此开始逐服务推进最终pkg/awsapi下形成了覆盖 CloudFormation、EC2、EKS、IAM、SSM、Outposts、ELB/ELBV2、CloudTrail、CloudWatch Logs、Autoscaling 等服务的完整 v2 接口集见 pkg/awsapi 目录。五、升级与使用建议想用 从 0 扩容在节点组配置中设置desiredCapacity: 0并开启propagateASGTags: true同时通过--asg-access或iam.withAddonPolicies.autoScaler: true写入 Autoscaler 发现标签。注意总标签数不得超过 50含Name、kubernetes.io/cluster/*等内置标签。关注 SDK 迁移STS 已完成 v2 迁移重试与 Endpoint 行为与 v1 时代略有差异STS 禁用重试器如你在自定义 Endpoint/本地模拟环境如 LocalStack中运行 eksctl可通过AWS_STS_ENDPOINT等环境变量覆盖。addon 权限创建官方 addon 且不指定任何策略源时eksctl 将为其绑定 AWS 推荐策略如需自定义权限在attachPolicy、attachPolicyARNs、serviceAccountRoleARN中三选一并确保集群已启用 OIDC。以上变化均可在当前仓库中直接验证配置字段见 pkg/apis/eksctl.io/v1alpha5/types.go、模板构建见 pkg/cfn/builder/nodegroup.go、测试覆盖见 pkg/cfn/builder/nodegroup_test.go、用户指南见 userdocs/src/usage/autoscaling.md 与 userdocs/src/usage/addons.md。赞分享云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载相关推荐eksctl 0.104.0 发布解读aws-node 插件更新与 aws-iam-authenticator 依赖移除eksctl 0.104.0 发布解读aws node 插件更新与 aws iam authenticator 依赖移除 导读 本文解读 eksctl v0.云原生容器编排DevOpseksctl 0.94.0 发布解读EC2/IAM 全面迁移 aws-sdk-go-v2、override 集成测试与可用区过滤修复eksctl 0.94.0 发布解读EC2/IAM 全面迁移 aws sdk go v2、override 集成测试与可用区过滤修复 导读 本文围绕 eks云原生容器编排DevOpseksctl 0.91.0 版本解析移除旧版 al2/ubuntu 引导路径全面迁移 AWS SDK for Go v2eksctl 0.91.0 版本解析移除旧版 al2/ubuntu 引导路径全面迁移 AWS SDK for Go v2 本文基于 eksctl 官方发布说云原生容器编排DevOps创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考