diff --git a/UPGRADE-20.0/index.html b/UPGRADE-20.0/index.html index 6432f3da..5dc41bdf 100644 --- a/UPGRADE-20.0/index.html +++ b/UPGRADE-20.0/index.html @@ -14,7 +14,7 @@ - + diff --git a/UPGRADE-21.0/index.html b/UPGRADE-21.0/index.html new file mode 100644 index 00000000..39b830f8 --- /dev/null +++ b/UPGRADE-21.0/index.html @@ -0,0 +1,880 @@ + + + + + + + + + + + + + + + + + + + + + + + + + Upgrade from v20.x to v21.x - Terraform AWS EKS + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + + + + + +
+ + + + +
+ +
+ + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+
+ + + + + + + +

Upgrade from v20.x to v21.x

+

If you have any questions regarding this upgrade process, please consult the examples directory: +If you find a bug, please open an issue with supporting configuration to reproduce.

+

List of backwards incompatible changes

+
    +
  • Terraform v1.5.7 is now minimum supported version
    • +
  • AWS provider v6.0.0 is now minimum supported version
    • +
  • TLS provider v4.0.0 is now minimum supported version
    • +
  • The aws-auth sub-module has been removed. Users who wish to utilize its functionality can continue to do so by specifying a v20.x version, or ~> v20.0 version constraint in their module source.
    • +
  • bootstrap_self_managed_addons is now hardcoded to false. This is a legacy setting and instead users should utilize the EKS addons API, which is what this module does by default. In conjunction with this change, the bootstrap_self_managed_addons is now ignored by the module to aid in upgrading without disruption (otherwise it would require cluster re-creation).
    • +
  • When enabling enable_efa_support or creating placement groups within a node group, users must now specify the correct subnet_ids; the module no longer tries to automatically select a suitable subnet.
    • +
  • EKS managed node group:
      +
    • IMDS now default to a hop limit of 1 (previously was 2)
      • +
    • ami_type now defaults to AL2023_x86_64_STANDARD
      • +
    • enable_monitoring is now set to false by default
      • +
    • enable_efa_only is now set to true by default
      • +
    • use_latest_ami_release_version is now set to true by default
      • +
    • Support for autoscaling group schedules has been removed
      • +
    +
    • +
  • Self-managed node group:
      +
    • IMDS now default to a hop limit of 1 (previously was 2)
      • +
    • ami_type now defaults to AL2023_x86_64_STANDARD
      • +
    • enable_monitoring is now set to false by default
      • +
    • enable_efa_only is now set to true by default
      • +
    • Support for autoscaling group schedules has been removed
      • +
    +
    • +
  • Karpenter:
      +
    • Native support for IAM roles for service accounts (IRSA) has been removed; EKS Pod Identity is now enabled by default
      • +
    • Karpenter controller policy for prior to Karpenter v1 have been removed (i.e. v0.33); the v1 policy is now used by default
      • +
    • create_pod_identity_association is now set to true by default
      • +
    +
    • +
  • addons.resolve_conflicts_on_create is now set to "NONE" by default (was "OVERWRITE").
    • +
  • addons.most_recent is now set to true by default (was false).
    • +
  • cluster_identity_providers.issuer_url is now required to be set by users; the prior incorrect default has been removed. See https://github.com/terraform-aws-modules/terraform-aws-eks/pull/3055 and https://github.com/kubernetes/kubernetes/pull/123561 for more details.
    • +
  • The OIDC issuer URL for IAM roles for service accounts (IRSA) has been changed to use the new dual stackoidc-eks endpoint instead of oidc.eks. This is to align with https://github.com/aws/containers-roadmap/issues/2038#issuecomment-2278450601
    • +
+

Additional changes

+

Added

+
    +
  • Support for region parameter to specify the AWS region for the resources created if different from the provider region.
    • +
  • Both the EKS managed and self-managed node groups now support creating their own security groups (again). This is primarily motivated by the changes for EFA support; previously users would need to specify enable_efa_support both at the cluster level (to add the appropriate security group rules to the shared node security group) as well as the node group level. However, its not always desirable to have these rules across ALL node groups when they are really only required on the node group where EFA is utilized. And similarly for other use cases, users can create custom rules for a specific node group instead of apply across ALL node groups.
    • +
+

Modified

+
    +
  • Variable definitions now contain detailed object types in place of the previously used any type.
    • +
  • The embedded KMS key module definition has been updated to v4.0 to support the same version requirements as well as the new region argument.
    • +
+

Variable and output changes

