mirror of
https://github.com/terraform-aws-modules/terraform-aws-eks.git
synced 2025-09-09 19:32:58 +08:00
feat!: Upgrade min AWS provider and Terraform versions to 6.0 and 1.5.7 respectively (#3412)
* feat!: Upgrade min AWS provider and Terraform versions to `6.0` and `1.5.7` respectively * fix: Remove deprecated arguments in AWS v6.0 provider, upgrade Helm provider to v3.0, bump VPC module to v6.0 * fix: Remove `aws-auth` sub-module * fix: Remove `platform` and `cluster_service_ipv4_cidr` variables from `user-data` sub-module * fix: Resolve all marked `todos` that have been accumulated * fix: Set default `http_put_response_hop_limit` to `1` * fix: Remove IRSA support from Karpenter sub-module * fix: Avoid making GET requests from data sources unless absolutely necessary * feat: Add variable optional attribute definitions * feat: Bump KMS key module version to latest, add remaining variable attribute definitions * fix: Remove `cluster_` prefix from variable names to better match the underlying API * fix: Move all EFA logic to the nodegroup itself * fix: Remove arguments that do not make sense in EKS * fix: Updates from plan validation * fix: Remove more self-managed node group attributes that are commonly not used in EKS clusters * fix: Remove data plane compute `*_defaults` variables that do not work with variable optional attributes * fix: Ignore changes to `bootstrap_self_managed_addons` to aid in upgrade * feat: Add support for `region` argument on relevant resources * feat: Initial pass on upgrade guide * fix: Updates from testing and validating EKS managed node group * fix: Updates from testing and validating self-managed node group * docs: Ensure addon ussage documented is aligned * feat: Switch to dualstack OIDC issuer URL * feat: Allow sourcing over overriding the Karpenter assume role policy * fix: Use `Bool` instead of `StringEquals` for DenyHTTP queue policy * fix: Correct use of `nullable` and default value propagation
This commit is contained in:
+20
-4
@@ -10,7 +10,8 @@ Users can see the various methods of using and providing user data through the [
|
||||
- AMI types of `BOTTLEROCKET_*`, user data must be in TOML format
|
||||
- AMI types of `WINDOWS_*`, user data must be in powershell/PS1 script format
|
||||
- Self Managed Node Groups
|
||||
- `AL2_x86_64` AMI type (default) -> the user data template (bash/shell script) provided by the module is used as the default; users are able to provide their own user data template
|
||||
- `AL2_*` AMI types -> the user data template (bash/shell script) provided by the module is used as the default; users are able to provide their own user data template
|
||||
- `AL2023_*` AMI types -> the user data template (MIME multipart format) provided by the module is used as the default; users are able to provide their own user data template
|
||||
- `BOTTLEROCKET_*` AMI types -> the user data template (TOML file) provided by the module is used as the default; users are able to provide their own user data template
|
||||
- `WINDOWS_*` AMI types -> the user data template (powershell/PS1 script) provided by the module is used as the default; users are able to provide their own user data template
|
||||
|
||||
@@ -24,9 +25,24 @@ When using an EKS managed node group, users have 2 primary routes for interactin
|
||||
|
||||
- Users can use the following variables to facilitate this process:
|
||||
|
||||
```hcl
|
||||
pre_bootstrap_user_data = "..."
|
||||
```
|
||||
For `AL2_*`, `BOTTLEROCKET_*`, and `WINDOWS_*`:
|
||||
```hcl
|
||||
pre_bootstrap_user_data = "..."
|
||||
```
|
||||
|
||||
For `AL2023_*`
|
||||
```hcl
|
||||
cloudinit_pre_nodeadm = [{
|
||||
content = <<-EOT
|
||||
---
|
||||
apiVersion: node.eks.aws/v1alpha1
|
||||
kind: NodeConfig
|
||||
spec:
|
||||
...
|
||||
EOT
|
||||
content_type = "application/node.eks.aws"
|
||||
}]
|
||||
```
|
||||
|
||||
2. If a custom AMI is used, then per the [AWS documentation](https://docs.aws.amazon.com/eks/latest/userguide/launch-templates.html#launch-template-custom-ami), users will need to supply the necessary user data to bootstrap and register nodes with the cluster when launched. There are two routes to facilitate this bootstrapping process:
|
||||
- If the AMI used is a derivative of the [AWS EKS Optimized AMI ](https://github.com/awslabs/amazon-eks-ami), users can opt in to using a template provided by the module that provides the minimum necessary configuration to bootstrap the node when launched:
|
||||
|
||||
Reference in New Issue
Block a user