An unschedulable Pod triggers a NodeClaim, the Karpenter provider reads the nodeclass and creates a machine through the cloud API, then installs Kraftlet, which connects to the machine and registers it as a node that runs the Pod.

# Karpenter {/* vale off */} :::caution[**Limited Access**] The Karpenter provider for Unikraft is a preview feature available as part of enterprise plans. The behavior described here reflects the current implementation and may change before general availability. To try the preview, reach out to the [Unikraft Cloud Discord](https://kraft.cloud/discord) or send an email to [support@unikraft.com](mailto:support@unikraft.com). ::: {/* vale on */} [Kraftlet](/integrations/kubernetes) lets a Kubernetes cluster run Pods on Unikraft Cloud, but the cluster still needs nodes to schedule those Pods onto. The Karpenter provider for Unikraft creates them on demand. When a Pod has nowhere to run, the provider launches a machine running the Unikraft Cloud platform and installs Kraftlet against that machine. Then the provider joins it to the cluster as a node. Once the capacity goes unused, the provider removes the node and the machine again. The provider builds on [Karpenter](https://karpenter.sh), the Kubernetes node autoscaler, so the objects and the workflow are the ones Karpenter users already know. ## How a node comes up {/* vale off */}

Karpenter turns unschedulable Pods into machines, and Kraftlet turns each machine into a node.

{/* vale on */} No kubelet runs on the machine. Kraftlet takes that role from inside your cluster and reaches the machine over the network, so each machine needs an endpoint your cluster can reach. A node joins the cluster only once the platform on its machine reports healthy. ## What it's good for Without it, a Kraftlet cluster scales to a limited, static capacity. The provider makes Unikraft Cloud capacity elastic from inside Kubernetes, driven by the autoscaler Kubernetes users already run. Nodes arrive when Pods need them and go away once they empty, so a deployment that swings between nothing and thousands of instances holds nodes only while it runs. It also keeps a full node from stalling the cluster. A Pod that no longer fits goes back to its controller and lands on a node with room, or on a new one, as [Pod rescheduling](/integrations/kubernetes#pod-rescheduling) describes. ## What a setup looks like The provider needs the following objects in the cluster: 1. **A `UnikraftNodeClass`** describes the machine behind a node: its image, where it runs, how it gets its DNS records and certificate, and the Kraftlet release that fronts it. 2. **A `NodePool`** specifies which machine sizes to pick, how many nodes to allow, and when to remove the ones that empty. 3. **Your workloads** reach the pool through a toleration and a node selector, the same way they reach a fixed Kraftlet node. Everything the [Kubernetes integration](/integrations/kubernetes) describes then applies to the Pods that land there, including services, volumes, ROMs, plugins, and annotations. Unikraft provides the machine images, and the setup steps for your cluster. The enterprise documentation covers the configuration in full. ## Requirements and limitations * The provider needs a Kubernetes cluster and a cloud account of your own. At the moment, the provider can provision machines on AWS and GCP. * Machines launch as on-demand instances, so a NodePool that asks for `karpenter.sh/capacity-type: spot` gets none. * A node advertises the platform quotas of its machine rather than the size of the machine underneath. You can cap the total vCPUs, memory, and volume storage a node advertises, and [scale-to-zero](/features/scale-to-zero) lets you overcommit those caps by a wide margin. * Changing a nodeclass replaces the machines made from it rather than reconfiguring them in place.