云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载本篇技术指南围绕 eksctlThe official CLI for Amazon EKS的 0.105.0 版本发布说明展开逐条解读该版本包含的三项变更addon--force标志的文档修正、taints污点示例迁移到结构化列表新语法以及无节点组时不再等待 CoreDNS 变为 active的 Bug 修复。阅读本文后你将掌握eksctl create addon --force的真实语义与底层ResolveConflicts行为、taints 新旧两种声明语法的差异与适用场景以及 addon 等待机制中HasNodes()判定对集群创建流程的影响并能对照 pkg/actions/addon 源码与 examples/34-taints.yaml 示例直接验证。版本概览eksctl 0.105.0 是一次以文档与示例收尾 一处关键流程 Bug 修复为主的小版本发布其变更集中在 addon附加组件与 nodegroup节点组两大模块类型变更内容关联 PR文档修复修正 addons 中--force标志的文档说明#5466示例更新taints 示例改用新语法书写#5457Bug 修复集群无 nodegroups 时不再等待 CoreDNS 变为 active#5458三者虽然看似零散但都对应着可验证的源码实现下面逐一展开。addon--force文档修复背后的真实语义命令行定义--force是eksctl create addon与eksctl update addon系列命令共用的布尔标志。其命令行定义为见 pkg/ctl/create/addon.gofs.BoolVar(force, force, false, Force migrates an existing self-managed add-on to an EKS managed add-on)即将集群中已存在的自管理self-managedadd-on 强制迁移为 EKS 托管managedadd-on。默认值为false不传时按普通创建流程处理。底层实现ResolveConflictsOverwrite--force的核心影响体现在 addon 创建/更新时提交给 EKS API 的ResolveConflicts字段上。在创建路径中见 pkg/actions/addon/create.goif addon.Force { createAddonInput.ResolveConflicts ekstypes.ResolveConflictsOverwrite } else { addonName : strings.ToLower(addon.Name) if addonName coredns || addonName kube-proxy || addonName vpc-cni { logger.Info(when creating an addon to replace an existing application, e.g. CoreDNS, kube-proxy VPC-CNI the --force flag will ensure the currently deployed configuration is replaced) } }在更新路径中同理见 pkg/actions/addon/update.goif addon.Force { updateAddonInput.ResolveConflicts ekstypes.ResolveConflictsOverwrite }ResolveConflictsOverwrite的含义是当目标 addon 与集群内既有配置如自管理版 CoreDNS、kube-proxy、VPC-CNI 的 Deployment 配置存在冲突时直接用托管 addon 的配置覆盖现有应用。这一行为在 pkg/actions/addon/create_test.go 的测试用例中也有明确断言ResolveConflictsimplicitly set to overwrite by using--forceflag并在测试中断言最终提交给 EKS 的ResolveConflicts等于ekstypes.ResolveConflictsOverwrite见同文件 L708。0.105.0 修复了什么从源码注释可见此前文档对--force的描述容易让人误以为它只针对 CoreDNS / kube-proxy / VPC-CNI 三个特定 addon。实际上--force是一个通用开关对任意addon 都生效其效果是强制以覆盖方式解决配置冲突只不过对于上述三个自管理 add-on 迁移场景不传--force时代码会额外打印提示提醒用户启用该标志以确保替换成功。0.105.0 正是修正了文档中这一表述使--force的通用语义与替换既有自管理应用的典型用途被准确区分开来。实操建议在已有自管理 CoreDNS/kube-proxy/VPC-CNI 的集群上启用托管 addon 时务必加上--force否则 EKS 可能因配置冲突拒绝创建或保持既有配置不变eksctl create addon --cluster cluster-name --name coredns --force更新 addon 时如需覆盖既有配置冲突同样使用eksctl update addon --cluster cluster-name --name vpc-cni --force若在配置文件ClusterConfig中声明 addon 并希望强制覆盖可将force: true写入 addon 条目命令行--force与配置文件中的Force字段最终都会映射到同一个api.Addon.Force字段并驱动ResolveConflicts逻辑见 pkg/ctl/create/addon.go 中force向a.Force true的赋值。taints 新语法从 map 简写升级为结构化列表为什么需要新语法taints污点用于控制 Pod 能否被调度到节点组上。早期 eksctl 支持一种 map 简写语法形如key: value:effect。这种写法把 value 与 effect 压缩进一个字符串可读性差且容易与普通 label 混淆。0.105.0 将官方示例统一迁移为结构化列表语法见 examples/34-taints.yaml每个污点由key、value、effect三个显式字段组成。新旧语法对比旧语法map 简写仍受支持nodeGroups: - name: ng1 taints: your.domain.com/db: true:NoSchedule新语法结构化列表0.105.0 示例采用的写法nodeGroups: - name: ng1 taints: - key: your.domain.com/db value: true effect: NoSchedule两种写法在解析层是兼容的taints字段的类型taintsWrapper实现了自定义UnmarshalJSON见 pkg/apis/eksctl.io/v1alpha5/types.go它会先尝试按map[string]string解析旧语法失败后再按[]NodeGroupTaint列表解析新语法两者皆不匹配时报错taints must be a {string: string} or a [{key, value, effect}]。也就是说旧配置无需改动即可继续使用新语法则作为更清晰、推荐的声明方式进入官方示例。完整的官方示例34-taints.yaml0.105.0 更新后的 examples/34-taints.yaml 同时覆盖了非托管unmanaged与托管managed节点组是理解 taints 配置的最佳模板apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: taints-1 region: us-west-1 # Unmanaged nodegroups with and without taints. nodeGroups: - name: ng1-public instanceType: m5.xlarge minSize: 2 maxSize: 8 taints: - key: your.domain.com/db value: true effect: NoSchedule - key: your.domain.com/production value: true effect: NoExecute - name: ng2-private instanceType: m5.xlarge minSize: 2 maxSize: 8 privateNetworking: true taints: - key: your.domain.com/sensitive-information value: true effect: NoSchedule - name: ng3-public instanceType: m5.xlarge minSize: 2 maxSize: 8 # Managed nodegroups with taints. managedNodeGroups: - name: mng1-public taints: - key: your.domain.com/memory-pressure value: true effect: PreferNoSchedule - key: your.domain.com/needs-auth value: true effect: NoExecute要点解读非托管与托管节点组均可配置 taints。对应 API 类型中非托管NodeGroup的Taints字段与托管ManagedNodeGroup的Taints字段都声明为[]NodeGroupTaint见 pkg/apis/eksctl.io/v1alpha5/types.go 与同文件 L2160并统一通过NGTaints()接口暴露给上层见 L1595-L1597 与 L2216-L2218。effect 支持三种取值NoSchedule默认禁止不满足容忍度的 Pod 调度、NoExecute驱逐已运行的不满足容忍度的 Pod、PreferNoSchedule软性约束尽量不调度。示例中三种效果均有覆盖mng1-public使用了PreferNoSchedule说明托管节点组同样支持软性污点。配置的最终落点不同非托管节点组的 taints 会写入 CloudFormation 的 Auto Scaling Group 与 EC2 实例托管节点组则通过 EKS 的 Nodegroup API 创建资源并应用到 EC2 实例schema 描述见 pkg/apis/eksctl.io/v1alpha5/assets/schema.json 与 L2390-L2394。托管节点组在 CFN 构建路径中通过mapTaints(m.nodeGroup.Taints)转换后写入自定义资源属性见 pkg/cfn/builder/managed_nodegroup.go 与 pkg/cfn/builder/beta.go。校验规则三个字段都有约束无论新旧语法解析出的NodeGroupTaint最终都会按 Kubernetes 污点规范校验见 pkg/utils/taints/taints.go 与 L62-L74key必须非空且必须是通过validation.IsQualifiedName的合法域名/限定名如your.domain.com/dbvalue若提供必须是通过validation.IsValidLabelValue的合法 label 值effect必须是NoSchedule、NoExecute、PreferNoSchedule三者之一否则报错 invalid taint effect。同时旧语法解析pkg/utils/taints/taints.go接受value:effect或:effect两种字符串形态可视为新语法的紧凑替代。与 Cluster Autoscaler 的联动taints 与 autoscaling 存在一个需要注意的联动点若希望节点组支持从 0 扩容需要将 labels/taints 以 ASG tag 形式传播出去否则 Cluster Autoscaler 无法在 0 节点时感知节点模板。两种做法一是手动在tags中声明k8s.io/cluster-autoscaler/node-template/taint/key: value:effect旧语法字符串形式二是直接设置propagateASGTags: true让 eksctl 自动把 taints/labels 传播为 ASG tags。相关细节见 userdocs/src/usage/autoscaling.md。Bug 修复无节点组集群不再等待 CoreDNS active问题背景在创建集群时eksctl 会为配置中声明的 addon含 CoreDNS执行创建并等待其进入ACTIVE状态。但存在一个特殊场景集群不包含任何节点组nodegroups例如纯 Fargate 集群或先建集群后补节点组的流程。此时 CoreDNS以及依赖节点运行的工作负载型 addon没有可运行的节点会长时间停留在DEGRADED状态导致 eksctl 在等待 addon active 时超时报错阻塞整个创建流程。修复后的判定逻辑修复位于 addon 等待函数中见 pkg/actions/addon/addon.gofunc (a *Manager) waitForAddonToBeActive(ctx context.Context, addon *api.Addon, waitTimeout time.Duration) error { // Dont wait for coredns, aws-ebs-csi-driver or aws-efs-csi-driver if there are no nodegroups. // They will be in degraded state until nodegroups are added. if (addon.Name api.CoreDNSAddon || addon.Name api.AWSEBSCSIDriverAddon || addon.Name api.AWSEFSCSIDriverAddon) !a.clusterConfig.HasNodes() { return nil } ... }逻辑可概括为当 addon 属于coredns、aws-ebs-csi-driver、aws-efs-csi-driver三者之一且集群没有任何节点组clusterConfig.HasNodes()为false时跳过 active 状态等待直接返回不再触发NewAddonActiveWaiter的轮询与超时。源码注释也写明了设计意图They will be in degraded state until nodegroups are added——这些 addon 在节点组加入之前必然处于 degraded 状态等待只会白白耗尽--wait-timeout。类似的判定还出现在任务编排层ShouldWaitForAddons(cfg.HasNodes(), postAddons)会根据集群是否含节点组来决定是否让 post-create addon 任务执行等待见 pkg/actions/addon/tasks.go。为什么只豁免这三个 addoncoredns、aws-ebs-csi-driver、aws-efs-csi-driver都是依赖实际节点工作负载的 addonCoreDNS 需要节点运行 DNS 解析 PodCSI 驱动需要节点挂载存储插件。在零节点集群中它们无法进入 active。而其他 addon如eks-pod-identity-agent等不在此豁免名单中仍按原流程等待。与 Fargate 场景的关系需要留意的是这个豁免针对的是集群内没有节点组的通用场景。Fargate 集群若配置了 Fargate Profile 且允许调度 CoreDNS则走另一条路径——eksctl 会主动把 CoreDNS 调度到 Fargate 并等待其调度完成见 pkg/eks/fargate.go 的ScheduleCoreDNSOnFargateIfRelevant与 pkg/fargate/coredns 包的WaitForScheduleOnFargate。两条路径互相独立是否跳过 addon active 等待取决于HasNodes()是否调度 CoreDNS 到 Fargate 取决于 Fargate Profile 配置coredns.IsSchedulableOnFargate。对使用者的影响纯 Fargate 集群或先创建空集群、后续再补节点组的自动化流程在 0.105.0 之后不会因 CoreDNS 长时间 degraded 而卡死在 addon 等待环节集群创建完成后若 addon 仍处于DEGRADED状态属于预期行为节点组加入后 addon 会自动恢复 active对含节点组的常规集群行为不变CoreDNS 等 addon 仍会等待至 active。小结eksctl 0.105.0 的三项变更覆盖了文档准确性、示例现代化、流程健壮性三个层面addon--force文档被修正为准确描述其强制覆盖配置冲突 / 迁移自管理 add-on的通用语义底层对应ResolveConflictsOverwrite见 pkg/actions/addon/create.go、pkg/actions/addon/update.go并有单元测试锁定行为见 pkg/actions/addon/create_test.gotaints 新语法官方示例统一采用key/value/effect结构化列表见 examples/34-taints.yaml解析层通过taintsWrapper同时兼容新旧两种写法见 pkg/apis/eksctl.io/v1alpha5/types.go校验规则与 Kubernetes 污点规范对齐见 pkg/utils/taints/taints.goCoreDNS 等待豁免当集群无节点组时对coredns、aws-ebs-csi-driver、aws-efs-csi-driver跳过 active 等待避免无意义的超时见 pkg/actions/addon/addon.go。对于升级到 0.105.0 的用户建议重点验证既有 taints 配置文件旧语法仍可用无需强制改写、涉及自管理 add-on 迁移的--force用法以及零节点集群的创建流程是否因此更加顺畅。赞分享云原生容器编排DevOps【免费下载链接】eksctlThe official CLI for Amazon EKS项目地址https://gitcode.com/gh_mirrors/ek/eksctl点击查看免费下载相关推荐RabbitMQ 4.0.4 维护版发布说明深度解读集群标签、节点标签与关键修复全景RabbitMQ 4.0.4 维护版发布说明深度解读集群标签、节点标签与关键修复全景 RabbitMQ 4.0.4 是 4.0.x 系列中的一个维护版本ma后端消息队列消息路由CoreDNS 1.9.0 发布解读kubernetes 通配符移除、健康检查与指标修复要点CoreDNS 1.9.0 发布解读kubernetes 通配符移除、健康检查与指标修复要点 本篇技术指南围绕 CoreDNS 1.9.0 发布说明 not后端网络云原生Flink CDC 接 OceanBase30 分钟跑通全量快照 增量 CDC 同步Flink CDC 接 OceanBase30 分钟跑通全量快照 增量 CDC 同步 凌晨两点对账财务发现 OceanBase 里的订单表还是 T1后端数据集成大数据流处理变更数据捕获数据同步上一篇brpc bvar 单维度指标库C使用指南从 Reducer 到 Window/PerSecond 的监控编程实战下一篇Ceph cephadm 集群版本追踪详解get-cluster-version-history 与 remove-cluster-version-history 实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考