+
    +
  1. +

    Removed variables:

    +
      +
    • enable_efa_support - users only need to set this within the node group configuration, as the module no longer manages EFA support at the cluster level.
      • +
    • enable_security_groups_for_pods - users can instead attach the arn:aws:iam::aws:policy/AmazonEKSVPCResourceController policy via iam_role_additional_policies if using security groups for pods.
      • +
    • eks-managed-node-group sub-module
        +
      • cluster_service_ipv4_cidr - users should use cluster_service_cidr instead (for either IPv4 or IPv6).
        • +
      • elastic_gpu_specifications
        • +
      • elastic_inference_accelerator
        • +
      • platform - this is superseded by ami_type
        • +
      • placement_group_strategy - set to cluster by the module
        • +
      • placement_group_az - users will need to specify the correct subnet in subnet_ids
        • +
      • create_schedule
        • +
      • schedules
        • +
      +
      • +
    • self-managed-node-group sub-module
        +
      • elastic_gpu_specifications
        • +
      • elastic_inference_accelerator
        • +
      • platform - this is superseded by ami_type
        • +
      • create_schedule
        • +
      • schedules
        • +
      • placement_group_az - users will need to specify the correct subnet in subnet_ids
        • +
      • hibernation_options - not valid in EKS
        • +
      • min_elb_capacity - not valid in EKS
        • +
      • wait_for_elb_capacity - not valid in EKS
        • +
      • wait_for_capacity_timeout - not valid in EKS
        • +
      • default_cooldown - not valid in EKS
        • +
      • target_group_arns - not valid in EKS
        • +
      • service_linked_role_arn - not valid in EKS
        • +
      • warm_pool - not valid in EKS
        • +
      +
      • +
    • fargate-profile sub-module
        +
      • None
        • +
      +
      • +
    • karpenter sub-module
        +
      • enable_v1_permissions - v1 permissions are now the default
        • +
      • enable_irsa
        • +
      • irsa_oidc_provider_arn
        • +
      • irsa_namespace_service_accounts
        • +
      • irsa_assume_role_condition_test
        • +
      +
      • +
    +
    2. +
  2. +

    Renamed variables:

    +
      +
    • Variables prefixed with cluster_* have been stripped of the prefix to better match the underlying API:
        +
      • cluster_name -> name
        • +
      • cluster_version -> kubernetes_version
        • +
      • cluster_enabled_log_types -> enabled_log_types
        • +
      • cluster_force_update_version -> force_update_version
        • +
      • cluster_compute_config -> compute_config
        • +
      • cluster_upgrade_policy -> upgrade_policy
        • +
      • cluster_remote_network_config -> remote_network_config
        • +
      • cluster_zonal_shift_config -> zonal_shift_config
        • +
      • cluster_additional_security_group_ids -> additional_security_group_ids
        • +
      • cluster_endpoint_private_access -> endpoint_private_access
        • +
      • cluster_endpoint_public_access -> endpoint_public_access
        • +
      • cluster_endpoint_public_access_cidrs -> endpoint_public_access_cidrs
        • +
      • cluster_ip_family -> ip_family
        • +
      • cluster_service_ipv4_cidr -> service_ipv4_cidr
        • +
      • cluster_service_ipv6_cidr -> service_ipv6_cidr
        • +
      • cluster_encryption_config -> encryption_config
        • +
      • create_cluster_primary_security_group_tags -> create_primary_security_group_tags
        • +
      • cluster_timeouts -> timeouts
        • +
      • create_cluster_security_group -> create_security_group
        • +
      • cluster_security_group_id -> security_group_id
        • +
      • cluster_security_group_name -> security_group_name
        • +
      • cluster_security_group_use_name_prefix -> security_group_use_name_prefix
        • +
      • cluster_security_group_description -> security_group_description
        • +
      • cluster_security_group_additional_rules -> security_group_additional_rules
        • +
      • cluster_security_group_tags -> security_group_tags
        • +
      • cluster_encryption_policy_use_name_prefix -> encryption_policy_use_name_prefix
        • +
      • cluster_encryption_policy_name -> encryption_policy_name
        • +
      • cluster_encryption_policy_description -> encryption_policy_description
        • +
      • cluster_encryption_policy_path -> encryption_policy_path
        • +
      • cluster_encryption_policy_tags -> encryption_policy_tags
        • +
      • cluster_addons -> addons
        • +
      • cluster_addons_timeouts -> addons_timeouts
        • +
      • cluster_identity_providers -> identity_providers
        • +
      +
      • +
    • eks-managed-node-group sub-module
        +
      • cluster_version -> kubernetes_version
        • +
      +
      • +
    • self-managed-node-group sub-module
        +
      • cluster_version -> kubernetes_version
        • +
      • delete_timeout -> timeouts
        • +
      +
      • +
    • fargate-profile sub-module
        +
      • None
        • +
      +
      • +
    • karpenter sub-module
        +
      • None
        • +
      +
      • +
    +
    3. +
  3. +

    Added variables:

    +
      +
    • region
      • +
    • eks-managed-node-group sub-module
        +
      • region
        • +
      • partition - added to reduce number of GET requests from data sources when possible
        • +
      • account_id - added to reduce number of GET requests from data sources when possible
        • +
      • create_security_group
        • +
      • security_group_name
        • +
      • security_group_use_name_prefix
        • +
      • security_group_description
        • +
      • security_group_ingress_rules
        • +
      • security_group_egress_rules
        • +
      • security_group_tags
        • +
      +
      • +
    • self-managed-node-group sub-module
        +
      • region
        • +
      • partition - added to reduce number of GET requests from data sources when possible
        • +
      • account_id - added to reduce number of GET requests from data sources when possible
        • +
      • create_security_group
        • +
      • security_group_name
        • +
      • security_group_use_name_prefix
        • +
      • security_group_description
        • +
      • security_group_ingress_rules
        • +
      • security_group_egress_rules
        • +
      • security_group_tags
        • +
      +
      • +
    • fargate-profile sub-module
        +
      • region
        • +
      • partition - added to reduce number of GET requests from data sources when possible
        • +
      • account_id - added to reduce number of GET requests from data sources when possible
        • +
      +
      • +
    • karpenter sub-module
        +
      • region
        • +
      +
      • +
    +
    4. +
  4. +

    Removed outputs:

    +
      +
    • eks-managed-node-group sub-module
        +
      • platform - this is superseded by ami_type
        • +
      • autoscaling_group_schedule_arns
        • +
      +
      • +
    • self-managed-node-group sub-module
        +
      • platform - this is superseded by ami_type
        • +
      • autoscaling_group_schedule_arns
        • +
      +
      • +
    • fargate-profile sub-module
        +
      • None
        • +
      +
      • +
    • karpenter sub-module
        +
      • None
        • +
      +
      • +
    +
    5. +
  5. +

    Renamed outputs:

    +
      +
    • eks-managed-node-group sub-module
        +
      • None
        • +
      +
      • +
    • self-managed-node-group sub-module
        +
      • None
        • +
      +
      • +
    • fargate-profile sub-module
        +
      • None
        • +
      +
      • +
    • karpenter sub-module
        +
      • None
        • +
      +
      • +
    +
    6. +
  6. +

    Added outputs:

    +
      +
    • eks-managed-node-group sub-module
        +
      • security_group_arn
        • +
      • security_group_id
        • +
      +
      • +
    • self-managed-node-group sub-module
        +
      • security_group_arn
        • +
      • security_group_id
        • +
      +
      • +
    • fargate-profile sub-module
        +
      • None
        • +
      +
      • +
    • karpenter sub-module
        +
      • None
        • +
      +
      • +
    +
    7. +
