企业官网建设流程全解析

Renovate 的 aws-eks-addon 数据源：自动化 EKS 插件版本更新实战指南

【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate

Renovate 内置的aws-eks-addondatasource 通过 AWS 官方 API 查询 Amazon EKS 上可用 Addon（插件）的版本列表，用于自动发现并升级 EKS 插件版本。本文以 lib/modules/datasource/aws-eks-addon/readme.md 为骨架，结合该数据源的源码实现与测试用例，完整讲解 AWS 凭证配置、IAM 最小权限、自定义 manager 的 regex 匹配方案，以及如何在 Terraform、YAML 等配置文件中为 EKS Addon 开启版本更新。读完本文，你将能够在自己的仓库中直接落地一套可运行的 EKS Addon 依赖自动升级配置。

一、数据源定位与工作原理

aws-eks-addon是 Renovate 中负责 EKS Addon 版本发现的数据源。它在 lib/modules/datasource/aws-eks-addon/index.ts 中实现，核心逻辑是调用 AWS SDK for JavaScript v3 的DescribeAddonVersionsCommand命令（见 index.ts#L38-L43），向 AWS EKS API 查询指定插件在特定 Kubernetes 版本下的可用版本列表，并把结果整理为 Renovate 标准的releases结构：

• version：插件版本号，如v1.18.1-eksbuild.3；
• default：是否为当前集群配置下的 AWS 默认推荐版本；
• compatibleWith：该版本兼容的 Kubernetes 集群版本列表。

该数据源声明了caching = true（index.ts#L17），getReleases通过withCache以datasource-aws-eks-addon:getReleases:{packageName}为键做结果缓存（index.ts#L70-L79），避免重复请求 AWS API。

查询请求固定使用maxResults: 1（index.ts#L41），即只取一个 Addon 的信息块，再从该 Addon 的addonVersions中展开全部版本，从而以最少的 API 开销获取完整版本列表。

二、AWS 凭证配置

Renovate 与 AWS 服务交互时统一使用 AWS SDK for JavaScript，因此可以像使用awsCLI 一样通过标准方式提供凭证，具体说明见 docs/usage/calling-aws-services.md：

• 通过AWS_REGION环境变量或~/.aws/config设置区域；
• 通过AWS_ACCESS_KEY_ID与AWS_SECRET_ACCESS_KEY环境变量或~/.aws/credentials提供凭证；
• 通过AWS_PROFILE环境变量选择使用的 profile。

2.1 为数据源单独配置 hostRules 凭证

除默认凭证链外，还可以专门为该数据源配置一条hostRules。设置hostType为aws-eks-addon，username为 Access Key ID，password为 Secret Access Key，可选token为 Session Token：

{ "hostRules": [ { "hostType": "aws-eks-addon", "username": "access-key-id", "password": "secret-access-key", "token": "session-token" } ] }

从源码看，这些凭证仅用于 EKS Addon 查询。在 getClient 中，Renovate 先通过hostRules.find({ hostType: AwsEKSAddonDataSource.id })查找上述配置：

• 若同时存在username和password，则直接使用accessKeyId / secretAccessKey / sessionToken构造 AWS 凭证；
• 否则回退到fromNodeProviderChain(profile ? { profile } : undefined)，即 AWS 默认凭证提供者链（环境变量 → 共享凭证文件 → 实例角色等），与awsCLI 的行为一致。

测试 index.spec.ts#L174-L198 专门验证了「host rule 凭证优先于 profile」这一优先级：即使 packageName 中传入了profile，只要存在 hostRules 凭证，就会使用 hostRules 中的凭证。

2.2 IAM 最小权限

该数据源只需要一个 API 调用eks:DescribeAddonVersions，因此最小 IAM 权限策略如下：

{ "Sid": "AllowDescribeEKSAddonVersions", "Effect": "Allow", "Action": ["eks:DescribeAddonVersions"], "Resource": "*" }

出于安全最佳实践，建议为 Renovate 使用独立的 IAM 用户/角色，仅授予上述权限，避免授予 EKS 集群的写权限或其它敏感权限。

三、使用方式：custom manager + minified JSON packageName

