New amiSelectorTerm alias for latest~1

[calvinbui]

Description

What problem are you trying to solve?

I want our staging environment to use the latest ami and our production environment to use n-1

• staging: - alias: al2023@latest
• production: - alias: al2023@latest~1

This requires less manual work to find the specific AMI versions and having to manually pin/update Karpenter each time. This includes when they can lag behind in each region and when we there are multiple arch as well.

How important is this feature to you?

We have been recommended by our AWS TAM team to implement this strategy for our environments.

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[stevehipwell]

I have a similar requirement but I don't think that n-1 is a workable solution. Firstly even with a 7 day regular release cycle, which none of AL2, AL2023 or Bottlerocket actually follow, this is a significant lag to get updates which are likely already lagged in the first place. Secondly how do we know that n-1 is actually a "good" release; n could have been released to replace a "bad" n-1 without n-1 having been delisted.

I'd like to see support for marking an AMI as stable either in the context of AWS/EKS or Karpenter and then being able to use a - alias: al2023@stable selector. The stable concept could have some constraints, such as min release age etc, and there should be an expectation that in the case of a "bad" stable version that this would be rolled back to the previous "good" stable version.

As a less integrated option Karpenter could support managing dynamic AMI selection from a user defined SSM (or equivalent) source.

[aelliottatsonatype]

I would love to see this implemented and have a stable tag I could use.

[erulabs]

Not related to the stable tag, but because of an issue in the latest AL2023 release, and because a lack of documentation around selecting versions by alias, I have been using:

  amiSelectorTerms:
    - alias: al2023@v20241031

to back off the most recent version.

+1 for a stable tag the lags behind!

[Jerome-w6n]

Hello,

I was going to create a new issue about our use case, but I think this one is close.

We don't want the latest AMI to be directly deployed to production environments, but we also don't want to manually modify all EC2Nodeclass resources every time the AMI is changed. We have about sixty EKS test/staging/production clusters to manage.

Therefore, we currently use the following mechanism:

• amiTermSelector is configured with a list of tags (as described in https://karpenter.sh/docs/tasks/managing-amis/#controlling-ami-replacement)
• a script regularly checks for a new AMI for the current version of the EKS control plane (and AMI Family) and adds tags if necessary.

The tag update script has the following constraint: the new AMI must have been published for more than X days. In test environments, this value is 0, in staging environments, it's 3, and in production, it's 8.

The idea of ​​an alias "@stable" is interesting, but it's more opaque and doesn't allow for differentiation across the three environments.

So, could the idea of ​​having an alias that selects the most recent AMI, but one that was published more than X days ago, fit into this issue?
Something like this:

• alias: al2023@olderthan~0
• alias: al2023@olderthan~3
• alias: al2023@olderthan~8

[kevarr]

I like this idea, but wouldn't you want your n-1 clusters to be on version n when AWS releases a critical Security Patch?

It would be great if AWS / Karpenter had release channels for 'latest' and 'stable' for edge and more vetted releases.

[jmdeal]

I'm going to close this issue and covert it to a discussion for the same reason I laid out here. You can find our documentation on best practices for managing AMIs in production environments in our docs: https://karpenter.sh/docs/tasks/managing-amis/.