xpk/terraform-aws-eks
1
0
Fork 0
mirror of https://github.com/terraform-aws-modules/terraform-aws-eks.git synced 2025-09-09 19:32:58 +08:00
Code Activity

feat!: Upgrade min AWS provider and Terraform versions to 6.0 and 1.5.7 respectively (#3412)

Browse Source 
* 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:
Bryant Biggs
2025-07-23 15:11:01 -05:00
committed by GitHub
parent 8a0efdbbc8
commit 416515a0da
84 changed files with 4111 additions and 3339 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/faq.md
+33 -10
View File
@@ -12,23 +12,44 @@
`disk_size`, and `remote_access` can only be set when using the EKS managed node group default launch template. This module defaults to providing a custom launch template to allow for custom security groups, tag propagation, etc. If you wish to forgo the custom launch template route, you can set `use_custom_launch_template = false` and then you can set `disk_size` and `remote_access`.
### I received an error: `expect exactly one securityGroup tagged with kubernetes.io/cluster/<NAME> ...`
### I received an error: `expect exactly one securityGroup tagged with kubernetes.io/cluster/<CLUSTER_NAME> ...`
⚠️ `<CLUSTER_NAME>` would be the name of your cluster
By default, EKS creates a cluster primary security group that is created outside of the module and the EKS service adds the tag `{ "kubernetes.io/cluster/<CLUSTER_NAME>" = "owned" }`. This on its own does not cause any conflicts for addons such as the AWS Load Balancer Controller until users decide to attach both the cluster primary security group and the shared node security group created by the module (by setting `attach_cluster_primary_security_group = true`). The issue is not with having multiple security groups in your account with this tag key:value combination, but having multiple security groups with this tag key:value combination attached to nodes in the same cluster. There are a few ways to resolve this depending on your use case/intentions:
⚠️ `<CLUSTER_NAME>` below needs to be replaced with the name of your cluster
1. If you want to use the cluster primary security group, you can disable the creation of the shared node security group with:
```hcl
create_node_security_group = false # default is true
attach_cluster_primary_security_group = true # default is false
create_node_security_group = false # default is true
eks_managed_node_group = {
example = {
attach_cluster_primary_security_group = true # default is false
}
}
# Or for self-managed
self_managed_node_group = {
example = {
attach_cluster_primary_security_group = true # default is false
}
}
```
2. By not attaching the cluster primary security group. The cluster primary security group has quite broad access and the module has instead provided a security group with the minimum amount of access to launch an empty EKS cluster successfully and users are encouraged to open up access when necessary to support their workload.
```hcl
attach_cluster_primary_security_group = false # this is the default for the module
eks_managed_node_group = {
example = {
attach_cluster_primary_security_group = true # default is false
}
}
# Or for self-managed
self_managed_node_group = {
example = {
attach_cluster_primary_security_group = true # default is false
}
}
```
In theory, if you are attaching the cluster primary security group, you shouldn't need to use the shared node security group created by the module. However, this is left up to users to decide for their requirements and use case.
@@ -58,6 +79,8 @@ If you require a public endpoint, setting up both (public and private) and restr
The module is configured to ignore this value. Unfortunately, Terraform does not support variables within the `lifecycle` block. The setting is ignored to allow autoscaling via controllers such as cluster autoscaler or Karpenter to work properly and without interference by Terraform. Changing the desired count must be handled outside of Terraform once the node group is created.
:info: See [this](https://github.com/bryantbiggs/eks-desired-size-hack) for a workaround to this limitation.
### How do I access compute resource attributes?
Examples of accessing the attributes of the compute resource(s) created by the root module are shown below. Note - the assumption is that your cluster module definition is named `eks` as in `module "eks" { ... }`:
@@ -90,6 +113,10 @@ aws eks describe-addon-versions --query 'addons[*].addonName'
### What configuration values are available for an add-on?
> [!NOTE]
> The available configuration values will vary between add-on versions,
> typically more configuration values will be added in later versions as functionality is enabled by EKS.
You can retrieve the configuration value schema for a given addon using the following command:
```sh
@@ -286,7 +313,3 @@ Returns (at the time of writing):
}
}
```
> [!NOTE]
> The available configuration values will vary between add-on versions,
> typically more configuration values will be added in later versions as functionality is enabled by EKS.