KubeCon EUBooth 1151, Amsterdam. March 23-26
Node Operator

Overview

The DevZero Node Operator manages Kubernetes node lifecycle -- provisioning optimal instance types and consolidating underutilized nodes.

Node Operator

The Node Operator is DevZero's node lifecycle manager. It automatically provisions right-sized nodes for your workloads and consolidates underutilized nodes to reduce costs.

What It Does

  • Just-in-time provisioning -- launches nodes only when pods are pending
  • Instance type selection -- chooses the cheapest instance type that fits workload requirements
  • Consolidation -- identifies underutilized nodes and drains them, letting workloads repack onto fewer nodes
  • Spot instance management -- uses spot/preemptible instances where appropriate, with automatic fallback
  • Multi-architecture -- supports mixed AMD64/ARM64 node pools

How It Differs from Cluster Autoscaler

FeatureCluster AutoscalerNode Operator
Provisioning speedMinutes (node group scaling)Seconds (direct API)
Instance type selectionFixed per node groupDynamic per pod
ConsolidationNoYes
Spot managementLimitedBuilt-in

Already Running Karpenter?

If your cluster already uses upstream Karpenter, you can migrate to the DevZero Node Operator with zero downtime. Your existing NodePool and NodeClaim resources are fully compatible -- see the migration guide.

Cloud Provider Setup

The Node Operator requires cloud-specific configuration for IAM roles, instance profiles, and networking:

Core Concepts

NodePool

A NodePool defines constraints for nodes that the Node Operator provisions:

  • Instance types, architectures, and zones
  • Taints and labels to apply
  • Resource limits (max vCPUs, memory across all nodes)
  • Disruption policies (consolidation, expiration)

NodeClaim

A NodeClaim represents a single node being provisioned or running. The Node Operator creates NodeClaims automatically based on pending pod requirements and NodePool constraints.

Consolidation

The Node Operator continuously evaluates running nodes and identifies opportunities to:

  • Delete empty nodes
  • Replace underutilized nodes with smaller, cheaper instances
  • Consolidate workloads onto fewer nodes

Consolidation respects PodDisruptionBudgets, node affinities, and topology spread constraints.

On this page