十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Terraform AWS Provider 中 aws_eks_addon_version 数据源:为 EKS Add-on 选择正确版本

Terraform AWS Provider 中 aws_eks_addon_version 数据源:为 EKS Add-on 选择正确版本 Terraform AWS Provider 中 aws_eks_addon_version 数据源为 EKS Add-on 选择正确版本【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws本文围绕 terraform-provider-aws 仓库中的aws_eks_addon_version数据源文档展开说明如何根据 EKS 集群的 Kubernetes 版本查询 Add-on如 vpc-cni、coredns、kube-proxy 等的可用版本并结合 provider 源码解析其底层的DescribeAddonVersionsAPI 调用链、分页逻辑以及“最新版本 vs 默认版本”的选择策略帮助你在编写 EKS Add-on 配置时自动获得正确的addon_version取值。数据源概述在 EKS 集群中Add-on 的版本与集群的 Kubernetes 版本强相关同一个 Add-on例如vpc-cni在不同 Kubernetes 版本下可安装的版本不同且 AWS 会为每个 Kubernetes 版本维护一个“默认版本”。如果手工硬编码addon_version集群升级后很容易选到不兼容的版本。aws_eks_addon_version数据源的作用正是给定 Add-on 名称和集群 Kubernetes 版本自动解析出应使用的 Add-on 版本供aws_eks_addon等资源引用。该数据源的完整文档见 website/docs/d/eks_addon_version.html.markdown实现位于 internal/service/eks/addon_version_data_source.go。示例用法官方文档给出的示例展示了“默认版本”与“最新版本”两种查询方式以及如何把查询结果直接喂给aws_eks_addon资源data aws_eks_addon_version default { addon_name vpc-cni kubernetes_version aws_eks_cluster.example.version } data aws_eks_addon_version latest { addon_name vpc-cni kubernetes_version aws_eks_cluster.example.version most_recent true } resource aws_eks_addon vpc_cni { cluster_name aws_eks_cluster.example.name addon_name vpc-cni addon_version data.aws_eks_addon_version.latest.version } output default { value data.aws_eks_addon_version.default.version } output latest { value data.aws_eks_addon_version.latest.version }注意示例中kubernetes_version引用的是aws_eks_cluster.example.version——即让数据源始终跟随集群实际 Kubernetes 版本而不是写死1.29之类的字面量。这样当集群升级后重新 plan数据源会自动重新解析出匹配的版本。参数Argument Reference数据源支持以下参数参数必填/可选说明region可选指定 Add-on 版本查询所在的 Region默认使用 provider 配置中设置的 Regionaddon_name必填EKS Add-on 名称必须是 AWS EKSlist-addons支持的名称之一如vpc-cni、coredns、kube-proxy等kubernetes_version必填EKS 集群的 Kubernetes 版本。长度 1–100 个字符须以字母或数字开头只能包含字母、数字、连字符和下划线正则^[0-9A-Za-z][A-Za-z0-9\-_]$most_recent可选布尔值。为true时返回该 Add-on 的最新版本缺省false时返回 AWS 为该 Kubernetes 版本标记的默认版本从源码看Schema 定义非常精简addon_name使用validation.NoZeroValues校验非零值kubernetes_version为普通必填字符串most_recent为可选布尔version为计算属性另加上 provider 统一注入的region支持见 addon_version_data_source.go。输出属性Attribute Reference除上述参数外数据源额外导出属性说明idAdd-on 名称源码中d.SetId(addonName)直接以 Add-on 名称作为资源 IDversion解析出的 EKS Add-on 版本字符串是供其他资源引用的核心输出底层实现DescribeAddonVersions 与版本选择策略API 调用与分页数据源的读取函数dataSourceAddonVersionRead获取addon_name、kubernetes_version、most_recent三个参数后调用内部查找函数findAddonVersionByTwoPartKey。该函数构造DescribeAddonVersionsInput携带 AddonName 与 KubernetesVersion并通过 SDK v2 的分页器遍历全部结果页input : eks.DescribeAddonVersionsInput{ AddonName: aws.String(addonName), KubernetesVersion: aws.String(kubernetesVersion), } pages : eks.NewDescribeAddonVersionsPaginator(conn, input) for pages.HasMorePages() { page, err : pages.NextPage(ctx) // ... }节选自 findAddonVersionByTwoPartKey。分页循环中还有两处值得注意的健壮性处理如果 API 返回ResourceNotFoundException例如 Add-on 名称不存在或该区域不支持会被包装为retry.NotFoundError向上返回而不是当作普通错误直接失败如果遍历完所有分页都没找到匹配版本则返回tfresource.NewEmptyResultError()提示查询结果为空。“最新版本”与“默认版本”的选择逻辑这是该数据源最核心的业务逻辑源码中体现为对每个AddonVersionInfo的两种判定路径for _, v : range page.Addons { for i, v : range v.AddonVersions { if mostRecent i 0 v.AddonVersion ! nil { return v, nil } for _, compatibility : range v.Compatibilities { if compatibility.DefaultVersion v.AddonVersion ! nil { return v, nil } } } }可以归纳出两条选择规则most_recent true直接取 API 返回的第一个版本条目i 0。从 AWS EKS API 的返回结构看AddonVersions是按版本倒序排列的首元素即最新版缺省默认版本遍历每个版本的Compatibilities列表找到其中DefaultVersion为true的条目返回。也就是说“默认版本”并非 API 单独返回的字段而是通过兼容性元数据中标记的default得来。找到目标后读取函数把结果写入 stateid与addon_name同为 Add-on 名称version取自versionInfo.AddonVersion见 dataSourceAddonVersionRead。错误信息格式查询失败时诊断信息会以如下格式返回方便在 Terraform 报错中定位参数reading EKS Add-On version info (addon_name, kubernetes_version): err与 aws_eks_addon 数据源的协同实践中常把本数据源与aws_eks_addon数据源配合使用前者决定“应该装哪个版本”后者用于“读回已安装 Add-on 的实际状态”。aws_eks_addon数据源由cluster_nameaddon_name唯一定位导出addon_version、configuration_values、service_account_role_arn、created_at/modified_at等属性实现见 internal/service/eks/addon_data_source.go。仓库中的验收测试 TestAccEKSAddonVersionDataSource_basic 正是验证这种协同以vpc-cni为例先用aws_eks_addon_version查到版本再用该版本创建aws_eks_addon资源最后断言数据源的version输出与已安装 Add-on 的addon_version一致并分别覆盖most_recent true/false两种场景。该测试的 PreCheck 还会调用一次DescribeAddonVersionsAPI见 addon_test.go来确认当前测试环境可用该 API不可用时自动跳过。data aws_eks_addon_version test { addon_name vpc-cni kubernetes_version aws_eks_cluster.test.version most_recent true } resource aws_eks_addon test { addon_name vpc-cni cluster_name aws_eks_cluster.test.name addon_version data.aws_eks_addon_version.test.version resolve_conflicts_on_create OVERWRITE } data aws_eks_addon test { addon_name vpc-cni cluster_name aws_eks_cluster.test.name depends_on [ data.aws_eks_addon_version.test, aws_eks_addon.test, aws_eks_cluster.test, ] }实践建议与适用限制跟随集群版本而非写死版本把kubernetes_version绑定到aws_eks_cluster.x.version可让 Add-on 版本随集群升级自动重新解析写死版本字符串在集群升级后会失去自动适配能力。区分 default 与 most_recent 的语义缺省时取的是 AWS 为该 Kubernetes 版本标记的默认版本兼容性标记most_recent true则取 API 返回列表中的首个版本。对于生产集群默认版本通常更稳妥对需要尝鲜的场景才开启most_recent。名称必须合法addon_name必须是 EKS 支持列表中的 Add-on 名称名称不存在或区域不支持时会以 NotFound 类错误失败查询无结果时会得到“empty result”错误二者都可以直接从报错信息中定位问题参数。区域限制与 provider 其他数据源一致region参数遵循 provider 的 region 配置逻辑不同区域可提供的 Add-on 及其版本集合可能不同查询结果为空时也应考虑区域因素。相关文件索引文件内容website/docs/d/eks_addon_version.html.markdown数据源官方文档本文主体依据internal/service/eks/addon_version_data_source.go数据源 Schema、读取逻辑与版本选择实现internal/service/eks/addon_version_data_source_test.go验收测试default / most_recent 两种模式internal/service/eks/addon_data_source.go配套的aws_eks_addon数据源实现internal/service/eks/addon_test.goEKS 相关测试的 PreCheck 与基础配置【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表