+

Upgrade Migrations

+

Before 20.x Example

+
module "eks" {
+  source  = "terraform-aws-modules/eks/aws"
+  version = "~> 20.0"
+
+  # Truncated for brevity ...
+  # Renamed variables are not shown here, please refer to the full list above.
+
+  enable_efa_support = true
+
+  eks_managed_node_group_defaults = {
+    iam_role_additional_policies = {
+      AmazonSSMManagedInstanceCore = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
+    }
+  }
+
+  eks_managed_node_groups = {
+    efa = {
+      ami_type       = "AL2023_x86_64_NVIDIA"
+      instance_types = ["p5e.48xlarge"]
+
+      enable_efa_support = true
+      enable_efa_only    = true
+    }
+  }
+
+  self_managed_node_groups = {
+    example = {
+      use_mixed_instances_policy = true
+      mixed_instances_policy = {
+        instances_distribution = {
+          on_demand_base_capacity                  = 0
+          on_demand_percentage_above_base_capacity = 0
+          on_demand_allocation_strategy            = "lowest-price"
+          spot_allocation_strategy                 = "price-capacity-optimized"
+        }
+
+        # ASG configuration
+        override = [
+          {
+            instance_requirements = {
+              cpu_manufacturers                           = ["intel"]
+              instance_generations                        = ["current", "previous"]
+              spot_max_price_percentage_over_lowest_price = 100
+
+              vcpu_count = {
+                min = 1
+              }
+
+              allowed_instance_types = ["t*", "m*"]
+            }
+          }
+        ]
+      }
+    }
+  }
+}
+
+

After 21.x Example

+
module "eks" {
+  source  = "terraform-aws-modules/eks/aws"
+  version = "~> 21.0"
+
+  # Truncated for brevity ...
+  # Renamed variables are not shown here, please refer to the full list above.
+
+  eks_managed_node_groups = {
+    efa = {
+      ami_type       = "AL2023_x86_64_NVIDIA"
+      instance_types = ["p5e.48xlarge"]
+
+      iam_role_additional_policies = {
+        AmazonSSMManagedInstanceCore = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
+      }
+
+      enable_efa_support = true
+
+      subnet_ids = element(module.vpc.private_subnets, 0)
+    }
+  }
+
+  self_managed_node_groups = {
+    example = {
+      use_mixed_instances_policy = true
+      mixed_instances_policy = {
+        instances_distribution = {
+          on_demand_base_capacity                  = 0
+          on_demand_percentage_above_base_capacity = 0
+          on_demand_allocation_strategy            = "lowest-price"
+          spot_allocation_strategy                 = "price-capacity-optimized"
+        }
+
+        # ASG configuration
+        # Need to wrap in `launch_template` now
+        launch_template = {
+          override = [
+            {
+              instance_requirements = {
+                cpu_manufacturers                           = ["intel"]
+                instance_generations                        = ["current", "previous"]
+                spot_max_price_percentage_over_lowest_price = 100
+
+                vcpu_count = {
+                  min = 1
+                }
+
+                allowed_instance_types = ["t*", "m*"]
+              }
+            }
+          ]
+        }
+      }
+    }
+  }
+}
+
+

State Changes

+

No state changes required.

+ + + + + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + + \ No newline at end of file diff --git a/compute_resources/index.html b/compute_resources/index.html index 6dbf6416..9ece9601 100644 --- a/compute_resources/index.html +++ b/compute_resources/index.html @@ -11,7 +11,7 @@ - + @@ -362,15 +362,6 @@ - - -
  • - - - Default Configurations - - -
    • @@ -447,24 +438,36 @@ 
      eks_managed_node_groups = {
     custom_ami = {
-      ami_id = "ami-0caf35bc73450c396"
-
-      # 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
-
-      pre_bootstrap_user_data = <<-EOT
-        export FOO=bar
-      EOT
-
-      # Because we have full control over the user data supplied, we can also run additional
-      # scripts/configuration changes after the bootstrap script has been run
-      post_bootstrap_user_data = <<-EOT
-        echo "you are free little kubelet!"
-      EOT
-    }
-  }
+      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\""
+      }]
+    }
+  }
    1. There is similar support for Bottlerocket OS:
      2. @@ -499,9 +502,9 @@
      1. The self-managed-node-group uses the latest AWS EKS Optimized AMI (Linux) for the given Kubernetes version by default:
      -
        cluster_version = "1.33"
+
        kubernetes_version = "1.33"
 
-  # This self managed node group will use the latest AWS EKS Optimized AMI for Kubernetes 1.27
+  # This self managed node group will use the latest AWS EKS Optimized AMI for Kubernetes 1.33
   self_managed_node_groups = {
     default = {}
   }
@@ -509,7 +512,7 @@
 
        
 
      1. To use Bottlerocket, specify the ami_type as one of the respective "BOTTLEROCKET_*" types and supply a Bottlerocket OS AMI:
        2. 
 
      
-
        cluster_version = "1.33"
+
        kubernetes_version = "1.33"
 
   self_managed_node_groups = {
     bottlerocket = {
@@ -521,43 +524,6 @@
 
      See the examples/self-managed-node-group/ example for a working example of various configurations.
      
 
      Fargate Profiles
      
 
      Fargate profiles are straightforward to use and therefore no further details are provided here. See the tests/fargate-profile/ tests for a working example of various configurations.
      
-
      Default Configurations
      
-
      Each type of compute resource (EKS managed node group, self managed node group, or Fargate profile) provides the option for users to specify a default configuration. These default configurations can be overridden from within the compute resource's individual definition. The order of precedence for configurations (from highest to least precedence):
      
-
        
-
      • Compute resource individual configuration
        • 
-
      • Compute resource family default configuration (eks_managed_node_group_defaults, self_managed_node_group_defaults, fargate_profile_defaults)
          
-
        • Module default configuration (see variables.tf and node_groups.tf)
          • 
-
        
-
        • 
-
      
-
      For example, the following creates 4 AWS EKS Managed Node Groups:
      
-
        eks_managed_node_group_defaults = {
-    ami_type               = "AL2_x86_64"
-    disk_size              = 50
-    instance_types         = ["m6i.large", "m5.large", "m5n.large", "m5zn.large"]
-  }
-
-  eks_managed_node_groups = {
-    # Uses module default configurations overridden by configuration above
-    default = {}
-
-    # This further overrides the instance types used
-    compute = {
-      instance_types = ["c5.large", "c6i.large", "c6d.large"]
-    }
-
-    # This further overrides the instance types and disk size used
-    persistent = {
-      disk_size = 1024
-      instance_types = ["r5.xlarge", "r6i.xlarge", "r5b.xlarge"]
-    }
-
-    # This overrides the OS used
-    bottlerocket = {
-      ami_type = "BOTTLEROCKET_x86_64"
-    }
-  }
-
      
 
 
 
diff --git a/faq/index.html b/faq/index.html
index aa771ed2..4cba6438 100644
--- a/faq/index.html
+++ b/faq/index.html
@@ -337,9 +337,9 @@
 
       
         
    2. 
-  
+  
     
-      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> ...
     
   
   
@@ -420,19 +420,40 @@
 
 
      Setting disk_size or remote_access does not make any changes
      
 
      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:
        2. 
 
      
-
        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
+    }
+  }
 
      
 
        
 
      1. 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.
        2. 
 
      
