Learn Karpenter - Latest Stable Features (v1.14)

#Introduction

In episode 19 you tuned Karpenter for latency and binpacking efficiency. But good tuning for the current version is not necessarily correct for the next one. Karpenter moves fast, and understanding the direction of its releases determines how much work you must do when upgrading.

This episode maps Karpenter's evolution from v1.0 in 2024 to v1.14.0 in July 2026. We break down the v1 API that removes v1beta1, Kubernetes 1.29-1.36 support, then the standout features: Static Capacity, NodeOverlay, drift detection for the CA bundle, and scheduling and disruption budget improvements.

#Release Evolution: From v1.0 to v1.14

Karpenter reached its first major stability at v1.0 in 2024. Since then, minor releases have come regularly, and each one brings real changes for users.

#The v1 API and the End of v1beta1

Karpenter v1.0 introduced a new generation of APIs: NodePool replaces Provisioner, and NodeClaim replaces Machine. Since v1.1.0, the karpenter.sh/v1beta1 apiVersion has been removed entirely — all resources must use karpenter.sh/v1.

For those following this series, the v1 API has been in use since episode 3. That means there is no sudden migration. But if you take over an older cluster, check the apiVersion on every manifest:

kubectl get nodepools -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'
kubectl get nodes -o wide

The AWS provider follows the same pattern: EC2NodeClass uses karpenter.k8s.aws/v1, replacing the beta API from the previous generation. Always match the manifest apiVersion with the CRD version installed in the cluster.

#Kubernetes 1.29-1.36 Support

Karpenter maintains compatibility with a certain range of Kubernetes versions. In v1.14, the supported range is Kubernetes 1.29 through 1.36. Understanding this range matters when planning an EKS cluster upgrade.

Before upgrading the cluster:

1. Read the Karpenter release notes for the version you use.
2. Make sure the target cluster version is still within the supported range.
3. Upgrade Karpenter first if needed, then upgrade the cluster.

#Static Capacity

Static Capacity is a feature that treats static capacity — bare metal, on-premises, or dedicated nodes — as part of the same NodePool. Karpenter does not launch instances for this capacity, but it still schedules workloads there based on the same requirements and taints.

This feature sits behind the StaticCapacity feature gate since v1.8.x. Static nodes are registered to the cluster with labels matching the NodePool requirements, and Karpenter counts them as available capacity. This refines the static capacity approach you saw in episode 17.

settings:
  featureGates:
    staticCapacity: true

#NodeOverlay

NodeOverlay is a feature gate that changes how nodes connect to the cluster network. Instead of every node taking an IP from the main VPC CIDR, nodes use a separate overlay CIDR managed by EKS. The benefits: subnet IP limits are no longer a barrier to node growth, and IP capacity is predictable regardless of the number of instances.

Because this mode affects scheduling decisions — Karpenter must know the additional resources and pricing adjustments that come from the overlay — the feature is still alpha since v1.7.x. Test it in a staging environment with production-representative load before enabling it.

#Drift Detection for the CA Bundle (v1.12+)

Since v1.12, Karpenter detects drift when the CA bundle sent to nodes changes. Previously, changes to the CA bundle in the EC2NodeClass did not trigger node replacement — so running nodes kept using the old certificate. Now the NodeClass hash includes the CA bundle, and Karpenter replaces nodes that fall behind.

apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  userData: |
    #cloud-config
    write_files:
      - path: /etc/kubernetes/ca-bundle.crt
        content: |
          <base64-ca-bundle>

#Scheduling and Disruption Budget Improvements

Version v1.14 brings quality improvements in two core areas. On the scheduling side, simulation is more efficient for clusters with many NodePools, and binpacking decisions are more stable so unnecessary instance churn is reduced.

On the disruption budgets side, control is finer-grained: budgets can be set per reason — such as Drifted, Empty, Underutilized — and per time schedule. This lets clusters limit drift during busy hours and give more room during quiet hours, without disabling disruption entirely.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  disruption:
    budgets:
      - nodes: "5%"
        reasons:
          - Drifted
        schedule: "0 9 * * mon-fri"
      - nodes: "50%"
        reasons:
          - Drifted

#A Safe Upgrade Strategy

Following the latest releases matters for security fixes and features, but upgrades must be controlled. The recommended flow:

helm repo update
helm upgrade karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version v1.14.0 \
  --namespace karpenter \
  --reuse-values
kubectl get pods -n karpenter -o wide

Before running: read the upgrade guide on karpenter.sh for the target version, verify the CRD apiVersions used by your manifests, test on a staging cluster, and prepare a rollback plan with the previous Helm version. Release notes always list breaking changes.

#Closing

Following Karpenter's evolution means an upgrade is no longer a scary event, but a planned routine.

Key takeaways:

• The v1 API is established: since v1.1.0, v1beta1 no longer exists; NodePool and EC2NodeClass manifests use karpenter.sh/v1 and karpenter.k8s.aws/v1.
• The Kubernetes range is clear: v1.14 supports Kubernetes 1.29-1.36; plan cluster and Karpenter upgrades together.
• New features arrive via feature gates: Static Capacity and NodeOverlay are still alpha, so evaluate them on staging before production.
• Drift now covers the CA bundle: v1.12+ replaces nodes when the CA bundle changes, preserving trust in cluster certificates.
• Disruption budgets are more precise: per reason and per schedule gives fine-grained control without disabling disruption.

All these features only matter in the real world if they are assembled correctly. In episode 21 we cover production-ready deployment — a multi-NodePool architecture for general, spot, and GPU workloads, strict budgets, HPA and KEDA integration, disaster recovery, and CI/CD and GitOps pipelines. See you there!