Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cluster Autoscaler > Karpenter > Blueprints - Which is the best approach? #636

Open
brunobritodev opened this issue Jan 17, 2025 · 0 comments
Labels
correction Data is inaccurate

Comments

@brunobritodev
Copy link

Describe the Problem

tl;dr: There is a lack of clarity about which terraform module we should use.

In the EKS Best Practices > Cluster Autoscaler > Karpenter, under the section Karpenter Blueprints, a link is provided to karpenter-blueprints on GitHub. The repository's demo utilizes the aws-ia/eks-blueprints-addons/aws module, which currently does not support POD Identity Association. This limitation is tracked in an open issue.

On the other hand, the Karpenter.sh website recommends using the Amazon EKS Blueprints for Terraform, which redirects to the documentation for terraform-aws-eks-blueprints.

The docs provides two setup recommendations:

Both approaches utilize the terraform-aws-modules/eks/aws//modules/karpenter component.

A review of the motivations for migrating from v4 to v5 of terraform-aws-eks-blueprints reveals that the team plans to discontinue support for certain components. They now recommend transitioning to the terraform-aws-eks module for future-proofing.

Summary

  • EKS Best Practices: References a repository that uses EKS version 1.30 and a Karpenter module lacking POD Identity Association support.
  • Karpenter.sh: Points to a newer repository with a Karpenter module compatible with all the latest EKS features.

The primary issue is the lack of clarity about which module should be adopted, as both official documentations provide ambiguous guidance on this decision.

My Suggestion:
Actually following the recommendations from Karpenter.sh is the best approach. This ensures compatibility with the latest EKS features.

@brunobritodev brunobritodev added the correction Data is inaccurate label Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
correction Data is inaccurate
Projects
None yet
Development

No branches or pull requests

1 participant