I'm planning to deploy Karpenter on an EKS cluster and want to validate the architecture before moving ahead. The cluster is currently managed with an app-of-apps setup in ArgoCD, and all workloads run in a Managed Node Group.
My proposed design is to reduce the Managed Node Group to a small static group, run the Karpenter controller there alongside ArgoCD and other essential cluster components, and use Karpenter to provision capacity for regular workloads. Karpenter itself would be installed and managed through ArgoCD during the cluster bootstrap process.
Is this a sound design, or are there best practices or changes I should consider? In particular, I'm interested in avoiding bootstrap dependencies, handling disruption and consolidation safely, and deciding which system components should remain on static capacity.
3 Answers
The overall architecture is reasonable: keep a small, stable node group for Karpenter, ArgoCD, and only the cluster components needed for recovery and bootstrap. Karpenter should not depend on capacity that it manages, otherwise you can run into a circular dependency during startup or node replacement.
Managing the Karpenter installation with ArgoCD is fine, as long as ArgoCD and Karpenter have somewhere stable to run before dynamic capacity is available. I would avoid placing every system workload on the static group, though. Keep ordinary workloads off it with taints and tolerations, so the group remains small and predictable.
Make the static capacity highly available enough to survive a node failure—for example, multiple small nodes across availability zones rather than one bootstrap node. Then put most of the design effort into the NodePool and EC2NodeClass settings: instance flexibility, availability zones, Spot versus On-Demand capacity, disruption and consolidation policies, resource limits, and workload requests and topology rules.
Be careful with consolidation and ArgoCD synchronization. If the static node group can be disrupted or if ArgoCD components are allowed to run on replaceable capacity, consolidation may evict something during a sync. Taint the static group so only bootstrap and critical components land there, and use appropriate PodDisruptionBudgets—especially for the ArgoCD repository server and other components that need continuity.
The key distinction is that Karpenter is a controller, not something that needs ArgoCD in order to function. ArgoCD can install and reconcile its Kubernetes resources, but Karpenter still needs stable compute and the required AWS permissions independently. Treat ArgoCD as the deployment mechanism, not as a runtime dependency for Karpenter.
It may also be worth considering Fargate for a few cluster-critical controllers if that fits your environment. That removes their dependence on managed or Karpenter-provisioned nodes, although it comes with its own limitations and cost trade-offs.