Feature request: Infer AMI from current configuration or allow user to pass custom AMI

[bryantbiggs]

Use case

(Instead of trying to re-interpret the current logic, I'll defer to describing the intended logic)

--custom-ami-id argument should be added for users to pass a custom AMI ID.

When performing an upgrade of EKS and/or self-managed nodegroups, the process for determining the appropriate AMI should follow:

Self-managed nodegroup

If --custom-ami-id has been supplied with a value, simply proceed to grab each ASG and its LT and create a new LT version with the AMI ID provided. If --custom-ami-id has NOT been supplied:

1. Get the launch template of each self-managed autoscaling group (we are ignoring support for launch configuration since its EOL)
2. From the LTs, extract the AMI ID
3. Perform a describe call on the AMI to determine if this is an Amazon EKS optimized AMI, and of which variant (AL2, Bottlerocket, Windows variants) and arch (x86/arm64)
4. If this is NOT an Amazon EKS optimized AMI, and --custom-ami-id has not been supplied, halt progress and return details to user that a custom AMI ID is required when an Amazon EKS optimized AMI is not currently in use
5. If this is an Amazon EKS optimized AMI, retrieve the AMI ID of the next incremental Kubernetes version from the associated SSM parameter (get the AMI ID for the next version of K8s for the given AMI variant and arch)
6. Create a new LT version with the new AMI ID, update the ASG, etc. (roll out changes)

EKS managed nodegroup

Default launch template

1. No-op from an AMI perspective; once the nodegroup Kubneretes version has been updated, the managed nodegroup will pull the appropriate AMI and deploy

Custom launch template

1. Get the ASGs from each of the EKS managed nodegroups
2. If there is NOT an AMI ID specified on the nodegroup, then the AMIs used are the EKS optimized AMIs - update the nodegroup version to the next incremental Kubernetes version and roll out changes
3. If there is an AMI ID specified on the nodegroup, this is a custom AMI and the user should have provided a --custom-ami-id, otherwise abort and report (nice rhyme!)

Solution/User Experience

The logic used for determining an AMI ID should be consistent and reliable without assumptions

Alternative solutions

No response

[dan-hoeger]

wouldn't it be better to provide an AMI template string? also for my use case we need to specify a specific owner to search for that ami so something like --custom-ami-owner=xxxx --custom-ami-template="AmazonLinux2-EKS-{Ver}*" where {Ver} is the version you are trying to upgrade to. but this also assumes that the instances it finds that are custom are "AmazonLinux" instances what if you have AmazonLinux, Ubuntu and Windows images? how do you specify the templates and owners for each of those?

[bryantbiggs]

passing the AMI ID itself is the most direct way and is also the method that EKS managed nodegroups, or self-managed nodegroups, follow.

But I am curious to hear more about why passing the owner and a string template would be preferred? That looks like it could get quite tricky - what if multiple AMI IDs are matched and returned, which one to select?

[dan-hoeger]

aren't the AMI ID's specific to each region? we have multiple VPN's in multiple regions so we would have to lookup the ami ID value for each region and pass that as the parameter. plus with nodes that have Windows and Linux instances which AMI are you passing for this switch? I think we almost need a JSON object to specify the configuration for what we have in "latest_ami.py get_latest_ami method" if you look there it has "Amazon Linux 2", "Windows", "bottlerocket" and "ubuntu" so the custom ami's could potentially have entries for each of these that would have to be specified.

In the case that multiple AMi's are returned for the same search string I would think you just use the most current image.

[github-actions]

This issue has not received any attention in 30 days. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.