Copy page

Integrations

Karpenter

Kraftlet 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, the Kubernetes node autoscaler, so the objects and the workflow are the ones Karpenter users already know.

How a node comes up

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 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 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 lets you overcommit those caps by a wide margin.
• Changing a nodeclass replaces the machines made from it rather than reconfiguring them in place.