A previous series of blogs discussed K8s autoscaling. We discussed the Cluster autoscaler https://www.vamsitalkstech.com/kubernetes/kubernetes-cluster-autoscaling-a-refresher/. Karpenter is an open source project incubated at AWS. It is somewhat of a relook at cluster autoscaling for K8s, as it aims to eliminate a few pain points associated with cluster autoscaler – manual effort, rightsizing and over-provisioning resources.
Karpenter is designed to be agnostic to the cloud provider but currently supports AWS EKS (Elastic Kubernetes Service). As we discuss in this blog, Karpenter observes events within the Kubernetes cluster, and then sends provisioning commands to resources in the underlying cloud provider.
Karpenter is a replacement for the Cluster Autoscaler. It is similar to the Cluster autpscaler in that nodes are scaled up when pods cannot be scheduled. Both can be run together but scheduling-wise, Karpenter runs first and can provision the right compute resources in seconds. It accomplishes this by observing the aggregate resource requests of unschedulable pods and making decisions to launch and terminate nodes to minimize scheduling latencies. Cluster Autoscaler will then act to downsize unneeded nodes. The Cluster Autoscaler when configured to be used with Node Groups that support scheduling constraints that aren’t supported by any other Provisioner, will continue to work as before.
How does Karpenter Work
Karpenter leverages two control loops that enable it to mazimize cluster resource availability and usage. Using these two controllers, enables Karpenter to balance availability and cost.
- The Allocator is the fast-acting controller that ensures that pods are scheduled in quick time, typically seconds
- The Reallocator is a slow-acting cost-sensitive controller that ensures that excess node capacity is reallocated as pods are evicted
For most container/EKS deployment scenarios that span a tenant workload, a single Karpenter provisioner is adequate to manage the cluster. The Provisioner takes into account the AZ, the EC2 instance type, the AMI and other scheduling constraints. For multi-tenant deployments with workload isolation requirements, one can define multiple Provisioners. Karpenter brings a set of provisioner set of defaults that can be overridden by pod scheduling constraints.
As depicted above, the basic flow in Karpenter is that incoming pods are observed in terms of their resource requests. Pods are then provisioned into nodes. Karpenter will only manage the nodes it provisions. Nodes are then terminated if they are unused, pods are rebalanced based on resource requirements. As discussed above, Karpenter is designed to work alongside existing AWS Capacity providers such as EKS Managed node groups and ECS Auto scaling groups. Customers can use a mixed model of cluster capacity management. Over the long term, it is expected that Karpenter will be leveraged more and more as the premier dynamic cluster node manager.
References
Please check out the project at it’s Github home – https://github.com/awslabs/karpenter