Provisioner API
Example Provisioner Resource
Node deprovisioning
If neither of these values are set, Karpenter will not delete instances. It is recommended to set the ttlSecondsAfterEmpty
value, to enable scale down of the cluster.
spec.ttlSecondsAfterEmpty
Setting a value here enables Karpenter to delete empty/unnecessary instances. DaemonSets are excluded from considering a node “empty”. This value is in seconds.
spec.ttlSecondsUntilExpired
Setting a value here enables node expiry. After nodes reach the defined age in seconds, they will be deleted, even if in use. This enables nodes to effectively be periodically “upgraded” by replacing them with newly provisioned instances.
Note that Karpenter does not automatically add jitter to this value. If multiple instances are created in a small amount of time, they will expire at very similar times. Consider defining a pod disruption budget to prevent excessive workload disruption.
spec.requirements
Kubernetes defines the following Well-Known Labels, and cloud providers (e.g., AWS) implement them. They are defined at the “spec.requirements” section of the Provisioner API.
These well known labels may be specified at the provisioner level, or in a workload definition (e.g., nodeSelector on a pod.spec). Nodes are chosen using both the provisioner’s and pod’s requirements. If there is no overlap, nodes will not be launched. In other words, a pod’s requirements must be within the provisioner’s requirements. If a requirement is not defined for a well known label, any value available to the cloud provider may be chosen.
For example, an instance type may be specified using a nodeSelector in a pod spec. If the instance type requested is not included in the provisioner list and the provisioner has instance type requirements, Karpenter will not create a node or schedule the pod.
📝 None of these values are required.
Instance Types
- key:
node.kubernetes.io/instance-type
Generally, instance types should be a list and not a single value. Leaving this field undefined is recommended, as it maximizes choices for efficiently placing pods.
☁️ AWS
Review AWS instance types.
The default value includes all instance types with the exclusion of metal (non-virtualized), non-HVM, and GPU instances.
View the full list of instance types with aws ec2 describe-instance-types
.
Example
Set Default with provisioner.yaml
Override with workload manifest (e.g., pod)
Availability Zones
- key:
topology.kubernetes.io/zone
- value example:
us-east-1c
☁️ AWS
- value list:
aws ec2 describe-availability-zones --region <region-name>
Karpenter can be configured to create nodes in a particular zone. Note that the Availability Zone us-east-1a
for your AWS account might not have the same location as us-east-1a
for another AWS account.
Learn more about Availability Zone IDs.
Architecture
- key:
kubernetes.io/arch
- values
amd64
(default)arm64
Karpenter supports amd64
nodes, and arm64
nodes.
Capacity Type
- key:
karpenter.sh/capacity-type
☁️ AWS
- values
spot
on-demand
(default)
Karpenter supports specifying capacity type, which is analogous to EC2 purchase options.
Karpenter prioritizes Spot offerings if the provisioner allows Spot and on-demand instances. If the provider API (e.g. EC2 Fleet’s API) indicates Spot capacity is unavailable, Karpenter caches that result across all attempts to provision EC2 capacity for that instance type and zone for the next 45 seconds. If there are no other possible offerings available for Spot, Karpenter will attempt to provision on-demand instances, generally within milliseconds.
Karpenter also allows karpenter.sh/capacity-type
to be used as a topology key for enforcing topology-spread.
spec.kubeletConfiguration
Karpenter provides the ability to specify a few additional Kubelet args. These are all optional and provide support for additional customization and use cases. Adjust these only if you know you need to do so.
☁️ AWS
You can specify the container runtime to be either dockerd
or containerd
.
dockerd
will be chosen by default for Inferentia instanceTypes. For all other instancescontainerd
is the default.- You can only use
containerd
with the Bottlerocket AMI Family.
spec.limits.resources
The provisioner spec includes a limits section (spec.limits.resources
), which constrains the maximum amount of resources that the provisioner will manage.
Karpenter supports limits of any resource type that is reported by your cloud provider.
CPU limits are described with a DecimalSI
value. Note that the Kubernetes API will coerce this into a string, so we recommend against using integers to avoid GitOps skew.
Memory limits are described with a BinarySI
value, such as 1000Gi.
Karpenter limits instance types when scheduling to those that will not exceed the specified limits. If a limit has been exceeded, nodes provisioning is prevented until some nodes have been terminated.
Review the resource limit task for more information.
spec.provider
This section is cloud provider specific. Reference the appropriate documentation: