Cluster Autoscaler
Cluster Autoscaler is a Kubernetes utility that increases or decreases the size of a Kubernetes cluster (by adding or removing nodes), based on the presence of pending pods and node utilization metrics.
Automatically resize the Kubernetes cluster when one of the following conditions is met:
- There are pods that cannot run on the cluster due to insufficient resources.
- There are nodes in the cluster that have been underused for a long period of time and their pods can be placed on other existing nodes.
A Kubernetes node autoscaling solution is a tool that automatically scales the Kubernetes cluster based on the demands of our workloads. Therefore, there is no need to manually create (or delete) a new Kubernetes node every time we need it.
Karpenter automatically provides new nodes in response to non-programmable pods. It does this by observing events within the Kubernetes cluster and then sending commands to the underlying cloud provider. It is designed to work with any Kubernetes cluster in any environment.
Architecture of Cluster Autoscaler
- The cluster autoscaler looks for pods that cannot be scheduled and nodes that are underutilized.
- It then simulates adding or removing nodes before applying the change to your cluster.
- The AWS cloud provider implementation in Cluster Autoscaler controls the .DesiredReplicas field of your EC2 Auto Scaling groups.
- The Kubernetes cluster autoscaler automatically adjusts the number of nodes in your cluster when pods fail or are rescheduled to other nodes.
- The cluster autoscaler is typically installed as a deployment on your cluster.
Architecture of Karpenter
Karpenter works with the Kubernetes scheduler observing incoming pods throughout the lifetime of the cluster. It starts or stops nodes to optimize application availability and cluster utilization. When there is enough capacity in the cluster, the Kubernetes scheduler will place the incoming pods as usual.
When pods are started that cannot be scheduled using existing cluster capacity, Karpenter bypasses the Kubernetes scheduler and works directly with your provider's compute service to start the minimum compute resources needed in those pods and associate pods with provisioning nodes.
When pods are removed , Karpenter looks for opportunities to terminate underutilized nodes.
Karpenter claims to offer the following enhancements:
Designed to handle the full flexibility of the cloud
Karpenter has the ability to efficiently address the full range of instance types available through AWS. Cluster Autoscaler was not originally built with the flexibility to manage hundreds of instance types, zones and purchasing options.
Node provisioning without groups
Karpenter manages each instance directly, without using additional orchestration mechanisms such as node groups. This allows you to retry in milliseconds instead of minutes when capacity is not available. It also allows Karpenter to take advantage of different types of instances, Availability Zones and purchasing options without creating hundreds of node groups.
Applying Planning
Cluster Autoscaler does not associate pods with nodes it creates. Instead, it relies on the kube scheduler to make the same scheduling decision after the node is online. The kubelet does not need to wait for the scheduler or the node to prepare. It can immediately start preparing the container runtime environment, including pre-fetching the image. This can reduce node startup latency by a few seconds.
Gratitude for perusing my article till the end. I hope you realized something unique today. If you enjoyed this article then please share it with your buddies and if you have suggestions or thoughts to share with me then please write in the comment box.
Follow me and share your thoughts,
GitHub
LinkedIn
Twitter
The above blog is submitted under 'Devtron Hacktoberfest 2022' conducted by Devtron. Check out their Github repo and give it a star ⭐️ if you like it. Follow Devtron on LinkedIn, Twitter
Top comments (1)
"The kubelet does not need to wait for the scheduler or the node to prepare. It can immediately start preparing the container runtime environment, including pre-fetching the image. This can reduce node startup latency by a few seconds." - can you show some code snippets of official docs for this statement.