云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载本文基于 eksctl 仓库中的官方发布说明 docs/release_notes/0.151.0.md 展开。v0.151.0 是一次以节点镜像灵活性为主题的版本它让自管self-managedWindows 节点组与 EKS 托管managedUbuntu 节点组都可以使用自定义 AMI同时移除了对 EKS 1.22 的支持并修复了多可用区子网选择、实例类型可用性分页等多个问题。读完本文你可以掌握自定义 AMI 在两类节点组上的配置方式、配套的校验规则与限制条件并理解各修复项在源码层面的实现位置。版本概览v0.151.0 的变更按官方发布说明分为以下类别条目均对应具体 PR 编号类别变更内容Features自管 Windows 节点组支持自定义 AMI#6804EKS 托管节点组支持自定义 Ubuntu AMI#6850Improvements移除对 EKS 1.22 的支持#6704Bug Fixes修复 CI 中Post Cache go-build and mod步骤的 tar 错误#6840修复 release 版本 link-time 变量设置#6841当同一 AZ 存在多个子网且未提供 VPC 配置时只选择一个子网#6814对DescribeInstanceTypeOfferings响应做分页处理#6832Maintenance依赖升级#6852、#6859清理 Flux 集成代码#6836下面逐项展开并结合仓库源码说明这些能力背后的实现与约束。特性一自管 Windows 节点组支持自定义 AMI配置方式在自管节点组nodeGroups中通过ami字段指定自定义镜像 ID并显式声明amiFamily。以 Windows 节点组为例参考 examples/14-windows-nodes.yaml 的写法加上自定义镜像后形如nodeGroups: - name: windows-windows amiFamily: WindowsServer2019CoreContainer # 必须显式指定 ami: ami-0123456789abcdef0 # 自定义 AMI ID instanceType: c5.large scalingConfig: minSize: 1 maxSize: 3ami字段定义在 pkg/apis/eksctl.io/v1alpha5/types.go 的NodeGroupBase中自管与托管节点组共用该基础结构注释中说明其可取值包括auto-ssm、auto、static以及具体的 AMI ID。校验规则为什么 Windows 是特殊的一族v0.151.0 之前使用自定义 AMI 时校验逻辑会强制要求overrideBootstrapCommand覆盖引导脚本因为 eksctl 需要为节点生成启动脚本。Windows 节点的引导机制不同通过 Windows 启动脚本而非 Linux 风格的 bootstrap 命令因此 #6804 将 Windows 镜像家族从该强制要求中豁免。这一豁免可以直接在自管节点组校验函数ValidateNodeGroup中看到见 pkg/apis/eksctl.io/v1alpha5/validation.goif ng.AMI ! ng.AMIFamily { return errors.New(when using a custom AMI, amiFamily needs to be explicitly set via config file or via --node-ami-family flag) } ... if ng.AMI ! ng.OverrideBootstrapCommand nil ng.AMIFamily ! NodeImageFamilyAmazonLinux2023 !IsBottlerocketImage(ng.AMIFamily) !IsWindowsImage(ng.AMIFamily) { return fmt.Errorf(%[1]s.overrideBootstrapCommand is required when using a custom AMI based on %s (%[1]s.ami), path, ng.AMIFamily) }从源码结构看自管节点组使用自定义 AMI 时的约束可归纳为约束说明amiFamily必填设置ami后必须显式给出amiFamily配置文件或--node-ami-family标志否则直接报错overrideBootstrapCommand除 AmazonLinux2023、Bottlerocket 家族和 Windows 家族外使用自定义 AMI 必须提供引导命令覆盖AMI ID 格式托管侧校验中通过IsAMI()检查 ID 合法性ami-前缀格式Windows 镜像家族常量本身定义在 pkg/apis/eksctl.io/v1alpha5/types.go 一带包括WindowsServer2019CoreContainer、WindowsServer2022CoreContainer、WindowsServer2025CoreContainer及对应 Full 变体等IsWindowsImage()判断函数位于 pkg/apis/eksctl.io/v1alpha5/validation.go。自动解析 AMI 的背景机制当不指定ami时eksctl 通过 pkg/ami/auto_resolver.go 中的AutoResolver.Resolve自动解析默认 AMIMakeImageSearchPatterns会为每个镜像家族生成按 Kubernetes 版本匹配的镜像名前缀如Windows_Server-2019-English-Core-EKS_Optimized-%v-*再按OwnerAccountIDWindows 镜像属于微软账户801119661308调用 EC2 API 查找。理解了这条自动解析链路就能明白自定义 AMI的价值所在它让用户可以完全绕过按版本前缀匹配官方镜像的流程直接使用自行构建、加固或预装软件的镜像。特性二EKS 托管节点组支持自定义 Ubuntu AMI支持的家族范围对于托管节点组managedNodeGroups#6850 将自定义 AMI 允许使用的镜像家族扩展到了 Ubuntu。校验逻辑位于 pkg/apis/eksctl.io/v1alpha5/validation.gocase ng.AMI ! : if !IsAMI(ng.AMI) { return fmt.Errorf(invalid AMI %q (%s.%s), ng.AMI, path, ami) } if ng.AMIFamily { return errors.New(when using a custom AMI, amiFamily needs to be explicitly set via config file or via --node-ami-family flag) } if !IsAmazonLinuxImage(ng.AMIFamily) !IsBottlerocketImage(ng.AMIFamily) !IsUbuntuImage(ng.AMIFamily) { return fmt.Errorf(cannot set amiFamily to %s when using a custom AMI for managed nodes, only %s are supported, ng.AMIFamily, ...) } if ng.OverrideBootstrapCommand nil ng.AMIFamily ! NodeImageFamilyAmazonLinux2023 !IsBottlerocketImage(ng.AMIFamily) { return fmt.Errorf(%[1]s.overrideBootstrapCommand is required when using a custom AMI based on %s (%[1]s.ami), path, ng.AMIFamily) }也就是说托管节点组上自定义 AMI 支持的家族为 Amazon Linux 2 / AL2023、Bottlerocket 与 Ubuntu各版本变体且除 AL2023 与 Bottlerocket 外Ubuntu 自定义 AMI 必须提供overrideBootstrapCommand以下字段与自定义 AMI 互斥设置即报错maxPodsPerNode、ssh.enableSSM、releaseVersion对应源码中的notSupportedWithCustomAMIErr分支。与 launch template 的互斥约束托管节点组若改用 launch template 内置ImageId的方式指定自定义镜像还有一层独立校验见 pkg/cfn/builder/managed_nodegroup.go 的validateLaunchTemplatelaunch template 设置了ImageId时UserData节点引导脚本必须存在否则报node bootstrapping script (UserData) must be set when using a custom AMImanagedNodeGroup.ami与managedNodeGroup.releaseVersion不能与 launch template 中的ImageId同时设置launch template 中不能设置 IAM instance profile由 eksctl 管理。同一文件中的测试用例 pkg/cfn/builder/managed_launch_template_test.go 覆盖了 Launch Template with custom AMI 等场景可作为行为验证参考。配置示例参考 examples/15-managed-nodes.yaml 的结构Ubuntu 自定义 AMI 的托管节点组配置形如managedNodeGroups: - name: ubuntu-custom-ami amiFamily: Ubuntu2004 # Ubuntu 家族之一 ami: ami-0fedcba9876543210 # 自定义 Ubuntu EKS 优化 AMI instanceType: m5.large minSize: 2 maxSize: 4 overrideBootstrapCommand: | # 非 AL2023/Bottlerocket 时必填 ...注意托管节点组无法像自管节点组那样直接写instanceType之外的引导细节maxPodsPerNode、enableSSM、releaseVersion均被禁用配置时需提前确认这些限制。版本支持变更移除 EKS 1.22#6704 移除了对 Kubernetes 1.22 控制面版本的支持。在 eksctl 中版本能力的核心是 pkg/eks/versions_manager.go 中的ClusterVersionsManager它通过 EKS API 的DescribeClusterVersions拉取各版本状态构建supportedVersions列表并由resolveDeprecatedVersions以最老受支持版本为基准推导出所有更早的历史版本为 deprecated见 pkg/eks/versions_manager.goValidateVersion对已废弃版本给出明确的错误信息如invalid version, 1.22 is no longer supported, supported values: ...见 pkg/eks/versions_manager.go 中ValidateVersion的错误文案ResolveUpgradeVersion决定eksctl upgrade/update的目标版本仅允许逐个小版本升级或回退。从源码结构看移除 1.22 支持意味着当 AWS 侧 API 不再把 1.22 列为受支持版本时eksctl 会将其归入 deprecated 列表用户若继续用--version 1.22创建集群或直接升级跨越该版本都会得到上述报错。对于仍运行 1.22 的集群正确路径是先按每次一个小版本的顺序逐版本升级。缺陷修复解析多子网 AZ 的选择问题#6814问题场景当某个可用区AZ下存在多个子网且用户没有通过vpc.subnets显式指定子网时此前的逻辑可能在子网挑选上出现歧义修复后eksctl 会在存在多个子网的 AZ 中选择一个子网保证自动分配的子网集合可用且无冲突。该修复所处的区域逻辑在 pkg/az/az.go 中GetAvailabilityZones先经DescribeAvailabilityZones发现可用 AZ再经FilterBasedOnAvailability过滤掉不支持所选实例类型的 AZ见 pkg/az/az.go。相关子网分配行为可在 pkg/cfn/builder/nodegroup_subnets_test.go 的表驱动测试如 EFA enabled with multiple subnets selects only one subnet 条目中验证。实例类型可用性查询分页#6832问题场景查询 EC2 实例类型在某区域各 AZ 的可用性时若一次调用返回结果超过 API 单页上限会丢失数据进而导致 AZ 过滤判断不完整。修复后pkg/az/az.go 的GetInstanceTypeOfferings改用分页器遍历完整结果集p : ec2.NewDescribeInstanceTypeOfferingsPaginator(ec2API, ec2.DescribeInstanceTypeOfferingsInput{ Filters: []ec2types.Filter{ {Name: aws.String(instance-type), Values: instances}, {Name: aws.String(location), Values: zones}, }, LocationType: ec2types.LocationTypeAvailabilityZone, MaxResults: aws.Int32(100), }) for p.HasMorePages() { output, err : p.NextPage(ctx) ... instanceTypeOfferings append(instanceTypeOfferings, output.InstanceTypeOfferings...) }分页完成后结果被整理为zoneToInstanceMap[az][instanceType]结构供上文提到的 AZ 过滤使用。对于配置了大量实例类型或跨多 AZ 的集群这个修复能避免某 AZ 明明支持某实例类型却被误判为不支持的问题。工程类修复#6840、#6841CI tar 错误修复了构建缓存步骤Post Cache go-build and mod中 tar 命令的错误属于持续集成管线维护不影响运行时代码link-time 变量修复了 release 版本 link-time 变量设置。这与版本信息的注入链路相关——pkg/version/version.go 中的Info结构持有Version、PreReleaseID及BuildMetadataGitCommit、BuildDate由go generate与构建期注入填充GetVersion()会按是否 release candidate 决定是否附带gitCommit.buildDate形式的构建元数据见 pkg/version/version.go。修复确保了发布构建中该元数据被正确写入。维护项说明依赖升级#6852、#6859常规的 Go 模块依赖更新可结合仓库根目录 go.mod 查看当前锁定的依赖版本Flux 集成清理#6836对 GitOps/Flux 相关代码做清理。Flux 的运行时逻辑集中在 pkg/flux/flux.go 与 pkg/actions/flux/ 目录清理属于代码结构优化不改变--flux相关开关的对外行为。使用建议与升级注意升级到 v0.151.0 前确认没有工作流依赖--version 1.22或 1.22 集群的直接升级路径1.22 集群需逐版本升级。使用自定义 AMI 时无论自管还是托管必须显式设置amiFamily托管 Ubuntu 自定义 AMI 需提供overrideBootstrapCommand且不能同时设置maxPodsPerNode、enableSSM、releaseVersion自管节点组中AL2023、Bottlerocket 与 Windows 家族可豁免overrideBootstrapCommand要求其他 Linux 家族如 AL2、Ubuntu 自管仍需提供托管节点组若走 launch template 的ImageId路线则模板内必须包含UserData且与ami/releaseVersion字段互斥。多 AZ 集群若你在同一 AZ 规划了多个子网且未显式指定vpc.subnets升级到该版本可获得更确定的子网选择行为涉及大量实例类型的配置也会受益于DescribeInstanceTypeOfferings的分页修复。以上所有源码路径与行为描述均基于当前仓库代码如需进一步深入建议从 pkg/apis/eksctl.io/v1alpha5/validation.go 的ValidateNodeGroup与validateManagedNodeGroup托管侧自定义 AMI 校验两个入口读起。赞分享云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载相关推荐eksctl 0.101.0 版本解读NVIDIA 节点组自动容忍、托管 Bottlerocket GPU 节点与并行 Drain 能力eksctl 0.101.0 版本解读NVIDIA 节点组自动容忍、托管 Bottlerocket GPU 节点与并行 Drain 能力 导读 本文围绕 ek云原生容器编排DevOps解读 eksctl 0.110.0 版本发布Karpenter v0.15.0 支持、Windows/Ubuntu GPU 节点组与中国区 IPv6 修复解读 eksctl 0.110.0 版本发布Karpenter v0.15.0 支持、Windows/Ubuntu GPU 节点组与中国区 IPv6 修复 本云原生容器编排DevOpseksctl v0.175.0 修复解读Bottlerocket 托管节点组升级改为显式携带 Version 字段eksctl v0.175.0 修复解读Bottlerocket 托管节点组升级改为显式携带 Version 字段 本文围绕 eksctl 发布说明 docs云原生容器编排DevOps创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载本文基于 eksctl 仓库中的官方发布说明 docs/release_notes/0.151.0.md 展开。v0.151.0 是一次以节点镜像灵活性为主题的版本它让自管self-managedWindows 节点组与 EKS 托管managedUbuntu 节点组都可以使用自定义 AMI同时移除了对 EKS 1.22 的支持并修复了多可用区子网选择、实例类型可用性分页等多个问题。读完本文你可以掌握自定义 AMI 在两类节点组上的配置方式、配套的校验规则与限制条件并理解各修复项在源码层面的实现位置。版本概览v0.151.0 的变更按官方发布说明分为以下类别条目均对应具体 PR 编号类别变更内容Features自管 Windows 节点组支持自定义 AMI#6804EKS 托管节点组支持自定义 Ubuntu AMI#6850Improvements移除对 EKS 1.22 的支持#6704Bug Fixes修复 CI 中Post Cache go-build and mod步骤的 tar 错误#6840修复 release 版本 link-time 变量设置#6841当同一 AZ 存在多个子网且未提供 VPC 配置时只选择一个子网#6814对DescribeInstanceTypeOfferings响应做分页处理#6832Maintenance依赖升级#6852、#6859清理 Flux 集成代码#6836下面逐项展开并结合仓库源码说明这些能力背后的实现与约束。特性一自管 Windows 节点组支持自定义 AMI配置方式在自管节点组nodeGroups中通过ami字段指定自定义镜像 ID并显式声明amiFamily。以 Windows 节点组为例参考 examples/14-windows-nodes.yaml 的写法加上自定义镜像后形如nodeGroups: - name: windows-windows amiFamily: WindowsServer2019CoreContainer # 必须显式指定 ami: ami-0123456789abcdef0 # 自定义 AMI ID instanceType: c5.large scalingConfig: minSize: 1 maxSize: 3ami字段定义在 pkg/apis/eksctl.io/v1alpha5/types.go 的NodeGroupBase中自管与托管节点组共用该基础结构注释中说明其可取值包括auto-ssm、auto、static以及具体的 AMI ID。校验规则为什么 Windows 是特殊的一族v0.151.0 之前使用自定义 AMI 时校验逻辑会强制要求overrideBootstrapCommand覆盖引导脚本因为 eksctl 需要为节点生成启动脚本。Windows 节点的引导机制不同通过 Windows 启动脚本而非 Linux 风格的 bootstrap 命令因此 #6804 将 Windows 镜像家族从该强制要求中豁免。这一豁免可以直接在自管节点组校验函数ValidateNodeGroup中看到见 pkg/apis/eksctl.io/v1alpha5/validation.goif ng.AMI ! ng.AMIFamily { return errors.New(when using a custom AMI, amiFamily needs to be explicitly set via config file or via --node-ami-family flag) } ... if ng.AMI ! ng.OverrideBootstrapCommand nil ng.AMIFamily ! NodeImageFamilyAmazonLinux2023 !IsBottlerocketImage(ng.AMIFamily) !IsWindowsImage(ng.AMIFamily) { return fmt.Errorf(%[1]s.overrideBootstrapCommand is required when using a custom AMI based on %s (%[1]s.ami), path, ng.AMIFamily) }从源码结构看自管节点组使用自定义 AMI 时的约束可归纳为约束说明amiFamily必填设置ami后必须显式给出amiFamily配置文件或--node-ami-family标志否则直接报错overrideBootstrapCommand除 AmazonLinux2023、Bottlerocket 家族和 Windows 家族外使用自定义 AMI 必须提供引导命令覆盖AMI ID 格式托管侧校验中通过IsAMI()检查 ID 合法性ami-前缀格式Windows 镜像家族常量本身定义在 pkg/apis/eksctl.io/v1alpha5/types.go 一带包括WindowsServer2019CoreContainer、WindowsServer2022CoreContainer、WindowsServer2025CoreContainer及对应 Full 变体等IsWindowsImage()判断函数位于 pkg/apis/eksctl.io/v1alpha5/validation.go。自动解析 AMI 的背景机制当不指定ami时eksctl 通过 pkg/ami/auto_resolver.go 中的AutoResolver.Resolve自动解析默认 AMIMakeImageSearchPatterns会为每个镜像家族生成按 Kubernetes 版本匹配的镜像名前缀如Windows_Server-2019-English-Core-EKS_Optimized-%v-*再按OwnerAccountIDWindows 镜像属于微软账户801119661308调用 EC2 API 查找。理解了这条自动解析链路就能明白自定义 AMI的价值所在它让用户可以完全绕过按版本前缀匹配官方镜像的流程直接使用自行构建、加固或预装软件的镜像。特性二EKS 托管节点组支持自定义 Ubuntu AMI支持的家族范围对于托管节点组managedNodeGroups#6850 将自定义 AMI 允许使用的镜像家族扩展到了 Ubuntu。校验逻辑位于 pkg/apis/eksctl.io/v1alpha5/validation.gocase ng.AMI ! : if !IsAMI(ng.AMI) { return fmt.Errorf(invalid AMI %q (%s.%s), ng.AMI, path, ami) } if ng.AMIFamily { return errors.New(when using a custom AMI, amiFamily needs to be explicitly set via config file or via --node-ami-family flag) } if !IsAmazonLinuxImage(ng.AMIFamily) !IsBottlerocketImage(ng.AMIFamily) !IsUbuntuImage(ng.AMIFamily) { return fmt.Errorf(cannot set amiFamily to %s when using a custom AMI for managed nodes, only %s are supported, ng.AMIFamily, ...) } if ng.OverrideBootstrapCommand nil ng.AMIFamily ! NodeImageFamilyAmazonLinux2023 !IsBottlerocketImage(ng.AMIFamily) { return fmt.Errorf(%[1]s.overrideBootstrapCommand is required when using a custom AMI based on %s (%[1]s.ami), path, ng.AMIFamily) }也就是说托管节点组上自定义 AMI 支持的家族为 Amazon Linux 2 / AL2023、Bottlerocket 与 Ubuntu各版本变体且除 AL2023 与 Bottlerocket 外Ubuntu 自定义 AMI 必须提供overrideBootstrapCommand以下字段与自定义 AMI 互斥设置即报错maxPodsPerNode、ssh.enableSSM、releaseVersion对应源码中的notSupportedWithCustomAMIErr分支。与 launch template 的互斥约束托管节点组若改用 launch template 内置ImageId的方式指定自定义镜像还有一层独立校验见 pkg/cfn/builder/managed_nodegroup.go 的validateLaunchTemplatelaunch template 设置了ImageId时UserData节点引导脚本必须存在否则报node bootstrapping script (UserData) must be set when using a custom AMImanagedNodeGroup.ami与managedNodeGroup.releaseVersion不能与 launch template 中的ImageId同时设置launch template 中不能设置 IAM instance profile由 eksctl 管理。同一文件中的测试用例 pkg/cfn/builder/managed_launch_template_test.go 覆盖了 Launch Template with custom AMI 等场景可作为行为验证参考。配置示例参考 examples/15-managed-nodes.yaml 的结构Ubuntu 自定义 AMI 的托管节点组配置形如managedNodeGroups: - name: ubuntu-custom-ami amiFamily: Ubuntu2004 # Ubuntu 家族之一 ami: ami-0fedcba9876543210 # 自定义 Ubuntu EKS 优化 AMI instanceType: m5.large minSize: 2 maxSize: 4 overrideBootstrapCommand: | # 非 AL2023/Bottlerocket 时必填 ...注意托管节点组无法像自管节点组那样直接写instanceType之外的引导细节maxPodsPerNode、enableSSM、releaseVersion均被禁用配置时需提前确认这些限制。版本支持变更移除 EKS 1.22#6704 移除了对 Kubernetes 1.22 控制面版本的支持。在 eksctl 中版本能力的核心是 pkg/eks/versions_manager.go 中的ClusterVersionsManager它通过 EKS API 的DescribeClusterVersions拉取各版本状态构建supportedVersions列表并由resolveDeprecatedVersions以最老受支持版本为基准推导出所有更早的历史版本为 deprecated见 pkg/eks/versions_manager.goValidateVersion对已废弃版本给出明确的错误信息如invalid version, 1.22 is no longer supported, supported values: ...见 pkg/eks/versions_manager.go 中ValidateVersion的错误文案ResolveUpgradeVersion决定eksctl upgrade/update的目标版本仅允许逐个小版本升级或回退。从源码结构看移除 1.22 支持意味着当 AWS 侧 API 不再把 1.22 列为受支持版本时eksctl 会将其归入 deprecated 列表用户若继续用--version 1.22创建集群或直接升级跨越该版本都会得到上述报错。对于仍运行 1.22 的集群正确路径是先按每次一个小版本的顺序逐版本升级。缺陷修复解析多子网 AZ 的选择问题#6814问题场景当某个可用区AZ下存在多个子网且用户没有通过vpc.subnets显式指定子网时此前的逻辑可能在子网挑选上出现歧义修复后eksctl 会在存在多个子网的 AZ 中选择一个子网保证自动分配的子网集合可用且无冲突。该修复所处的区域逻辑在 pkg/az/az.go 中GetAvailabilityZones先经DescribeAvailabilityZones发现可用 AZ再经FilterBasedOnAvailability过滤掉不支持所选实例类型的 AZ见 pkg/az/az.go。相关子网分配行为可在 pkg/cfn/builder/nodegroup_subnets_test.go 的表驱动测试如 EFA enabled with multiple subnets selects only one subnet 条目中验证。实例类型可用性查询分页#6832问题场景查询 EC2 实例类型在某区域各 AZ 的可用性时若一次调用返回结果超过 API 单页上限会丢失数据进而导致 AZ 过滤判断不完整。修复后pkg/az/az.go 的GetInstanceTypeOfferings改用分页器遍历完整结果集p : ec2.NewDescribeInstanceTypeOfferingsPaginator(ec2API, ec2.DescribeInstanceTypeOfferingsInput{ Filters: []ec2types.Filter{ {Name: aws.String(instance-type), Values: instances}, {Name: aws.String(location), Values: zones}, }, LocationType: ec2types.LocationTypeAvailabilityZone, MaxResults: aws.Int32(100), }) for p.HasMorePages() { output, err : p.NextPage(ctx) ... instanceTypeOfferings append(instanceTypeOfferings, output.InstanceTypeOfferings...) }分页完成后结果被整理为zoneToInstanceMap[az][instanceType]结构供上文提到的 AZ 过滤使用。对于配置了大量实例类型或跨多 AZ 的集群这个修复能避免某 AZ 明明支持某实例类型却被误判为不支持的问题。工程类修复#6840、#6841CI tar 错误修复了构建缓存步骤Post Cache go-build and mod中 tar 命令的错误属于持续集成管线维护不影响运行时代码link-time 变量修复了 release 版本 link-time 变量设置。这与版本信息的注入链路相关——pkg/version/version.go 中的Info结构持有Version、PreReleaseID及BuildMetadataGitCommit、BuildDate由go generate与构建期注入填充GetVersion()会按是否 release candidate 决定是否附带gitCommit.buildDate形式的构建元数据见 pkg/version/version.go。修复确保了发布构建中该元数据被正确写入。维护项说明依赖升级#6852、#6859常规的 Go 模块依赖更新可结合仓库根目录 go.mod 查看当前锁定的依赖版本Flux 集成清理#6836对 GitOps/Flux 相关代码做清理。Flux 的运行时逻辑集中在 pkg/flux/flux.go 与 pkg/actions/flux/ 目录清理属于代码结构优化不改变--flux相关开关的对外行为。使用建议与升级注意升级到 v0.151.0 前确认没有工作流依赖--version 1.22或 1.22 集群的直接升级路径1.22 集群需逐版本升级。使用自定义 AMI 时无论自管还是托管必须显式设置amiFamily托管 Ubuntu 自定义 AMI 需提供overrideBootstrapCommand且不能同时设置maxPodsPerNode、enableSSM、releaseVersion自管节点组中AL2023、Bottlerocket 与 Windows 家族可豁免overrideBootstrapCommand要求其他 Linux 家族如 AL2、Ubuntu 自管仍需提供托管节点组若走 launch template 的ImageId路线则模板内必须包含UserData且与ami/releaseVersion字段互斥。多 AZ 集群若你在同一 AZ 规划了多个子网且未显式指定vpc.subnets升级到该版本可获得更确定的子网选择行为涉及大量实例类型的配置也会受益于DescribeInstanceTypeOfferings的分页修复。以上所有源码路径与行为描述均基于当前仓库代码如需进一步深入建议从 pkg/apis/eksctl.io/v1alpha5/validation.go 的ValidateNodeGroup与validateManagedNodeGroup托管侧自定义 AMI 校验两个入口读起。赞分享云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载相关推荐eksctl 0.101.0 版本解读NVIDIA 节点组自动容忍、托管 Bottlerocket GPU 节点与并行 Drain 能力eksctl 0.101.0 版本解读NVIDIA 节点组自动容忍、托管 Bottlerocket GPU 节点与并行 Drain 能力 导读 本文围绕 ek云原生容器编排DevOps解读 eksctl 0.110.0 版本发布Karpenter v0.15.0 支持、Windows/Ubuntu GPU 节点组与中国区 IPv6 修复解读 eksctl 0.110.0 版本发布Karpenter v0.15.0 支持、Windows/Ubuntu GPU 节点组与中国区 IPv6 修复 本云原生容器编排DevOpseksctl v0.175.0 修复解读Bottlerocket 托管节点组升级改为显式携带 Version 字段eksctl v0.175.0 修复解读Bottlerocket 托管节点组升级改为显式携带 Version 字段 本文围绕 eksctl 发布说明 docs云原生容器编排DevOps创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
