Terraform-aws-eks: How to specify image id or ami id in the worker launch template?

Created on 20 Feb 2020  路  7Comments  路  Source: terraform-aws-modules/terraform-aws-eks

I have issues

I'm submitting a...

  • [ ] bug report
  • [ ] feature request
  • [x] support request - read the FAQ first!
  • [ ] kudos, thank you, warm fuzzy

What is the current behavior?

If this is a bug, how to reproduce? Please include a code sample if relevant.

What's the expected behavior?

Are you able to fix this problem and submit a PR? Link here if you have already.

Environment details

  • Affected module version:
  • OS:
  • Terraform version:

Any other relevant info

Most helpful comment

That's a little bit of a downside when you have different worker types on the same cluster (ARM or GPUs)

You can define your own ami datasource, your own filter and pass the AMI ID to your worker groups.

data "aws_ami" "my_worker_ami" { 
  filter { 
    name = "name" 
    values = ["your-filter"] 
  } 
  most_recent = true 
  owners = ["your-owner-alias-or-id]
}

# In your module call
module "eks" {
  worker_groups = [{
    ami_id = data.aws_ami.my_worker_ami.id
  }]
}

You can now define a different AMI by worker group or even configure the module for GPU AMI by default and provide AMI ID for ARM worker groups.

All 7 comments

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I have the following launch template for a graviton asg:
You can of course modified you kubelet args with your own needs.

{
  name                    = "worker-spot-g"
  override_instance_types = ["m6g.4xlarge"]
  spot_instance_pools     = 4
  asg_max_size            = 20
  asg_desired_capacity    = 1
  kubelet_extra_args      = "--node-labels=nodes=shared,authentication-token-webhook=true,authorization-mode=Webhook --register-with-taints=node.kubernetes.io/worker=true:NoSchedule,node.kubernetes.io/lifecycle=spot"
  ami_id                  = "ami-0ec3e069e3dc4757b"
  public_ip               = false
  tags = [
    {
      "key"                 = "k8s.io/cluster-autoscaler/enabled"
      "propagate_at_launch" = "false"
      "value"               = "true"
    },
    {
      "key"                 = "k8s.io/cluster-autoscaler/${local.cluster_name}"
      "propagate_at_launch" = "false"
      "value"               = "true"
    }
  ]
},

Can you specify the graviton ami with worker_ami_name_filter instead?

I figured this out. You can use:

 worker_ami_name_filter="amazon-eks-arm64-node-${var.cluster_version}-v*"

The benefit of this method over @garvizmx's approach is that it will always use the most up-to-date ami for your eks version. However, this will set __all__ of your worker nodes to use this ami.

That's a little bit of a downside when you have different worker types on the same cluster (ARM or GPUs)

That's a little bit of a downside when you have different worker types on the same cluster (ARM or GPUs)

You can define your own ami datasource, your own filter and pass the AMI ID to your worker groups.

data "aws_ami" "my_worker_ami" { 
  filter { 
    name = "name" 
    values = ["your-filter"] 
  } 
  most_recent = true 
  owners = ["your-owner-alias-or-id]
}

# In your module call
module "eks" {
  worker_groups = [{
    ami_id = data.aws_ami.my_worker_ami.id
  }]
}

You can now define a different AMI by worker group or even configure the module for GPU AMI by default and provide AMI ID for ARM worker groups.

Was this page helpful?
0 / 5 - 0 ratings