多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

terraform-aws-eks 演进史深度解析:从 v0.1.0 到 v10.0.0 的架构变迁、破坏性变更与迁移实战

terraform-aws-eks 演进史深度解析:从 v0.1.0 到 v10.0.0 的架构变迁、破坏性变更与迁移实战 terraform-aws-eks 演进史深度解析从 v0.1.0 到 v10.0.0 的架构变迁、破坏性变更与迁移实战【免费下载链接】terraform-aws-eksTerraform module to create Amazon Elastic Kubernetes (EKS) resources 项目地址: https://gitcode.com/GitHub_Trending/te/terraform-aws-eks本文基于仓库内 docs/CHANGELOG.pre-v11.0.0.md 整理完整复盘terraform-aws-eks模块从 2018 年 6 月首次发布v0.1.0到 2020 年 3 月v10.0.0的演进历程。文章围绕 Worker 节点供应方式、IAM 与安全模型、弹性扩缩容、加密与集群管控等核心主线展开梳理每一次破坏性变更的动机、迁移命令与状态操作并对照当前仓库v21.x源码验证这些历史决策的最终形态。读完本文你将理解该模块从裸 ASG 到 EKS 托管节点组、从 kubectl 拼接到 Kubernetes Provider 管理 aws-auth、从单一大集群到子模块化的架构逻辑并掌握各版本升级时的关键操作terraform import、terraform state等。一、版本时间线总览docs/CHANGELOG.pre-v11.0.0.md记录了 v0.1.0 至 v10.0.0 共 20 余个版本的变更覆盖两年内的持续迭代。按发布时间线整理如下版本发布日期核心主题v0.1.02018-06-07模块首次发布提供集群 自管理 Worker 基础能力v0.2.02018-06-08支持自定义 UserData、EBS 优化、configure_kubectl_sessionv1.0.02018-06-11支持自定义集群/Worker 安全组多 ASG 重构v1.3.02018-07-11引入map_accounts/map_roles/map_users管理 aws-authv1.5.02018-08-30Spot 实例、监控开关、可选附加的 Autoscaling 策略v1.6.02018-09-04迁移到amazon-eks-node-*AMI 与 bootstrap 脚本v1.8.02018-12-04支持 Launch Template 定义 ASGv2.0.02018-12-14引入*_count变量解决 computed value 问题v2.1.02019-01-15基于 Launch Template 的 Worker 组初始支持v2.3.12019-03-26EKS 公网/私网端点支持v3.0.02019-04-15控制面日志cluster_enabled_log_typesv4.0.02019-05-07重写 Launch Template 代码混合实例策略v5.0.02019-06-19Terraform 0.12 支持移除全部xx_count变量v6.0.02019-09-17worker_groups_launch_template统一混合实例EKS 1.14v7.0.02019-10-30自定义 AMI、Windows Worker、config_output_path重定义v8.0.02020-01-09EKS Managed Node Group、IRSA、aws-auth 改由 Kubernetes Provider 管理v9.0.02020-02-27移除 Autoscaling IAM 策略与标签新增examples/irsav10.0.02020-03-12EKS 1.15 支持、Secret 信封加密、EBS 加密选项从时间线可以清晰看到模块演进的三条主线数据面供应方式的持续抽象ASG → Launch Template → Managed Node Group、安全与认证体系的收敛安全组规则集中化、aws-auth 托管化、IRSA 引入、Terraform 生态的跟随0.11 → 0.12、required_providers、对象类型变量。二、数据面演进从裸 ASG 到 EKS 托管节点组2.1 多 ASG 支持v1.0.0与 Worker 组配置化v1.x模块早期采用一个集群 自管理 Worker ASG的经典形态。v1.0.0 将 Worker 构建逻辑重构为支持多个规格各异的 Autoscaling Group未指定任何组时以一组合理默认值创建单个 ASG。v1.1.0 补充了worker_sg_ingress_from_port控制 Pod 通信最小端口、公网 IP 附着与 SSH Key 配置并将 ASG 从name改为name_prefix以便资源可重建。v1.3.0 引入map_accounts/map_roles/map_users三个顶层变量管理aws-authConfigMap 的额外条目同时支持每个 ASG 指定独立的子网列表、输出worker_iam_role_arn。v1.4.0 则允许管理 Worker 根卷大小与类型并新增worker_group_count顶层变量用于替代length(var.worker_groups)——这是为了在 Worker 组配置中引入 computed value。2.2 Launch Template 的引入与统一v2.1.0 → v4.0.0 → v6.0.0v1.8.0 首次支持使用 AWS Launch Template 定义 Autoscaling Groupv2.1.0 提供基于 Launch Template 的 Worker 组初始支持新增worker_groups_launch_template与worker_group_count_launch_template变量。v4.0.0 是一次重要重构重写并去重了 Launch Template 相关代码Breaking Change同时新增混合实例策略Mixed Instances PolicyWorker 组选项、自定义 ASG Service-Linked Role、自定义集群/Worker IAM 角色并默认将 ASG 的 suspended processes 设为AZRebalance。v6.0.0 完成统一新增market_type允许不使用混合实例策略即可使用 Spot、并移除worker_groups_launch_template_mixed变量Breaking混合实例能力并入worker_groups_launch_template。该版本还引入required_providers强制 Provider 最低版本、将 ASG 标签生成改为 Terraform 0.12 的for表达式。从当前仓库看这一演进方向的终点是节点组子模块化modules/self-managed-node-group/独立承载自管理节点组AutoScaling Group IAM 角色 安全组 Launch Template其 README 展示了独立使用示例modules/self-managed-node-group/README.md而modules/eks-managed-node-group/对应托管节点组。两者的设计都继承了历史版本的输入形态min_size/max_size/desired_size、instance_types、capacity_type、labels、taints等。2.3 EKS Managed Node Group 支持v8.0.0v8.0.0 是本模块的重要分水岭新增对EKS Managed Node Group的支持要求 AWS Provider 2.38.0并将eks_node_group资源下沉为子模块、新增复杂输出node_groups与节点组 IAM 角色 ARN 输出。v9.0.0 进一步为托管节点组增加name参数允许手动命名节点组。对应到当前代码main.tf 通过eks_managed_node_groups变量在顶层声明托管节点组modules/eks-managed-node-group/main.tf 负责实际资源编排示例见 examples/eks-managed-node-group/main.tf含 AL2023 与 Bottlerocket 两种 AMI 类型。v8.1.0 还增加了ignore_lifecycle规则防止 Terraform 在 EKS Managed Node Group 背后误缩容 ASG——这一细节延续至今体现了托管节点组应交给 EKS 控制平面管理的设计原则。2.4 AMI 处理策略的演变AMI 查找与自定义贯穿多个版本v0.2.0 起workers_ami_id变为可选未指定时模块自动查找 AWS 官方最新 EKS AMIv1.6.0Breaking移除对旧eks-worker-*AMI 的支持全面切换到带 bootstrap 脚本的amazon-eks-node-*AMI并将kubelet_node_labels替换为更通用的kubelet_extra_argsv6.0.1 支持不同 Worker 使用不同 AMI如 GPU AMIv7.0.0Breaking允许为 Worker 节点指定自定义 AMI且AMI 必须使用完整名称如amazon-eks-node-1.14-v20190927v10.0.0 明确 AMI 查找层级worker_group_launch_templates和worker_groups→worker_group_defaults→ 最后回退到 AWS AMI 查找。当前版本中modules/eks-managed-node-group/与modules/self-managed-node-group/均默认ami_type AL2023_x86_64_STANDARD见 modules/self-managed-node-group/README.md 的输入表并支持ami_id自定义配合 UserData 模板渲染modules/_user_data/与 templates/ 目录延续了 v6.0.0 以来userdata_template_file的定制能力。三、IAM 与安全模型演进3.1 aws-auth ConfigMap 管理方式的两次变革早期版本v1.3.0 起通过map_accounts/map_roles/map_users变量注入 aws-auth 条目底层使用 kubectl 与null_resource应用配置。v2.1.0 增加应用 aws-auth 失败后最多重试 10 次并失败退出的健壮性处理v2.2.0 引入write_aws_auth_config与managed_aws_auth选项。v8.0.0 是 Breaking Changeaws-auth ConfigMap 的管理方式从 kubectl null_resource 改为Terraform Kubernetes Provider 管理。升级步骤如下原文档原文命令在调用模块处添加 kubernetes provider参考examples目录将 ConfigMap 导入 Terraform 状态terraform import module.cluster1.kubernetes_config_map.aws_auth[0] kube-system/aws-auth或者在 apply 之前删除 aws-auth ConfigMap——但这要求使用创建集群的同一用户/角色执行 apply。同时移除不再使用的write_aws_auth_config变量并在map_roles为空时跳过 ConfigMap 渲染、更新失败时以非零错误码退出v8.0.0。到当前版本v21.x这一领域再次演进为Cluster Access Entries模块通过access_entries变量管理 IAM 主体的集群访问权限并为自管理节点组、Karpenter 子模块自动创建访问条目见 README.md 的 Cluster Access Entry 一节。aws-auth 相关逻辑已随aws-auth子模块在 v21 中移除见 docs/UPGRADE-21.0.md完整反映了从 kubectl 拼接到声明式托管的历史闭环。3.2 安全组白名单逻辑v8.0.0 Breakingv8.0.0 的另一项 Breaking Change 是安全组白名单逻辑无论用户提供还是新建 Worker 安全组模块都会将 Worker 安全组加入控制面安全组的白名单。升级时需要移除cluster_create_security_group与worker_create_security_group两个变量若此前已手工建立白名单规则需删除后重新 apply 或导入terraform import module.eks.aws_security_group_rule.cluster_https_worker_ingress CONTROL_PLANE_SECURITY_GROUP_ID_ingress_tcp_443_443_WORKER_SECURITY_GROUP_ID这条规则的变迁脉络在历史中非常清晰v1.0.0 支持用户提供集群/Worker 安全组、未提供则由模块按足够集群-Worker 通信的规则创建v2.0.0 与 v1.8.0 引入cluster_create_security_group/worker_create_security_group以规避count cannot be computed错误v2.3.1 按 EKS 安全组要求加入最小入站规则v8.2.0 支持在存在 Worker 安全组时禁用 ingress 规则创建。对照当前 node_groups.tfL76-L109中的node_security_group_rules可以看到这些历史规则的最终形态集群 API 到节点组的 443、集群 API 到 kubelet 的 10250、节点间 CoreDNS 的 TCP/UDP 53以及推荐规则中的节点间临时端口段1025-65535等均由模块集中声明式管理。3.3 IRSA 与 OIDCv8.0.0 起v8.0.0 同时引入了IAM Roles for Service AccountsIRSA支持创建 IAM OpenID Connect Identity Provider、输出cluster_oidc_issuer_url从 list 修正为 string与 OIDC Provider ARN。v9.0.0 新增examples/irsa示例演示为 cluster-autoscaler 的 ServiceAccount 关联 IAM 角色同时将iam:{Create,Delete,Get}OpenIDConnectProvider加入docs/iam-permissions.md的所需权限清单。v21 中 IRSA 仍是核心能力cluster_identity_providers变量不过 OIDC issuer URL 已切换到新的双栈oidc-eks端点见 docs/UPGRADE-21.0.md而 Karpenter 子模块已默认改用 EKS Pod Identity。四、弹性、成本与数据加密能力4.1 Spot 与混合实例v1.5.0 为aws_launch_configuration增加spot_price选项v4.0.0 增加带混合实例策略的 Worker 组选项并在 README 补充 Spot 实例说明v6.0.0 为workers_launch_template.tf增加market_type无需混合实例策略即可使用 Spot 节点组同时更新capacity-optimized选项说明。历史文档还特别指出cluster-autoscaler 应调度在普通实例而非 Spot 实例上v10.0.0 的文档修正。4.2 ASG 弹性控制弹性相关能力逐版本积累suspended_processesv1.8.0、target_group_arnsv1.8.0、protect_from_scale_inv1.7.0解决 issue #134、ASG 生命周期钩子v6.0.2 / v6.0.0、LT/LC 变更时重建 ASGv6.0.0、default_cooldown与health_check_grace_periodv10.0.0、ASG 最大实例寿命v10.0.0、Termination Policyv5.0.0、force_delete与 ASG 标签v2.2.0、enabled_metricsv2.2.0。v9.0.0 的重要决策是移除 Autoscaling IAM 策略与标签该策略原先附着在节点组 IAM 角色上移除后降低了复杂度并提升了安全性。需要在模块外管理时可参照examples/irsa为 cluster-autoscaler 的 ServiceAccount 关联 IAM 角色或使用workers_additional_policies变量传入外部创建的策略。v6.0.2 也将 autoscaler 与 CNI 的 IAM 策略附加改为可选。4.3 数据加密加密能力是本模块安全主线的另一半v2.3.0 为workers_launch_template增加 EBS 加密v5.1.0 支持为日志组指定 KMS Key 并启用加密同时输出 CloudWatch 日志组名称v10.0.0 支持Kubernetes Secrets 信封加密envelope encryption与 Worker 根卷encrypted选项从 Worker 配置读取。当前 main.tfL124-L134中的encryption_config动态块展示了最终实现create_kms_key为 true 时自动创建 KMS Key否则使用provider_key_arnresources支持指定加密的资源如secrets。v21 中 EKS 已默认对 Secrets 静态加密模块默认以 AWS 托管密钥启用详见 docs/UPGRADE-21.0.md。五、集群管控与运维能力5.1 端点与日志v2.3.1 支持 EKS 公网/私网端点配置v8.1.0 支持限制公共 API 端点访问endpoint_public_access_cidrs的前身v3.0.0 通过cluster_enabled_log_types支持控制面日志EKS 控制面日志功能v5.1.0 支持日志保留期v6.0.0 支持日志组标签v5.1.0 起示例按 ELB/ALB 文档正确标记网络并设置enable_dns_hostnames true。当前 variables.tf 中enabled_log_types默认值为[audit, api, authenticator]main.tfL36-L58中aws_eks_cluster.this完整呈现了端点endpoint_private_access/endpoint_public_access/public_access_cidrs、日志enabled_cluster_log_types、删除保护deletion_protection与认证模式authentication_mode的最终配置面。5.2 kubeconfig 与等待集群就绪v0.2.0 起configure_kubectl_session true时可用模块输出的配置文件配置当前 shellv2.3.0 输出生成的 kubeconfig 文件名v1.2.0 使 kubeconfig 更灵活v7.0.0Breakingconfig_output_path现在支持完整指定 kubeconfig 文件路径而不再假定为目录此前文档建议以/结尾集群就绪等待逻辑逐步健壮v9.0.0 将wait_for_cluster_cmd默认从 curl 改为 wgetv8.2.0 支持自定义等待集群健康的 OS 专属命令v7.0.1 调整 aws-auth ConfigMap 的创建顺序先生成kube_config.yaml与aws_auth_configmap.yaml再执行kubectl applyv8.0.0 在应用 auth map 前先等待集群响应 kubectl。当前实现中node_groups.tfL10-L23的time_sleep.this资源延续了集群就绪后再创建数据面依赖的思路通过dataplane_wait_duration控制等待时长并以集群 ID、endpoint、版本、Service CIDR 与 CA 数据作为触发器。5.3 IAM 角色与实例配置细节面向企业合规与多样工作负载的细节同样贯穿历史IAM 角色路径v2.2.2、permissions_boundaryv2.2.0、force_detach_policiesv1.8.0、Worker 角色名称自定义v6.0.0、自定义集群/Worker IAM 角色v4.0.0、Worker 组指定 IAM 实例配置文件v1.7.0、Placement Groupv2.3.0/v1.7.0 的placement_tenancy、cpu_creditsv5.1.0、EBS 优化实例类型列表维护v7.0.0/v5.0.0、bootstrap_extra_args取代enable_docker_bridgev2.3.1Breaking、pre_userdatav1.2.0与用户自定义 UserData 模板v7.0.0 的userdata_template_file/userdata_template_extra_args等。六、升级迁移实战必须掌握的状态操作历史版本中有三次典型的破坏性迁移其操作手法对今天仍有借鉴价值6.1 Terraform 0.12 迁移v5.0.0v5.0.0 完成 Terraform 0.12 支持移除所有xx_count变量、Worker 组 map 从逗号分隔字符串改为真实列表、worker_group_tags迁移为 Worker 组的tags属性、混合实例策略的override instance_types改为列表。这属于大规模 HCL 语法与类型重构升级时需逐项核对变量定义。6.2 混合实例变量合并v6.0.0需要将 Worker 组从worker_groups_launch_template_mixed迁移到worker_groups_launch_template可通过Terraform 状态重命名避免破坏性变更terraform state mv module.eks.aws_autoscaling_group.workers_launch_template_mixed[0] module.eks.aws_autoscaling_group.workers_launch_template[0]同时map_roles条目需将role_arn改名为rolearn、group 改为groups []。6.3 认证与安全组迁移v8.0.0如第三节所述aws-auth ConfigMap 需执行terraform import module.cluster1.kubernetes_config_map.aws_auth[0] kube-system/aws-auth安全组白名单规则需导入aws_security_group_rule.cluster_https_worker_ingress地址格式为CONTROL_PLANE_SG_ID_ingress_tcp_443_443_WORKER_SG_ID。另外 v1.5.0 移除workstation_cidr变量时也要求清理状态terraform state rm module.eks.data.http.workstation_external_ip这些案例共同说明一个原则模块在引入破坏性变更时通常提供 state 导入/重命名路径以保留现有资源升级前应优先采用而非直接删除重建。七、历史演进的最终形态与当前仓库的呼应将 v11 之前的演进与当前 v21.x 源码对照可以看到清晰的传承子模块化v8.0.0 将eks_node_group下沉为子模块如今 modules/ 下已形成eks-managed-node-group、self-managed-node-group、fargate-profile、karpenter、hybrid-node-role、capability、_user_data的完整模块矩阵声明式安全aws-auth 从 kubectl/null_resource 到 Kubernetes Provider再到 v21 的access_entries全部收敛为 Terraform 声明供应方式收敛从worker_groups/worker_groups_launch_template的历史双轨演变为顶层eks_managed_node_groups 子模块的统一抽象并随 EKS Auto Modecompute_config与 EKS Provisioned Control Planecontrol_plane_scaling_config继续前进见 README.md 与 examples/eks-auto-mode/main.tfProvider 版本纪律v6.0.0 引入required_providers当前 versions.tf 要求 Terraform 1.5.7、AWS Provider 6.52、TLS 4.0、time 0.9并设置provider_metauser-agent。结语docs/CHANGELOG.pre-v11.0.0.md表面上是一份版本流水账实质上浓缩了 EKS 基础设施即代码的最佳实践演化史从自己管理一切逐步让位于托管服务 声明式配置从命令式 kubectl 拼接到纯 Terraform 生命周期管理。对于仍在维护 v10 及更早版本集群的团队本文第三、六节提供了直接的迁移指引对于新用户理解这段历史有助于更准确地把握 v21 中access_entries、节点组子模块、EKS Addons 等设计的来龙去脉。若需了解 v11 之后直至 v21的完整变更可继续阅读仓库根目录的 CHANGELOG.md 与 docs/UPGRADE-17.0.md、docs/UPGRADE-18.0.md、docs/UPGRADE-19.0.md、docs/UPGRADE-20.0.md、docs/UPGRADE-21.0.md 系列升级指南。【免费下载链接】terraform-aws-eksTerraform module to create Amazon Elastic Kubernetes (EKS) resources 项目地址: https://gitcode.com/GitHub_Trending/te/terraform-aws-eks创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表