云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载本篇围绕 eksctl v0.144.0 的官方发布说明docs/release_notes/0.144.0.md展开逐项解读该版本引入的核心能力通过vpc.hostnameType创建资源型主机名子网、为 Kubernetes 1.251.27 集群的 CoreDNS 启用ready插件与health.lameduck安全关停机制、更新 aws-load-balancer-controller 的 IAM 策略语句以及针对DescribeUpdate重试逻辑、ALB 清理、Windows 节点默认卷名的多项缺陷修复。读完本文你可以掌握hostnameType的取值与限制条件、CoreDNS 资产按控制面版本加载的原理并能定位到每一处变更对应的源码与集成测试。v0.144.0 变更总览该版本共包含 1 项功能Features、2 项改进Improvements、3 项缺陷修复Bug Fixes、3 项维护Maintenance以及 1 项文档Documentation变更完整清单如下类别变更内容对应 PRFeatures允许创建使用资源型主机名resource-based hostnames的子网#6651Improvements更新 loadbalancer controller 的 IAM policy statement#6655Improvements为 1.25、1.26、1.27 版本的 CoreDNS 移植 ready 插件并启用 health.lameduck 安全关停#6630Bug Fixes调用eks:DescribeUpdate时仅对合适的 API 错误进行重试#6645Bug Fixes基于spec.ingressClassName清理 ALB并覆盖 ALB 安全组#6389Bug Fixes将 Windows 节点默认卷名设置为/dev/sda1#6638Maintenance清理 README 与贡献文档修正格式和拼写#6660Maintenance修复 Trainium 与 Inferentia 集成测试的日志栈事件逻辑#6649Maintenance将 schemer 依赖从 v0.0.0-2021 升级至 v0.0.0-2023#6646Documentation生成 ATTRIBUTIONS.md 文件#6647本节后续将逐项结合仓库源码展开。新功能vpc.hostnameType支持资源型主机名子网v0.144.0 最重要的功能更新#6651是允许 eksctl 在创建集群 VPC 时为子网指定基于 EC2 资源名称的主机名resource-name而不是默认的基于 IP 的主机名ip-name。这样启动在该子网中的实例其私有 DNS 名会形如资源名称.region.compute.internal而非IP 点分十进制.region.compute.internal。配置方式与限制条件该功能通过 ClusterConfig 的vpc段下的hostnameType字段配置。字段定义见 vpc.go// HostnameType is the type of hostname to use for EC2 instances. HostnameType string json:hostnameType,omitempty一个可直接复制的完整示例来自 examples/02-custom-vpc-cidr-no-nodes.yamlapiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cluster-2 region: eu-north-1 vpc: cidr: 10.10.0.0/16 autoAllocateIPv6: true hostnameType: resource-name # disable public access to endpoint and only allow private access clusterEndpoints: publicAccess: false privateAccess: true nodeGroups: []配置校验逻辑位于 validation.go其中包含两条明确的适用前提与限制if c.VPC.HostnameType ! { if c.HasAnySubnets() { return errors.New(vpc.hostnameType is not supported with a pre-existing VPC) } var hostnameType ec2types.HostnameType found : false for _, h : range hostnameType.Values() { if h ec2types.HostnameType(c.VPC.HostnameType) { found true break } } if !found { return fmt.Errorf(invalid value %q for vpc.hostnameType; supported values are %v, c.VPC.HostnameType, hostnameType.Values()) } }从源码结构看可以归纳出以下使用约束仅适用于 eksctl 托管的新建 VPC如果配置了已有子网vpc.subnets即“已有 VPC”场景会直接报vpc.hostnameType is not supported with a pre-existing VPC错误取值必须合法取值范围由 AWS SDK 的ec2types.HostnameType枚举决定合法值为ip-name与resource-name否则会收到invalid value ... for vpc.hostnameType报错。这些约束在 validation_test.go 中有对应的用例覆盖非法值invalid报错、ip-name与resource-name通过校验、以及在已有 VPC设置了subnets场景下拒绝该字段。底层实现CloudFormation 模板中的 PrivateDnsNameOptionsOnLaunch当hostnameType非空时eksctl 会在生成的 CloudFormation 模板里为每个子网追加PrivateDnsNameOptionsOnLaunch属性。核心调用链是addSubnets→maybeSetHostnameType见 vpc_ipv4.go 与 vpc_ipv4.gosubnet : gfnec2.Subnet{ AvailabilityZone: gfnt.NewString(az), CidrBlock: gfnt.NewString(s.CIDR.String()), VpcId: v.vpcID, } maybeSetHostnameType(v.clusterConfig.VPC, subnet)func maybeSetHostnameType(vpc *api.ClusterVPC, subnet *gfnec2.Subnet) { if hostnameType : vpc.HostnameType; hostnameType ! { subnet.PrivateDnsNameOptionsOnLaunch gfnec2.Subnet_PrivateDnsNameOptionsOnLaunch{ HostnameType: gfnt.NewString(hostnameType), } } }即最终渲染出的AWS::EC2::Subnet资源会带上PrivateDnsNameOptionsOnLaunch: { HostnameType: resource-name }。IPv6 路径同样经过同一函数见 vpc_ipv6.go因此该能力对 IPv4/IPv6 双栈 VPC 一并生效。集成测试如何验证该能力仓库中的集成测试 kms_subnet_test.go 用 kms-subnet-cluster.yaml 创建了一个带hostnameType: resource-name的集群并断言每个节点的主机名等于实例 ID.region.compute.internalIt(should have a resource-based hostname, func() { clientSet : makeClientSet() nodeList : tests.ListNodes(clientSet, mng-1) Expect(nodeList.Items).To(HaveLen(2)) for _, node : range nodeList.Items { instanceID, err : getInstanceID(node) Expect(err).NotTo(HaveOccurred()) Expect(node.Name).To(Equal(fmt.Sprintf(%s.%s.compute.internal, instanceID, params.Region))) } })该测试既验证了node.Name标签来源kubelet 以私有 DNS 名注册也印证了resource-name模式下实例私有 DNS 名确实基于资源标识而非 IP。需要留意的前提resource-name主机名只对创建之后启动的实例生效且受限于 VPC 级默认设置由子网级OnLaunch选项覆盖的行为实际运维中如需修改已有实例的主机名仍需另行调用 EC2 API。改进为 CoreDNS 1.251.27 移植 ready 插件与 lameduck 安全关停#6630 将此前见 0.117.0 首次引入、0.128.0 移植至 1.24的 CoreDNS 改进统一移植到了 Kubernetes 1.25、1.26 和 1.27 的默认 CoreDNS 资产中。仓库内每个受支持 Kubernetes 版本都有独立的 CoreDNS 资产文件例如 coredns-1.27.json其Corefile为.:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload loadbalance }两处关键改动的作用可以对照插件语义理解ready插件在/ready端点报告 CoreDNS 是否已具备服务能力配合 Kubernetes 的readinessProbe使用避免 Pod 刚调度就被 Service 转发流量health { lameduck 5s }当健康检查端点收到停止信号时先进入 5 秒“跛行鸭”lameduck排空窗口再真正下线让上游 DNS 客户端有窗口切换到其他副本从而实现滚动重启期间的更安全关停。从源码结构看资产按控制面版本加载coredns.go 的loadAssetCoreDNS会把控制面版本解析为主次版本前缀resolveK8sVersionPrefix再读取assets/coredns-主次版本.jsonfunc loadAssetCoreDNS(controlPlaneVersion string) (*metav1.List, error) { ... version, err : resolveK8sVersionPrefix(controlPlaneVersion) ... manifest, err : coreDNSDir.ReadFile(fmt.Sprintf(assets/%s-%s.json, CoreDNS, version)) ... }资产文件本身可通过 update_coredns_assets.go 脚本从上游 EKS 生成的清单批量刷新coredns_test.go 则校验各版本资产中的 Corefile 与预期一致。因此对 v0.144.0 用户而言创建或eksctl utils update-core-dns管理 1.251.27 集群时CoreDNS 即会携带上述配置。改进更新 aws-load-balancer-controller 的 IAM policy statement#6655 更新了内置的 loadbalancer controller IAM 策略语句。该策略对应 ClusterConfig 中的iam.policies.awsLoadBalancerController开关定义于 well_known_iam_policy.go// AWSLoadBalancerController adds policies for using the // aws-load-balancer-controller. See [Load Balancer // docs](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html). AWSLoadBalancerController bool json:awsLoadBalancerController,inline使用方式参考 examples/13-iamserviceaccounts.yaml 与 iam-policies.mdiam: withOIDC: true serviceAccounts: - name: aws-load-balancer-controller namespace: kube-system # policyARNs: # - arn:aws:iam::aws:policy/... wellKnownPolicies: awsLoadBalancerController: true策略语句的实际内容生成在 statement.go 中其中为 load-balancer-controller 授予了一组较完整的 ELBv2 管理权限包括elasticloadbalancing:ModifyLoadBalancerAttributes、SetSecurityGroups、ModifyTargetGroup、ModifyListenerAttributes等动作见 statement.go并带有Null: aws:ResourceTag/elbv2.k8s.aws/cluster: false的标签条件限定只操作属于当前集群的负载均衡资源。更新后的语句会随创建的 IAM Role 一并写入 CloudFormation 模板iam_test.go 的测试快照中也能看到elasticloadbalancing:ModifyLoadBalancerAttributes出现在生成的策略 JSON 中。这一变更意味着v0.144.0 之后用awsLoadBalancerController: true创建的控制器 Role 会获得与上游控制器要求对齐的权限集合降低因策略缺口导致的Forbidden报错概率。缺陷修复一DescribeUpdate仅对可重试的 API 错误重试#6645 修复了等待集群更新如升级控制面、启用 KMS 加密时的错误重试策略。修复前的行为是任何eks:DescribeUpdate调用错误都会无限重试等待修复后等待器通过 errors.go 的IsRetriableError判断错误是否“可重试”func IsRetriableError(err error) bool { var apiErr smithy.APIError if !errors.As(err, apiErr) { return true } switch { case isBadRequestErrorCode(apiErr), isNotFoundErrorCode(apiErr), isAccessDeniedErrorCode(apiErr): return false default: return true } }也就是说BadRequestException、NotFoundException/ResourceNotFoundException、AccessDenied/AccessDeniedException这类“确定性失败”不再被吞掉重试会立即向上返回。该判断被UpdateWaiter的Retryable闭包使用见 waiter.gooptions.Retryable func(ctx context.Context, input *eks.DescribeUpdateInput, output *eks.DescribeUpdateOutput, err error) (bool, error) { if err ! nil { if apierrors.IsRetriableError(err) { return true, nil } return false, err } switch output.Update.Status { case ekstypes.UpdateStatusSuccessful: return false, nil case ekstypes.UpdateStatusFailed, ekstypes.UpdateStatusCancelled: return false, UpdateFailedError{...} default: return true, nil } }这个等待器正是eksctl upgrade cluster、eksctl utils enable-secrets-encryption等流程的底层实现update.go 中waitForUpdateToSucceed会构造UpdateWaiter并以 30 秒最小、120 秒最大延迟做指数退避轮询DescribeUpdate。修复后的实际收益是当凭证权限不足或更新 ID 不存在时命令会快速失败并给出真实原因而不是等到整个--wait-timeout耗尽。缺陷修复二基于spec.ingressClassName清理 ALB 及其安全组#6389 修复了eksctl delete cluster阶段清理负载均衡器时的两类问题对应实现位于 pkg/elb/ingress.go 与 pkg/elb/cleanup.go1. Ingress class 判定优先使用spec.ingressClassName。在Ingress接口的两个实现中GetIngressClass都优先读取新版字段仅在其为空时回退到旧注解func (i *v1Ingress) GetIngressClass() string { if i.ingress.Spec.IngressClassName ! nil { return *i.ingress.Spec.IngressClassName } return i.ingress.Annotations[ingressClassAnnotation] }这意味着即使 Ingress 只设置了spec.ingressClassName: alb未写kubernetes.io/ingress.class注解Cleanup也能正确识别它为 ALB Ingress 并纳入清理流程识别逻辑见 cleanup.goIngress class 不是alb则跳过是alb但status.loadBalancer无 hostname 则视为未就绪也跳过。2. ALB 安全组一并纳入等待删除的集合。Cleanup对每个负载均衡器不仅记录名称与类型classic/network/application还通过getSecurityGroupsOwnedByLoadBalancercleanup.go解析其挂载的安全组仅保留带集群标签kubernetes.io/cluster/集群名或elbv2.k8s.aws/cluster的安全组 ID。删除 Service/Ingress 之后清理循环每 2 秒轮询一次直到“负载均衡器本身及其安全组全部消失”loadBalancerExists会同时检查两者见 cleanup.go。这一修复针对的是此前 ALB 删除后其安全组残留、导致集群删除卡住或资源残留的问题。缺陷修复三Windows 节点默认卷名设为/dev/sda1#6638 修正了为 Windows 节点组生成启动模板时块设备映射的默认卷名。在 block_device_mapping.go 中const ( rootDeviceForLinux /dev/xvda rootDeviceForWindows /dev/sda1 ) func makeBlockDeviceMappings(ng *api.NodeGroupBase) []gfnec2.LaunchTemplate_BlockDeviceMapping { var ( mappings []gfnec2.LaunchTemplate_BlockDeviceMapping baseVolumeName string ) if ng.VolumeName ! nil { baseVolumeName *ng.VolumeName } else if api.IsWindowsImage(ng.AMIFamily) { baseVolumeName rootDeviceForWindows } else { baseVolumeName rootDeviceForLinux } ...取值优先级清晰显式配置的nodeGroups[].volumeName Windows 镜像默认/dev/sda1 Linux 默认/dev/xvda。Windows Server 的 EBS 根设备名是/dev/sda1而非/dev/xvda此前默认值不匹配会导致volumeSize等 EBS 参数无法正确应用到根卷。修复后Windows 节点组的启动模板 golden 文件 windows.json 中即可看到BlockDeviceMappings: [ { DeviceName: /dev/sda1, Ebs: { Iops: 3000, Throughput: 125, VolumeSize: 200, VolumeType: gp3 } } ]相关单测覆盖了该映射行为见 block_device_mapping 测试 与 ami_test.go。维护与文档变更文档清理#6660整理 README 与贡献指南的格式和拼写属仓库卫生类变更不影响功能行为集成测试日志修复#6649修复 Trainium 与 Inferentia 集成测试在失败时打印 CloudFormation 栈事件的逻辑params.LogStacksEventsOnFailure一类的工具函数可参考 kms_subnet_test.go 中的用法schemer 依赖升级#6646将 schemer 从 2021 年版本升级至 2023 年版本schemer 用于生成 JSON Schema升级会间接影响 assets/schema.json 等 schema 产物的生成工具链ATTRIBUTIONS.md 生成#6647仓库根目录新增自动生成的第三方依赖归属文件 ATTRIBUTIONS.md。小结v0.144.0 的适用前提与升级要点vpc.hostnameType仅对 eksctl 新建的 VPC 生效配置已有子网的集群会在校验阶段直接报错合法取值为ip-name/resource-nameCoreDNS 的readyhealth.lameduck 5s变更随控制面版本加载对应资产1.231.29 各有独立 JSON 资产见 assets 目录在 1.251.27 集群上执行 CoreDNS 更新/新建时生效awsLoadBalancerControllerIAM 策略语句更新影响 v0.144.0 之后新创建的 IRSA Role存量集群可对比 statement.go 中的动作清单自查权限差异DescribeUpdate重试收紧后升级集群、启用 Secrets 加密等长时任务遇到权限类错误会快速失败属于预期行为变化Windows 节点组若显式指定了volumeName仍以显式值为准默认值仅在未指定时回退为/dev/sda1。以上各条变更均可在 docs/release_notes/0.144.0.md 中回溯到原始 PR 编号文中引用的源码路径与测试文件提供了从配置到 CloudFormation 模板、从 CLI 行为到集成断言的完整证据链便于在升级或排查问题时逐一定位。赞分享云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载相关推荐media-autobuild_suite配置教程3步完成FFmpeg自定义编译选项设置media autobuild_suite配置教程3步完成FFmpeg自定义编译选项设置 media autobuild_suite是一款强大的WindowsWereader测试与部署指南确保浏览器扩展稳定运行的完整流程Wereader测试与部署指南确保浏览器扩展稳定运行的完整流程 Wereader是一款专为微信读书用户设计的浏览器扩展特别适合习惯使用Markdown做笔记前端brpc 客户端负载均衡全解析命名服务、负载均衡算法与健康检查机制brpc 客户端负载均衡全解析命名服务、负载均衡算法与健康检查机制 brpcbetter RPC是百度开源的工业级 C RPC 框架其客户端侧围绕后端RPC框架通信网络上一篇如何快速解密微信聊天数据库WechatDecrypt完整指南下一篇WechatDecrypt终极指南3步快速解密微信数据库免费恢复聊天记录创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考