Karpenter Replica Issue on Kubernetes

[dextercrypt]

Description

Observed Behavior:
Karpenter helm Chart deploys by default 2 replica of Karpenter.

Both should run fine if its a default value.

Expected Behavior:

One of the Replica always says this issue:

{"level":"INFO","time":"2024-10-01T20:25:27.649Z","logger":"controller","message":"attempting to acquire leader lease kube-system/karpenter-leader-election...","commit":"62a726c"}

While another one works and does it work? Can we just run 1 pod then?

Reproduction Steps (Please include YAML):

Versions:

• Chart Version: Latest (On documentation)
• Kubernetes Version (kubectl version): 1.28 EKS

• 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

[jmdeal]

By it's nature Karpenter doesn't horizontally scale (hence the leader election), but multiple replicas help ensure high availability. For example, there could be an AZ outage but since the replicas are in different AZs, the unaffected replica will be able to take over and continue operating. You're free to reduce the replica count, Karpenter will still function, but we recommend running multiple replicas spread across AZs.

[github-actions]

This issue has been inactive for 14 days. StaleBot will close this stale issue after 14 more days of inactivity.