由于 Renovate 目前没有专门解析 EKS Addon 的原生 manager，需要借助custom manager（regex 类型）识别仓库中的插件版本声明。关键点在于：必须把 Kubernetes 版本与插件名打包成一个 minified（压缩无空格）JSON 对象作为packageName传给数据源。

例如获取 Kubernetes 1.30 的vpc-cni版本：

{"kubernetesVersion":"1.30","addonName":"vpc-cni"}

minified JSON 对象支持以下字段（完整字段定义与校验规则见 schema.ts）：

校验由 zod schemaEksAddonsFilter完成（schema.ts#L5-L21），schema.spec.ts 中的用例给出了合法与非法输入的边界：kubernetesVersion: "130"（缺少点号分隔）、addonName: "kube_proxy"（含下划线）、缺少addonName的 JSON 都会被判定为非法；解析失败时数据源会记录Error parsing eks-addons config.警告并返回空结果（index.ts#L27-L34）。

3.1 在注释中声明 eksAddonsFilter

推荐的做法是在被监控文件中的版本行上方，用# renovate: eksAddonsFilter={...}注释声明过滤条件。数据源会在每个 Addon 上查询默认版本或指定 Kubernetes 版本的版本，示例如下：

# discover kube-proxy addon versions without specifying a cluster version. renovate: eksAddonsFilter={"addonName":"kube-proxy"} # discover kube-proxy default addon versions renovate: eksAddonsFilter={"addonName":"kube-proxy", "default":true} # discover vpc-cni addon versions on Kubernetes 1.30 in us-east-1 region using environmental AWS credentials. renovate: eksAddonsFilter={"kubernetesVersion":"1.30","addonName":"vpc-cni","region":"eu-west-1"} # discover vpc-cni addon versions on Kubernetes 1.30 in us-east-1 region using AWS credentials from `renovate-east` profile. renovate: eksAddonsFilter={"kubernetesVersion":"1.30","addonName":"vpc-cni","region":"us-east-1","profile":"renovate-east"}

说明：

• 虽然 EKS 通常在不同区域支持相同的插件版本，但依然可以通过region字段按区域发现版本；
• region会传入 AWS SDK 构造的EKSClient中（index.ts#L88），测试 index.spec.ts#L271-L298 验证了 packageName 中的 region 确实被透传给 AWS 客户端；
• profile仅在未配置 hostRules 凭证时生效（凭证优先级见 2.1 节）。

3.2 完整 custom manager 配置示例

下面是一个可复制使用的完整配置，匹配所有 Terraform 文件并识别其中的版本声明：

