Description
What problem are you trying to solve?
If Karpenter isn't able to discover any AMI's for an alias after upgrading the K8s Control Plane, it should set an unhealthy condition on the EC2NodeClass resource.
After an upgrade to K8s v1.34, we started started seeing a getting amis, getting AMI queries, failed to discover any AMIs for alias errors. This error was correct as no AMI existed with the criteria for K8s v1.34 but all of the conditions in the EC2NodeClass remained healthy despite this config error.
I think that Karpenter not being able to discover an AMI should be reflected within the EC2NodeClass conditions, whether that's by an existing condition or a new one e.g. AMIsDiscoveryReady.
This behaviour has been seen in other issues, e.g. #8985
How important is this feature to you?
We use the health/conditions of applications in ArgoCD to determine whether our CICD pipelines should progress to the next environment. Being able to see this issue with the EC2NodeClass status.conditions field would help us find misconfigured resources and prevent a wider rollout to higher envs.
- 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
Description
What problem are you trying to solve?
If Karpenter isn't able to discover any AMI's for an alias after upgrading the K8s Control Plane, it should set an unhealthy condition on the
EC2NodeClassresource.After an upgrade to K8s v1.34, we started started seeing a
getting amis, getting AMI queries, failed to discover any AMIs for aliaserrors. This error was correct as no AMI existed with the criteria for K8s v1.34 but all of the conditions in theEC2NodeClassremained healthy despite this config error.I think that Karpenter not being able to discover an AMI should be reflected within the
EC2NodeClassconditions, whether that's by an existing condition or a new one e.g.AMIsDiscoveryReady.This behaviour has been seen in other issues, e.g. #8985
How important is this feature to you?
We use the health/conditions of applications in ArgoCD to determine whether our CICD pipelines should progress to the next environment. Being able to see this issue with the
EC2NodeClassstatus.conditions field would help us find misconfigured resources and prevent a wider rollout to higher envs.