The Next Evolution: Moving to Karpenter for Smarter Scaling
Coinbase's continued growth exposed the limitations of its architecture built on Cluster Autoscaler and Managed Node Groups, necessitating a long-term infrastructure solution. A key pain point was the process of updating node groups, which often resulted in slow, disruptive cycles. With a frustrating 15-minute timeout and a single attempt to complete an upgrade, the old system proved to be inflexible and unreliable. Additionally, managing a variety of instance types became a cumbersome task, requiring a separate node group for each type. This complex and inefficient setup no longer met the company’s demands for speed and scalability.
In search of a more dynamic and efficient solution, Coinbase transitioned to Karpenter. This move allowed us to leverage a more Kubernetes-native approach to node management. Karpenter operates as a controller, continuously watching for unscheduleable pods and provisioning new nodes in real-time. This dynamic, just-in-time provisioning eliminates the need for predefined node groups and the associated management overhead. This streamlined operations and delivered an impressive 20% reduction in infrastructure costs. By embracing Karpenter, we achieved a more agile, cost-effective, and scalable foundation to support Coinbase’s continued growth.
IP address management is a subtle but critical challenge with Karpenter. While it's great at provisioning resources "just-in-time", it doesn't always have full visibility into a subnet's IP availability. This can lead to IP exhaustion, where a subnet runs out of addresses, causing newly provisioned nodes to become "unready" and pods to get stuck in a pending state. The issue often arises because Karpenter's logic for selecting a subnet might not align with IP availability. It could favor a particular Availability Zone (AZ) that has limited remaining IPs, leading to an unbalanced distribution of nodes. This is especially problematic for highly dynamic workloads with frequent scaling events. To address this long-term, we are actively working on enabling dual-stack EKS clusters to utilize IPv6, mitigating the risk of IPv4 exhaustion.