{ "packageRules": [ { "matchDatasources": ["aws-eks-addon"], "overrideDepName": "{{replace '.*\"addonName\":\"([^\"]+)\".*' '$1' depName}}" } ], "customManagers": [ { "customType": "regex", "managerFilePatterns": ["/.*\\.tf/"], "matchStrings": [ ".*# renovate: eksAddonsFilter=(?<packageName>.*?)\n.*?[a-zA-Z0-9-_:]*[ ]*?[:|=][ ]*?[\"|']?(?<currentValue>[a-zA-Z0-9-_.]+)[\"|']?.*" ], "datasourceTemplate": "aws-eks-addon", "versioningTemplate": "aws-eks-addon" // Optional. Default value is 'aws-eks-addon' } ] }

配置要点：

• matchDatasources限定只对aws-eks-addon数据源的依赖生效；
• overrideDepName使用 Renovate 模板的replace函数，从 minified JSON 的depName中提取addonName作为依赖展示名，让 PR 标题更友好；
• managerFilePatterns限定匹配/.*\.tf/（Terraform 文件），可按需替换为.yaml、.yml、.json等扩展名；
• matchStrings中的正则负责两件事：捕获# renovate: eksAddonsFilter=...注释作为packageName命名组，并捕获紧随其后的版本赋值语句中的版本值作为currentValue；
• datasourceTemplate固定为aws-eks-addon；
• versioningTemplate默认即为aws-eks-addon，可省略。

四、被监控文件的两种写法

4.1 Terraform 变量声明

上面的配置可以识别如下 Terraform 变量声明（在default值上方带 eksAddonsFilter 注释）：

variable "vpc_cni_version" { type = string description = "EKS vpc-cni add-on version" # kubernetesVersion and addonName provided # renovate: eksAddonsFilter={"kubernetesVersion":"1.30","addonName":"vpc-cni"} default = "v1.18.1-eksbuild.3" }

Renovate 发现default = "v1.18.1-eksbuild.3"为当前版本，按注释中的过滤条件查询vpc-cni在 Kubernetes 1.30 下的新版本，并生成升级 PR。

4.2 YAML 清单声明

对于name + version键值对形式的清单（如某些 IAC 工具或自研清单），只提供addonName与default过滤条件：

addons: - name: vpc-cni # only addon name and the supported default version # renovate: eksAddonsFilter={"addonName":"vpc-cni", "default":true} version: v1.18.5-eksbuild.1

此时 Renovate 仅把 AWS 标记为默认的版本作为可升级目标，避免升级到非默认（可能不稳定）的版本。

五、版本号解析规则

aws-eks-addon数据源默认关联同名的aws-eks-addonversioning（见 index.ts#L16），其实现位于 lib/modules/versioning/aws-eks-addon/index.ts。它基于正则表达式解析版本号：

^v?(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)(?<compatibility>-eksbuild\.)(?<build>\d+)$

即合法的插件版本形如v1.19.0-eksbuild.1，其构成包括：

• Major / Minor / Patch：遵循语义化版本 2.0 的三段式，分别表示破坏性变更、新功能增强与缺陷修复；
• -eksbuild.N构建元数据：表示 EKS 构建系统生成的特定构建/发布，用于区分同版本号下不同独立构建的产物，便于追踪与排障。

正因版本含-eksbuild.N构建号，插件版本并非纯 SemVer，因此必须使用该专用 versioning 而非通用semver才能正确比较与排序。

六、测试验证与行为边界

仓库中的测试用例从行为层面印证了上述设计（见 index.spec.ts）：

• 查询不存在的 Addon（AWS 返回空）时结果返回null，且请求参数严格为{ kubernetesVersion, addonName, maxResults: 1 }（index.spec.ts#L97-L116）；
• 缺少addonName的 packageName 被 schema 拒绝并产生警告日志（index.spec.ts#L118-L132）；
• 仅提供addonName时返回该插件全部版本，并附带compatibleWith（兼容集群版本）与default标记（index.spec.ts#L134-L163）；
• 提供default: true时，仅保留defaultVersion: true的版本（index.spec.ts#L209-L233）；
• 对缺少基本字段的畸形版本条目会被过滤掉，不会进入发布列表（index.spec.ts#L264-L266）。

七、常见问题与注意事项

1. minified JSON 不能有空格：packageName必须压缩为一行无空格的 JSON，否则正则捕获与 schema 解析都可能失败。
2. 凭证优先级：hostRules 凭证 > profile > 默认凭证提供者链；同时配置时应理解这一优先级，避免误用凭证。
3. addonName命名规则：只能使用小写字母、数字与连字符（如aws-cloudwatch-controller），下划线等字符会被 schema 拒绝。
4. default: true的取舍：开启后只跟踪 AWS 默认推荐版本，适合追求稳定的集群；关闭则跟踪该插件全部可用版本，更新更激进。
5. 匹配文件范围：managerFilePatterns只匹配.tf文件，若在 YAML 清单中使用，需同时调整为正则或使用多个 custom manager。
6. IAM 权限收敛：仅授予eks:DescribeAddonVersions即可，无需 EKS 写权限。

八、进一步阅读

• 数据源核心实现：lib/modules/datasource/aws-eks-addon/index.ts
• 过滤条件 schema 定义与校验：lib/modules/datasource/aws-eks-addon/schema.ts
• 数据源行为测试：lib/modules/datasource/aws-eks-addon/index.spec.ts
• 插件版本号解析规则：lib/modules/versioning/aws-eks-addon/index.ts
• AWS 凭证配置通用说明：docs/usage/calling-aws-services.md

【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate