Skip to main content
← Back to index page

1.250.0

Add EKS addons and the required IRSA to the `eks` component

What​

  • Deprecate the eks-iam component
  • Add EKS addons and the required IRSA for the addons to the eks component
  • Add ability to specify configuration values and timeouts for addons
  • Add ability to deploy addons to Fargate when necessary
  • Add ability to omit specifying Availability Zones and infer them from private subnets
  • Add recommended but optional and requiring opt-in: use a single Fargate Pod Execution Role for all Fargate Profiles

Why​

  • The eks-iam component is not in use (we now create the IAM roles for Kubernetes Service Accounts in the https://github.com/cloudposse/terraform-aws-helm-release module), and has very old and outdated code

  • AWS recommends to provision the required EKS addons and not to rely on the managed addons (some of which are automatically provisioned by EKS on a cluster)

  • Some EKS addons (e.g. vpc-cni and aws-ebs-csi-driver) require an IAM Role for Kubernetes Service Account (IRSA) with specific permissions. Since these addons are critical for cluster functionality, we create the IRSA roles for the addons in the eks component and provide the role ARNs to the addons

  • Some EKS addons can be configured. In particular, coredns requires configuration to enable it to be deployed to Fargate.

  • Users relying on Karpenter to deploy all nodes and wanting to deploy coredns or aws-ebs-csi-driver addons need to deploy them to Fargate or else the EKS deployment will fail.

  • Enable DRY specification of Availability Zones, and use of AZ IDs, by reading the VPCs AZs.

  • A cluster needs only one Fargate Pod Execution Role, and it was a mistake to provision one for every profile. However, making the change would break existing clusters, so it is optional and requires opt-in.

References​

Commiters​

Pull Requests​