Terraform AWS EKS 计算资源指南Managed Node Group、Self Managed Node Group 与 Fargate 配置实战【免费下载链接】terraform-aws-eksTerraform module to create Amazon Elastic Kubernetes (EKS) resources 项目地址: https://gitcode.com/GitHub_Trending/te/terraform-aws-eks本文聚焦 terraform-aws-eks 模块中三类核心计算资源——EKS Managed Node Groups托管节点组、Self Managed Node Groups自管节点组与 Fargate ProfilesFargate 配置档。通过本指南你将掌握自定义启动模板Launch Template的使用与关闭、Bottlerocket OS 的原生接入、自定义 AMI 下的 bootstrap 用户数据注入含 AL2023 nodeadm 与 cloud-init 配置、默认 AMI 自动选取等实战能力并理解这些能力在模块源码中的实现原理。为保持篇幅紧凑本文仅展示与主题相关的关键属性与官方文档一致完整输入参数请参阅各子模块的variables.tf。目录EKS Managed Node Groups托管节点组Self Managed Node Groups自管节点组Fargate ProfilesFargate 配置档默认配置速查EKS Managed Node Groups托管节点组EKS Managed Node Groups 由 AWS EKS 服务负责节点的生命周期管理升级、替换、扩缩容是生产环境中最省心的算力形态。在 terraform-aws-eks 中节点组通过根模块的eks_managed_node_groups变量声明每个键对应 modules/eks-managed-node-group 子模块的一个实例该子模块最终创建aws_eks_node_group资源见 modules/eks-managed-node-group/main.tf。1. 自定义启动模板默认开启可按需关闭模块默认会为每个托管节点组创建自定义 Launch Template启动模板以确保标签tags等设置能正确传播到实例。这一点可以在 modules/eks-managed-node-group/variables.tf 中得到印证create_launch_template与use_custom_launch_template的默认值均为truemodules/eks-managed-node-group/main.tf 中aws_launch_template.this的创建条件正是var.create var.create_launch_template var.use_custom_launch_template。需要特别注意的是文档中列出的许多自定义选项只有在使用自定义启动模板时才生效。例如block_device_mappings数据盘配置、metadata_optionsIMDSv2 强制、placement放置策略、instance_market_optionsSpot 购买选项等都是写入启动模板的属性。如果希望使用 AWS EKS 托管节点组服务提供的默认模板只需将use_custom_launch_template设为falseeks_managed_node_groups { default { use_custom_launch_template false } }关闭自定义启动模板后disk_size与remote_access参数才会生效见 modules/eks-managed-node-group/variables.tf 与 main.tf 中的注释说明而use_custom_launch_template false时aws_eks_node_group的launch_template动态块不会被渲染main.tf。2. Bottlerocket OS 原生支持通过 ami_type 启用模块对Bottlerocket OS提供原生支持只需在节点组中指定对应的 AMI 类型即可。Bottlerocket 是 AWS 出品的专为容器设计的极简 Linux 发行版其安全性与更新机制image-based、原子更新广受青睐eks_managed_node_groups { bottlerocket_default { use_custom_launch_template false ami_type BOTTLEROCKET_x86_64 } }从源码看模块对 Bottlerocket 的支持不止于ami_type透传。在 modules/eks-managed-node-group/main.tf 中定义了一张AMI 类型到 SSM Parameter 路径的映射表覆盖BOTTLEROCKET_ARM_64、BOTTLEROCKET_x86_64、FIPS 与 NVIDIA 变体如BOTTLEROCKET_x86_64_FIPS、BOTTLEROCKET_x86_64_NVIDIAssm_ami_type_to_ssm_param { ... BOTTLEROCKET_x86_64 /aws/service/bottlerocket/aws-k8s-${local.ssm_kubernetes_version}/x86_64/latest/image_version BOTTLEROCKET_x86_64_FIPS /aws/service/bottlerocket/aws-k8s-${local.ssm_kubernetes_version}-fips/x86_64/latest/image_version BOTTLEROCKET_x86_64_NVIDIA /aws/service/bottlerocket/aws-k8s-${local.ssm_kubernetes_version}-nvidia/x86_64/latest/image_version ... }这意味着当use_latest_ami_release_version true默认值时模块会通过data aws_ssm_parameter自动查询对应 Kubernetes 版本与 AMI 类型的最新发布版本并写入release_versionmain.tf确保节点始终使用最新且经过验证的 Bottlerocket 镜像。完整的 AMI 类型取值还包含 AL2、AL2023、Windows 等系列均可参考该映射表。3. Bottlerocket 用户数据TOML 格式与 bootstrap_extra_args与 Amazon Linux 的 Shell 脚本用户数据不同Bottlerocket 的用户数据采用 TOML 格式。模块通过bootstrap_extra_args向 Bottlerocket 用户数据追加额外的 settings 配置eks_managed_node_groups { bottlerocket_prepend_userdata { ami_type BOTTLEROCKET_x86_64 bootstrap_extra_args -EOT # extra args added [settings.kernel] lockdown integrity EOT } }其渲染逻辑位于 templates/bottlerocket_user_data.tpl当enable_bootstrap_user_data为真时模板先输出[settings.kubernetes]段包含cluster-name、api-server、cluster-certificate、cluster-dns-ip等必要字段随后原样追加bootstrap_extra_args%{ if enable_bootstrap_user_data ~} [settings.kubernetes] cluster-name ${cluster_name} api-server ${cluster_endpoint} cluster-certificate ${cluster_auth_base64} cluster-dns-ip ${cluster_dns_ips} %{ endif ~} ${bootstrap_extra_args ~}在 examples/eks-managed-node-group/eks-bottlerocket.tf 中可以看到更完整的实战示例——通过bootstrap_extra_args管理 Bottlerocket 的 host containersbootstrap_extra_args -EOT # The admin host container provides SSH access and runs with superpowers. # It is disabled by default, but can be disabled explicitly. [settings.host-containers.admin] enabled false # The control host container provides out-of-band access via SSM. # It is enabled by default, and can be disabled if you do not expect to use SSM. [settings.host-containers.control] enabled true # extra args added [settings.kernel] lockdown integrity EOTbootstrap_extra_args在 modules/eks-managed-node-group/variables.tf 中的定义为当ami_type为BOTTLEROCKET_*时提供的是附加的 Bottlerocket settingsTOML 片段否则是传给 EKS bootstrap 脚本的附加命令行参数。4. 自定义 AMI启用模块提供的 bootstrap 用户数据使用自定义 AMI 时有一个关键行为需要理解AWS EKS Managed Node Group 服务不会将必要的 bootstrap 脚本注入到用户提供的 user data 中。此时有两条路径用户自己提供完整的 user data 来完成节点引导bootstrap并接入集群选择启用模块提供的用户数据模板enable_bootstrap_user_data true来把引导逻辑加回来。eks_managed_node_groups { custom_ami { ami_id ami-0caf35bc73450c396 ami_type AL2023_x86_64_STANDARD # By default, EKS managed node groups will not append bootstrap script; # this adds it back in using the default template provided by the module # Note: this assumes the AMI provided is an EKS optimized AMI derivative enable_bootstrap_user_data true cloudinit_pre_nodeadm [{ content -EOT --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: kubelet: config: shutdownGracePeriod: 30s EOT content_type application/node.eks.aws }] # This is only possible when ami_id is specified, indicating a custom AMI cloudinit_post_nodeadm [{ content -EOT echo All done EOT content_type text/x-shellscript; charset\us-ascii\ }] } }这里需要解释两个新出现的概念它们对应 AL2023 时代的 EKS 节点引导机制nodeadm自 Kubernetes 1.30 起AL2023 是 EKS 托管节点组的默认 AMI 类型节点引导由新一代工具nodeadm负责它通过一个名为NodeConfig的 Kubernetes 风格 APIapiVersion: node.eks.aws/v1alpha1来声明集群信息与 kubelet 配置cloudinit_pre_nodeadm / cloudinit_post_nodeadm分别定义在 nodeadm 文档部分之前与之后插入的 cloud-init 文档片段MIME part。前者适合放置 NodeConfig 扩展配置如示例中的shutdownGracePeriod后者适合执行自定义脚本。当enable_bootstrap_user_data true时模块在 _user_data 子模块 中会把用户数据拼装成完整的 MIME 多部分文档先插入cloudinit_pre_nodeadm中的片段中间是模块渲染出的 nodeadm 引导内容application/node.eks.aws类型最后追加cloudinit_post_nodeadm片段整体通过data.cloudinit_config进行 base64 编码后写入启动模板的user_data。这就是只在指定ami_id自定义 AMI 时才可用cloudinit_post_nodeadm的原因——只有自定义 AMI 场景下模块才完全接管用户数据的生成。AL2023 的默认用户数据模板见 templates/al2023_user_data.tpl它生成的是一个标准 NodeConfig%{ if enable_bootstrap_user_data ~} --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: ${cluster_name} apiServerEndpoint: ${cluster_endpoint} certificateAuthority: ${cluster_auth_base64} cidr: ${cluster_service_cidr} %{ endif ~}在 examples/eks-managed-node-group/eks-al2023.tf 中可以看到相同的cloudinit_pre_nodeadm用法它展示了如何通过 NodeConfig 为 kubelet 设置shutdownGracePeriod: 30s。cloudinit_pre_nodeadm与cloudinit_post_nodeadm的类型定义见 modules/eks-managed-node-group/variables.tf每个片段支持content、content_type、filename、merge_type四个可选字段方便精确控制 MIME 文档的合并行为。5. Bottlerocket 自定义 AMI模板引导 扩展设置Bottlerocket OS 的自定义 AMI 场景提供类似支持启用模块用户数据模板完成节点引导再通过bootstrap_extra_args注入额外设置。下面的示例同时演示了节点标签node-labels与污点node-taints的配置——这在把节点组划分为专用角色如 GPU 节点、基础设施节点时非常实用eks_managed_node_groups { bottlerocket_custom_ami { ami_id ami-0ff61e0bcfc81dc94 ami_type BOTTLEROCKET_x86_64 # use module user data template to bootstrap enable_bootstrap_user_data true # this will get added to the template bootstrap_extra_args -EOT # extra args added [settings.kernel] lockdown integrity [settings.kubernetes.node-labels] label1 foo label2 bar [settings.kubernetes.node-taints] dedicated experimental:PreferNoSchedule special true:NoSchedule EOT } }结合 templates/bottlerocket_user_data.tpl 可以看出当enable_bootstrap_user_data true时模板会填充集群连接所需的[settings.kubernetes]基础字段集群名、API Server 地址、CA 证书、DNS IPbootstrap_extra_args中额外指定的 labels、taints 等设置会被直接合并进最终的 TOML 用户数据节点启动后自动完成注册与标签/污点应用。完整的多种配置组合示例可参考 examples/eks-managed-node-group 目录含 AL2023 与 Bottlerocket 两个独立示例模块示例中的 VPC 与子网准备见 examples/eks-managed-node-group/main.tf。Self Managed Node Groups自管节点组Self Managed Node Groups 将节点生命周期管理交还给用户模块基于 EC2Auto Scaling GroupASG Launch Template构建节点组适合需要完全掌控节点配置自定义 AMI、特定引导逻辑、混合实例策略等的场景。对应实现位于 modules/self-managed-node-group。1. 默认使用最新 EKS Optimized AMI自管节点组的默认行为是根据给定的 Kubernetes 版本自动使用最新的 AWS EKS Optimized AMILinux。只需要提供kubernetes_version连ami_id都可以不写kubernetes_version 1.33 # This self managed node group will use the latest AWS EKS Optimized AMI for Kubernetes 1.33 self_managed_node_groups { default {} }从 modules/self-managed-node-group/variables.tf 可以看到kubernetes_version的说明即为Kubernetes cluster version - used to lookup default AMI ID if one is not providedami_type的默认值为AL2023_x86_64_STANDARD。模块内部通过 SSM Parameter 按版本与 AMI 类型解析出最新的 EKS Optimized AMI因此用户无需手工维护 AMI ID。2. 使用 Bottlerocket指定 ami_type 并提供 AMI在自管节点组中使用 Bottlerocket 与托管节点组类似指定ami_type为对应的BOTTLEROCKET_*类型同时提供 Bottlerocket OS AMI通常通过data.aws_ami按名称过滤获取最新版本kubernetes_version 1.33 self_managed_node_groups { bottlerocket { ami_id data.aws_ami.bottlerocket_ami.id ami_type BOTTLEROCKET_x86_64 } }自管节点组的bootstrap_extra_args行为与托管节点组一致在 Bottlerocket 场景下作为 TOML settings 追加。完整的实战示例见 examples/self-managed-node-group/eks-bottlerocket.tf其中演示了通过bootstrap_extra_args管理host-containers.admin与host-containers.controlSSM 带外访问通道开关以及[settings.kernel] lockdown integrity的内核加固设置。自管节点组的其他高级能力均可从 modules/self-managed-node-group/variables.tf 查阅包括扩缩容min_size/max_size/desired_size默认 1/3/1以及protect_from_scale_in、capacity_rebalance等 ASG 行为控制实例策略use_mixed_instances_policy支持按需 Spot 混合实例含instances_distribution与按属性选择实例的instance_requirements滚动更新默认开启instance_refresh策略Rollingmin_healthy_percentage 66支持auto_rollback、checkpoint_percentages等偏好设置生命周期钩子initial_lifecycle_hooks可在实例启动前注入自定义动作实例类型默认m6i.largevariables.tf。多种配置组合的完整示例见 examples/self-managed-node-group 目录。Fargate ProfilesFargate 配置档Fargate Profiles 使用起来非常直接通过根模块的fargate_profiles变量声明即可因此官方文档未在此展开细节。核心思路是将命名空间namespace与选择标签selector映射到 Fargate 算力让符合条件的 Pod 自动调度到 AWS Fargate 上运行无需管理任何节点。模块实现位于 modules/fargate-profile含 migrations.tf 迁移逻辑可参考的可用配置组合见 tests/eks-fargate-profile 测试目录中的示例。一个典型的 Fargate Profile 声明大致为fargate_profiles { default { selectors [ { namespace kube-system } ] } }完整参数以 modules/fargate-profile/variables.tf 为准。默认配置速查以下为计算资源相关的模块默认值速查便于快速评估默认行为均来源于各子模块variables.tf配置项默认值说明use_custom_launch_template托管true托管节点组默认创建并使用自定义启动模板以便标签传播到实例ami_typeAL2023_x86_64_STANDARD默认 AMI 类型AL2023 x86_64 标准版capacity_typeON_DEMAND托管节点组容量类型可选ON_DEMAND/SPOTmin_size/max_size/desired_size1/3/1节点组扩缩容边界desired_size在初次创建后被忽略instance_type自管m6i.large自管节点组默认实例类型instance_types托管t3.medium托管节点组默认实例类型use_latest_ami_release_versiontrue通过 SSM Parameter 自动解析最新 AMI 发布版本enable_bootstrap_user_datafalse是否使用模块用户数据模板进行引导仅自定义 AMI指定ami_id时有效update_configmax_unavailable_percentage 33托管节点组更新时最多不可用节点百分比instance_refresh自管Rollingmin_healthy_percentage 66自管节点组默认滚动更新策略小结通过本指南可以明确三类计算资源的选型与配置要点托管节点组适合追求低运维的场景默认自定义启动模板保证标签一致性Bottlerocket 通过ami_type一行启用自定义 AMI 下用enable_bootstrap_user_datacloudinit_pre/post_nodeadm接管引导自管节点组适合需要完全掌控节点与 ASG 行为的场景默认按 Kubernetes 版本自动匹配最新 EKS Optimized AMI同时具备混合实例、实例刷新等高级能力Fargate适合按 Pod 粒度运行无状态工作负载配置档声明简单直接。无论选择哪种形态模块的默认值都经过了生产实践沉淀如 AL2023 默认 AMI、IMDSv2 强制、滚动更新保护比例等直接使用即可获得安全的基线配置在需要自定义时请结合各子模块 modules/eks-managed-node-group/variables.tf 与 modules/self-managed-node-group/variables.tf 的完整参数说明进行配置。【免费下载链接】terraform-aws-eksTerraform module to create Amazon Elastic Kubernetes (EKS) resources 项目地址: https://gitcode.com/GitHub_Trending/te/terraform-aws-eks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Terraform AWS EKS 计算资源指南Managed Node Group、Self Managed Node Group 与 Fargate 配置实战【免费下载链接】terraform-aws-eksTerraform module to create Amazon Elastic Kubernetes (EKS) resources 项目地址: https://gitcode.com/GitHub_Trending/te/terraform-aws-eks本文聚焦 terraform-aws-eks 模块中三类核心计算资源——EKS Managed Node Groups托管节点组、Self Managed Node Groups自管节点组与 Fargate ProfilesFargate 配置档。通过本指南你将掌握自定义启动模板Launch Template的使用与关闭、Bottlerocket OS 的原生接入、自定义 AMI 下的 bootstrap 用户数据注入含 AL2023 nodeadm 与 cloud-init 配置、默认 AMI 自动选取等实战能力并理解这些能力在模块源码中的实现原理。为保持篇幅紧凑本文仅展示与主题相关的关键属性与官方文档一致完整输入参数请参阅各子模块的variables.tf。目录EKS Managed Node Groups托管节点组Self Managed Node Groups自管节点组Fargate ProfilesFargate 配置档默认配置速查EKS Managed Node Groups托管节点组EKS Managed Node Groups 由 AWS EKS 服务负责节点的生命周期管理升级、替换、扩缩容是生产环境中最省心的算力形态。在 terraform-aws-eks 中节点组通过根模块的eks_managed_node_groups变量声明每个键对应 modules/eks-managed-node-group 子模块的一个实例该子模块最终创建aws_eks_node_group资源见 modules/eks-managed-node-group/main.tf。1. 自定义启动模板默认开启可按需关闭模块默认会为每个托管节点组创建自定义 Launch Template启动模板以确保标签tags等设置能正确传播到实例。这一点可以在 modules/eks-managed-node-group/variables.tf 中得到印证create_launch_template与use_custom_launch_template的默认值均为truemodules/eks-managed-node-group/main.tf 中aws_launch_template.this的创建条件正是var.create var.create_launch_template var.use_custom_launch_template。需要特别注意的是文档中列出的许多自定义选项只有在使用自定义启动模板时才生效。例如block_device_mappings数据盘配置、metadata_optionsIMDSv2 强制、placement放置策略、instance_market_optionsSpot 购买选项等都是写入启动模板的属性。如果希望使用 AWS EKS 托管节点组服务提供的默认模板只需将use_custom_launch_template设为falseeks_managed_node_groups { default { use_custom_launch_template false } }关闭自定义启动模板后disk_size与remote_access参数才会生效见 modules/eks-managed-node-group/variables.tf 与 main.tf 中的注释说明而use_custom_launch_template false时aws_eks_node_group的launch_template动态块不会被渲染main.tf。2. Bottlerocket OS 原生支持通过 ami_type 启用模块对Bottlerocket OS提供原生支持只需在节点组中指定对应的 AMI 类型即可。Bottlerocket 是 AWS 出品的专为容器设计的极简 Linux 发行版其安全性与更新机制image-based、原子更新广受青睐eks_managed_node_groups { bottlerocket_default { use_custom_launch_template false ami_type BOTTLEROCKET_x86_64 } }从源码看模块对 Bottlerocket 的支持不止于ami_type透传。在 modules/eks-managed-node-group/main.tf 中定义了一张AMI 类型到 SSM Parameter 路径的映射表覆盖BOTTLEROCKET_ARM_64、BOTTLEROCKET_x86_64、FIPS 与 NVIDIA 变体如BOTTLEROCKET_x86_64_FIPS、BOTTLEROCKET_x86_64_NVIDIAssm_ami_type_to_ssm_param { ... BOTTLEROCKET_x86_64 /aws/service/bottlerocket/aws-k8s-${local.ssm_kubernetes_version}/x86_64/latest/image_version BOTTLEROCKET_x86_64_FIPS /aws/service/bottlerocket/aws-k8s-${local.ssm_kubernetes_version}-fips/x86_64/latest/image_version BOTTLEROCKET_x86_64_NVIDIA /aws/service/bottlerocket/aws-k8s-${local.ssm_kubernetes_version}-nvidia/x86_64/latest/image_version ... }这意味着当use_latest_ami_release_version true默认值时模块会通过data aws_ssm_parameter自动查询对应 Kubernetes 版本与 AMI 类型的最新发布版本并写入release_versionmain.tf确保节点始终使用最新且经过验证的 Bottlerocket 镜像。完整的 AMI 类型取值还包含 AL2、AL2023、Windows 等系列均可参考该映射表。3. Bottlerocket 用户数据TOML 格式与 bootstrap_extra_args与 Amazon Linux 的 Shell 脚本用户数据不同Bottlerocket 的用户数据采用 TOML 格式。模块通过bootstrap_extra_args向 Bottlerocket 用户数据追加额外的 settings 配置eks_managed_node_groups { bottlerocket_prepend_userdata { ami_type BOTTLEROCKET_x86_64 bootstrap_extra_args -EOT # extra args added [settings.kernel] lockdown integrity EOT } }其渲染逻辑位于 templates/bottlerocket_user_data.tpl当enable_bootstrap_user_data为真时模板先输出[settings.kubernetes]段包含cluster-name、api-server、cluster-certificate、cluster-dns-ip等必要字段随后原样追加bootstrap_extra_args%{ if enable_bootstrap_user_data ~} [settings.kubernetes] cluster-name ${cluster_name} api-server ${cluster_endpoint} cluster-certificate ${cluster_auth_base64} cluster-dns-ip ${cluster_dns_ips} %{ endif ~} ${bootstrap_extra_args ~}在 examples/eks-managed-node-group/eks-bottlerocket.tf 中可以看到更完整的实战示例——通过bootstrap_extra_args管理 Bottlerocket 的 host containersbootstrap_extra_args -EOT # The admin host container provides SSH access and runs with superpowers. # It is disabled by default, but can be disabled explicitly. [settings.host-containers.admin] enabled false # The control host container provides out-of-band access via SSM. # It is enabled by default, and can be disabled if you do not expect to use SSM. [settings.host-containers.control] enabled true # extra args added [settings.kernel] lockdown integrity EOTbootstrap_extra_args在 modules/eks-managed-node-group/variables.tf 中的定义为当ami_type为BOTTLEROCKET_*时提供的是附加的 Bottlerocket settingsTOML 片段否则是传给 EKS bootstrap 脚本的附加命令行参数。4. 自定义 AMI启用模块提供的 bootstrap 用户数据使用自定义 AMI 时有一个关键行为需要理解AWS EKS Managed Node Group 服务不会将必要的 bootstrap 脚本注入到用户提供的 user data 中。此时有两条路径用户自己提供完整的 user data 来完成节点引导bootstrap并接入集群选择启用模块提供的用户数据模板enable_bootstrap_user_data true来把引导逻辑加回来。eks_managed_node_groups { custom_ami { ami_id ami-0caf35bc73450c396 ami_type AL2023_x86_64_STANDARD # By default, EKS managed node groups will not append bootstrap script; # this adds it back in using the default template provided by the module # Note: this assumes the AMI provided is an EKS optimized AMI derivative enable_bootstrap_user_data true cloudinit_pre_nodeadm [{ content -EOT --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: kubelet: config: shutdownGracePeriod: 30s EOT content_type application/node.eks.aws }] # This is only possible when ami_id is specified, indicating a custom AMI cloudinit_post_nodeadm [{ content -EOT echo All done EOT content_type text/x-shellscript; charset\us-ascii\ }] } }这里需要解释两个新出现的概念它们对应 AL2023 时代的 EKS 节点引导机制nodeadm自 Kubernetes 1.30 起AL2023 是 EKS 托管节点组的默认 AMI 类型节点引导由新一代工具nodeadm负责它通过一个名为NodeConfig的 Kubernetes 风格 APIapiVersion: node.eks.aws/v1alpha1来声明集群信息与 kubelet 配置cloudinit_pre_nodeadm / cloudinit_post_nodeadm分别定义在 nodeadm 文档部分之前与之后插入的 cloud-init 文档片段MIME part。前者适合放置 NodeConfig 扩展配置如示例中的shutdownGracePeriod后者适合执行自定义脚本。当enable_bootstrap_user_data true时模块在 _user_data 子模块 中会把用户数据拼装成完整的 MIME 多部分文档先插入cloudinit_pre_nodeadm中的片段中间是模块渲染出的 nodeadm 引导内容application/node.eks.aws类型最后追加cloudinit_post_nodeadm片段整体通过data.cloudinit_config进行 base64 编码后写入启动模板的user_data。这就是只在指定ami_id自定义 AMI 时才可用cloudinit_post_nodeadm的原因——只有自定义 AMI 场景下模块才完全接管用户数据的生成。AL2023 的默认用户数据模板见 templates/al2023_user_data.tpl它生成的是一个标准 NodeConfig%{ if enable_bootstrap_user_data ~} --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: ${cluster_name} apiServerEndpoint: ${cluster_endpoint} certificateAuthority: ${cluster_auth_base64} cidr: ${cluster_service_cidr} %{ endif ~}在 examples/eks-managed-node-group/eks-al2023.tf 中可以看到相同的cloudinit_pre_nodeadm用法它展示了如何通过 NodeConfig 为 kubelet 设置shutdownGracePeriod: 30s。cloudinit_pre_nodeadm与cloudinit_post_nodeadm的类型定义见 modules/eks-managed-node-group/variables.tf每个片段支持content、content_type、filename、merge_type四个可选字段方便精确控制 MIME 文档的合并行为。5. Bottlerocket 自定义 AMI模板引导 扩展设置Bottlerocket OS 的自定义 AMI 场景提供类似支持启用模块用户数据模板完成节点引导再通过bootstrap_extra_args注入额外设置。下面的示例同时演示了节点标签node-labels与污点node-taints的配置——这在把节点组划分为专用角色如 GPU 节点、基础设施节点时非常实用eks_managed_node_groups { bottlerocket_custom_ami { ami_id ami-0ff61e0bcfc81dc94 ami_type BOTTLEROCKET_x86_64 # use module user data template to bootstrap enable_bootstrap_user_data true # this will get added to the template bootstrap_extra_args -EOT # extra args added [settings.kernel] lockdown integrity [settings.kubernetes.node-labels] label1 foo label2 bar [settings.kubernetes.node-taints] dedicated experimental:PreferNoSchedule special true:NoSchedule EOT } }结合 templates/bottlerocket_user_data.tpl 可以看出当enable_bootstrap_user_data true时模板会填充集群连接所需的[settings.kubernetes]基础字段集群名、API Server 地址、CA 证书、DNS IPbootstrap_extra_args中额外指定的 labels、taints 等设置会被直接合并进最终的 TOML 用户数据节点启动后自动完成注册与标签/污点应用。完整的多种配置组合示例可参考 examples/eks-managed-node-group 目录含 AL2023 与 Bottlerocket 两个独立示例模块示例中的 VPC 与子网准备见 examples/eks-managed-node-group/main.tf。Self Managed Node Groups自管节点组Self Managed Node Groups 将节点生命周期管理交还给用户模块基于 EC2Auto Scaling GroupASG Launch Template构建节点组适合需要完全掌控节点配置自定义 AMI、特定引导逻辑、混合实例策略等的场景。对应实现位于 modules/self-managed-node-group。1. 默认使用最新 EKS Optimized AMI自管节点组的默认行为是根据给定的 Kubernetes 版本自动使用最新的 AWS EKS Optimized AMILinux。只需要提供kubernetes_version连ami_id都可以不写kubernetes_version 1.33 # This self managed node group will use the latest AWS EKS Optimized AMI for Kubernetes 1.33 self_managed_node_groups { default {} }从 modules/self-managed-node-group/variables.tf 可以看到kubernetes_version的说明即为Kubernetes cluster version - used to lookup default AMI ID if one is not providedami_type的默认值为AL2023_x86_64_STANDARD。模块内部通过 SSM Parameter 按版本与 AMI 类型解析出最新的 EKS Optimized AMI因此用户无需手工维护 AMI ID。2. 使用 Bottlerocket指定 ami_type 并提供 AMI在自管节点组中使用 Bottlerocket 与托管节点组类似指定ami_type为对应的BOTTLEROCKET_*类型同时提供 Bottlerocket OS AMI通常通过data.aws_ami按名称过滤获取最新版本kubernetes_version 1.33 self_managed_node_groups { bottlerocket { ami_id data.aws_ami.bottlerocket_ami.id ami_type BOTTLEROCKET_x86_64 } }自管节点组的bootstrap_extra_args行为与托管节点组一致在 Bottlerocket 场景下作为 TOML settings 追加。完整的实战示例见 examples/self-managed-node-group/eks-bottlerocket.tf其中演示了通过bootstrap_extra_args管理host-containers.admin与host-containers.controlSSM 带外访问通道开关以及[settings.kernel] lockdown integrity的内核加固设置。自管节点组的其他高级能力均可从 modules/self-managed-node-group/variables.tf 查阅包括扩缩容min_size/max_size/desired_size默认 1/3/1以及protect_from_scale_in、capacity_rebalance等 ASG 行为控制实例策略use_mixed_instances_policy支持按需 Spot 混合实例含instances_distribution与按属性选择实例的instance_requirements滚动更新默认开启instance_refresh策略Rollingmin_healthy_percentage 66支持auto_rollback、checkpoint_percentages等偏好设置生命周期钩子initial_lifecycle_hooks可在实例启动前注入自定义动作实例类型默认m6i.largevariables.tf。多种配置组合的完整示例见 examples/self-managed-node-group 目录。Fargate ProfilesFargate 配置档Fargate Profiles 使用起来非常直接通过根模块的fargate_profiles变量声明即可因此官方文档未在此展开细节。核心思路是将命名空间namespace与选择标签selector映射到 Fargate 算力让符合条件的 Pod 自动调度到 AWS Fargate 上运行无需管理任何节点。模块实现位于 modules/fargate-profile含 migrations.tf 迁移逻辑可参考的可用配置组合见 tests/eks-fargate-profile 测试目录中的示例。一个典型的 Fargate Profile 声明大致为fargate_profiles { default { selectors [ { namespace kube-system } ] } }完整参数以 modules/fargate-profile/variables.tf 为准。默认配置速查以下为计算资源相关的模块默认值速查便于快速评估默认行为均来源于各子模块variables.tf配置项默认值说明use_custom_launch_template托管true托管节点组默认创建并使用自定义启动模板以便标签传播到实例ami_typeAL2023_x86_64_STANDARD默认 AMI 类型AL2023 x86_64 标准版capacity_typeON_DEMAND托管节点组容量类型可选ON_DEMAND/SPOTmin_size/max_size/desired_size1/3/1节点组扩缩容边界desired_size在初次创建后被忽略instance_type自管m6i.large自管节点组默认实例类型instance_types托管t3.medium托管节点组默认实例类型use_latest_ami_release_versiontrue通过 SSM Parameter 自动解析最新 AMI 发布版本enable_bootstrap_user_datafalse是否使用模块用户数据模板进行引导仅自定义 AMI指定ami_id时有效update_configmax_unavailable_percentage 33托管节点组更新时最多不可用节点百分比instance_refresh自管Rollingmin_healthy_percentage 66自管节点组默认滚动更新策略小结通过本指南可以明确三类计算资源的选型与配置要点托管节点组适合追求低运维的场景默认自定义启动模板保证标签一致性Bottlerocket 通过ami_type一行启用自定义 AMI 下用enable_bootstrap_user_datacloudinit_pre/post_nodeadm接管引导自管节点组适合需要完全掌控节点与 ASG 行为的场景默认按 Kubernetes 版本自动匹配最新 EKS Optimized AMI同时具备混合实例、实例刷新等高级能力Fargate适合按 Pod 粒度运行无状态工作负载配置档声明简单直接。无论选择哪种形态模块的默认值都经过了生产实践沉淀如 AL2023 默认 AMI、IMDSv2 强制、滚动更新保护比例等直接使用即可获得安全的基线配置在需要自定义时请结合各子模块 modules/eks-managed-node-group/variables.tf 与 modules/self-managed-node-group/variables.tf 的完整参数说明进行配置。【免费下载链接】terraform-aws-eksTerraform module to create Amazon Elastic Kubernetes (EKS) resources 项目地址: https://gitcode.com/GitHub_Trending/te/terraform-aws-eks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
