Karpenter Carves Out Keener Kubernetes Compute Consumption

Open source Kubernetes cluster auto-scaling and compute management project Karpenter dons its graduation robes this month as it moves to its 1.0.0 version release. First developed and ruggedized inside the coding booths at AWS, the technology was subsequently open sourced and its APIs are now officially out of beta.

Karpenter exists to help improve application availability, reduce operational overhead and increase cluster compute utilization. 

Step 1 of 7

14%

Which of the following best describes how you currently monitor and manage systems across your hybrid cloud environment?(Required)

Multiple separate tools for different environments

Multiple separate tools for different monitoring and management functions

Single consolidated dashboard

Custom built monitoring and management solution

No full monitoring and management solution

Don’t know

How valuable would it be for your monitoring and management solution to incorporate predictive analytics to help you identify and address system issues that are critical and not waste time or effort working through all the data and “noise” that is not critical?(Required)

Extremely valuable

Moderately valuable

Somewhat valuable

Slightly valuable

Not valuable

How do you most typically address potential system issues BEFORE they impact your operations?(Required)

Automated workflows and playbooks to remediate potential issues as soon as they are detected

An orchestrated response process that leverages automation, AI, and human expertise to rapidly respond to potential issues

Advanced monitoring tools such as predictive analytics and anomaly detection to proactively identify and address potential issues

Respond to issues as they arise, using manual processes and troubleshooting techniques

A combination of automated remediation, orchestrated response, and/or proactive monitoring to address potential system issues

Don’t know

Other

What methods does your organization use to control and monitor cloud/IT spending?(Required)

Centralized procurement processes

Pre-approved budget thresholds

Automated cost monitoring tools

Department-level spending controls

Regular cost audits and reviews

Cloud cost optimization platform

Approval workflows for resource provisioning

Native financial operations tools provided by the cloud provider

No formal controls in place

Don’t know

Other

Please specify:

Which methods do you rely on most to detect security vulnerabilities in your systems?(Required)

Automated scanning tools

Manual assessments

Vendor notifications

Threat modeling (for early detection)

None of these

Don’t know

Other

Please specify:

What are the TWO most common ways you prioritize vulnerabilities to address within your environment?(Required)

Based on potential impact

Based on exploitability

Regulatory compliance requirements

Based on CVSS scores

Risk-based analysis of multiple factors

First-in-first-out approach

No formal prioritization process

Don’t know

How do you typically handle system updates and security patches?(Required)

Automated updates and patches

Manually review and apply updates and patches on a regular schedule

A combination of automation and manual review

Apply updates and patches on an as-needed basis.

Outsourced update and patch management

No defined process

Don’t know

Other

Δ

We can think of Karpenter as a node lifecycle management tool for Kubernetes clusters. It automates the provisioning and de-provisioning of nodes based on the scheduling needs of Kubernetes pods, which (as we know) are the smallest possible unit of deployable execution and exist as a group of one or more containers, with shared storage and network resources.

As the Karpenter team notes, “Karpenter responds quickly and automatically to changes in application load, scheduling and resource requirements, placing new workloads onto a variety of available compute resource capacity. Karpenter lowers cluster compute costs by looking for opportunities to remove under-utilized nodes, replace expensive nodes with cheaper alternatives, and consolidate workloads onto more efficient compute resources.”

Positive K8S Disruption

This official release includes three new features designed to enable greater control over how and when Karpenter “disrupts” Kubernetes applications, in the positive sense of the word meaning changes need to be made to achieve a new utilization efficiency level.

Developers can use Karpenter with Amazon Elastic Kubernetes Service (EKS) or any conformant Kubernetes cluster and, perhaps unsurprisingly, Karpenter has enjoyed widespread adoption across AWS EKS users.

Among Karpenter’s central functions is its ability to monitor pods that the Kubernetes scheduler cannot schedule, often due to operational issues related to system resource constraints. The technology can also evaluate the scheduling requirements (resource requests, node selectors, affinities, tolerations, etc.) of the unschedulable pods in any Kubernetes cluster.

Also as part of the core functionalities on offer here, Karpenter can provision new nodes that meet the requirements of those pods they correspond to. It is also able to remove nodes when they are no longer needed.

Alpha, Beta… Stable

AWS has detailed the project’s API’s maturity progression from alpha to beta then stable, following the same logical path of all other Kubernetes projects. This history of progression includes the APIs moving from alpha to beta in October 2023.

“This release marks the final milestone in the project’s maturity and [developers] can be assured that all Karpenter APIs will remain available in future 1.0 minor versions and not modified in any way that results in breaking changes,” states AWS, in an About AWS blog post. 

Alongside the graduation from beta, this 1.0.0 release includes three new features for Karpenter. Firstly there is the ability to specify “reasons for disruption” (i.e. a flag that tells the engineering team that the  Kubernetes clusters and its nodes and pods are failing to operate at an optimal level of several possible reasons e.g. underutilization, emptiness, drift or budgets.

Drift by Default

“Karpenter drift replaces nodes that drift from a desired state (e.g. using an outdated AMI or Amazon Machine Image). In v1 drift has been promoted to stable and the feature gate removed, which means nodes now drift by default. If users disabled the drift feature gate in v1beta1 they can now control drift by using disruption budgets by reason,” write Alex Kestner, Robert Northard and Rajdeep Saha of the Amazon Elastic Kubernetes Service containers team.

There is also a forceful disruption mode designed to help developers balance application availability against security requirements. Lastly, there is an expansion of the consolidate function, which lets users tune Karpenter’s consolidation feature to meet their cost-efficiency and application availability requirements.

The AWS team recommends that, when approaching the Karpenter 1.0.0 release to upgrade, users read the full Karpenter v1 migration documentation and test their upgrade process in a non-production environment.