-
        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.
      
 
      If you choose to use Custom Networking, make sure to only attach the security groups matching your choice above in your ENIConfig resources. This will ensure you avoid redundant tags.
      
@@ -462,6 +483,7 @@

    Why are there no changes when a node group's desired_size is modified?

    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 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" { ... }:

     @@ -408,27 +409,40 @@

  • Users can use the following variables to facilitate this process:

    +

    For AL2_*, BOTTLEROCKET_*, and WINDOWS_*: 

    pre_bootstrap_user_data = "..."
-
    +

    +

    For AL2023_* +

    cloudinit_pre_nodeadm = [{
+  content      = <<-EOT
+    ---
+    apiVersion: node.eks.aws/v1alpha1
+    kind: NodeConfig
+    spec:
+      ...
+  EOT
+  content_type = "application/node.eks.aws"
+}]
+

  • If a custom AMI is used, then per the AWS documentation, 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 , users can opt in to using a template provided by the module that provides the minimum necessary configuration to bootstrap the node when launched:
  • If the AMI is NOT an AWS EKS Optimized AMI derivative, or if users wish to have more control over the user data that is supplied to the node when launched, users have the ability to supply their own user data template that will be rendered instead of the module supplied template. Note - only the variables that are supplied to the templatefile() for the respective AMI type are available for use in the supplied template, otherwise users will need to pre-render/pre-populate the template before supplying the final template to the module for rendering as user data.
    • Users can use the following variables to facilitate this process: - 
      user_data_template_path  = "./your/user_data.sh" # user supplied bootstrap user data template
-pre_bootstrap_user_data  = "..."
-bootstrap_extra_args     = "..."
-post_bootstrap_user_data = "..."
+   
      user_data_template_path  = "./your/user_data.sh" # user supplied bootstrap user data template
+pre_bootstrap_user_data  = "..."
+bootstrap_extra_args     = "..."
+post_bootstrap_user_data = "..."
    • @@ -450,17 +464,17 @@
    • If the AMI used is a derivative of the AWS EKS Optimized 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:
    • Users can use the following variables to facilitate this process: - 
      enable_bootstrap_user_data = true # to opt in to using the module supplied bootstrap user data template
-pre_bootstrap_user_data    = "..."
-bootstrap_extra_args       = "..."
-post_bootstrap_user_data   = "..."
+    
      enable_bootstrap_user_data = true # to opt in to using the module supplied bootstrap user data template
+pre_bootstrap_user_data    = "..."
+bootstrap_extra_args       = "..."
+post_bootstrap_user_data   = "..."
    • If the AMI is NOT an AWS EKS Optimized AMI derivative, or if users wish to have more control over the user data that is supplied to the node when launched, users have the ability to supply their own user data template that will be rendered instead of the module supplied template. Note - only the variables that are supplied to the templatefile() for the respective AMI type are available for use in the supplied template, otherwise users will need to pre-render/pre-populate the template before supplying the final template to the module for rendering as user data.
      • Users can use the following variables to facilitate this process: - 
        user_data_template_path  = "./your/user_data.sh" # user supplied bootstrap user data template
-pre_bootstrap_user_data  = "..."
-bootstrap_extra_args     = "..."
-post_bootstrap_user_data = "..."
+  
        user_data_template_path  = "./your/user_data.sh" # user supplied bootstrap user data template
+pre_bootstrap_user_data  = "..."
+bootstrap_extra_args     = "..."
+post_bootstrap_user_data = "..."