Karpenter v1.14:新機能とアップグレード方法

TLDR;

2026年7月11日にリリースされたKarpenter v1.14では、3つの機能が追加されました。GPUやアクセラレーターのスケジューリングに対応するDynamic Resource Allocation(DRA)サポート、ノードの予備容量を確保するアルファ版のCapacityBuffer API、そしてコスト削減効果とPodの中断を天秤にかける新しいBalancedコンソリデーションポリシーです。Balancedコンソリデーションは安定版のフィールドで、本番環境でも安全に利用できます。DRAサポートとCapacityBufferはまだ初期段階のため、まずステージング環境で検証するのがおすすめです。

Karpenter v1.14:新機能とアップグレード方法

Karpenter v1.14は、Kubernetesノードオートスケーラーの最新リリースです。主な追加点は3つ。Dynamic Resource Allocation(DRA)のサポート、予備容量のための新しいCapacityBuffer API、そして新しいBalancedコンソリデーションポリシーです。このうち2つはまだ初期段階です。DRAサポートはKarpenterではまだGAではなく、CapacityBufferはアルファ版でデフォルトでは無効です。

2026年7月11日、Karpenterの2つのリポジトリ(コアプロジェクトとAWSプロバイダー)でv1.14.0がリリースされました。

本記事では、それぞれの機能の内容、アップグレード方法、そして現時点で本番環境に安全に導入できるものを解説します。

今回のリリースには一貫したテーマがあります。Karpenterチームは、オートスケーリングをチューニングする際に信頼性と可用性が最重要であることを理解しています。サービス障害と引き換えにコストを削減したい人はいません。新しいBalancedコンソリデーションポリシーもCapacityBufferも、この考え方に基づいて設計されています。前者は、失うわけにはいかないノードを動かすことなくコストを削減し、後者は予備容量を確保してPodを待たせません。これは、PerfectScaleが当初から採用してきた、信頼性を最優先するコスト最適化のアプローチと同じものです。

Karpenter v1.14の新機能

Karpenterは、Podがスケジュールできないときにノードを起動し、不要になったノードを削除します。v1.14でもこの役割は変わりません。変わったのは、GPUやハードウェアのワークロードに対してより賢くなったこと、予備ノードを確保する手段が加わったこと、そしてより穏やかなコスト削減方法が追加されたことです。

このリリースで注目すべき変更は3つあります。

a. DRAサポート:Karpenterがノードを選ぶ際にPodのDRAリクエストを読み取るようになりました。GPUなどのハードウェアワークロードで特に重要です。

b. CapacityBuffer:予備ノードを常に用意しておくことで、Podをすぐに起動できます。こちらはアルファ版です。

c. Balancedコンソリデーション:削減できるコストが中断に見合う場合にのみノードを削除する新しいポリシーです。

Karpenter v1.14のDRAサポート

DRAは、GPUをはじめとするアクセラレーターなどの特殊なハードウェアを要求するためのKubernetesの仕組みです。nvidia.com/gpu: 1のように固定数を指定する代わりに、PodはResourceClaimで必要なデバイスを記述し、スケジューラーが実際のデバイスを選択します。各ノードには対象ハードウェア用のDRAドライバーが必要です。DRAはKubernetes v1.34でGAとなり、同バージョン以降はデフォルトで有効です。

v1.14より前のKarpenterは、新しいノードを計画する際にこれらのDRAリクエストを読み取っていませんでした。そのため、DRA経由でGPUを必要とするPodは、それを実行できるノードをKarpenterが起動しないためにスケジュールされないまま止まってしまうことがありました。回避策として、旧来のデバイスプラグインモデルでGPU Podを振り分けるのと同じように、nodeSelectorやnode affinityを使って自分で適切なノードへ振り分ける必要がありました。Karpenterはそれらを読み取れますが、DRAクレーム自体を読み取ることはできなかったのです。v1.14ではDRAアロケーターが追加されました。KarpenterはPodのDRAリクエストを読み取り、それをもとに適切なノードを選択します。共有デバイスや分割可能なデバイスにも対応しており、複数のPodが1つのアクセラレーターを共有する場合に役立ちます。

この機能を有効化する必要はありません。デフォルトで有効です。KarpenterにDRAリクエストを無視させたい場合は、--ignore-dra-requestsフラグを設定してください。ただし、この機能はまだ初期段階です。DRAでGPUやアクセラレーターのワークロードを実行している場合は、まずステージング環境で試してください。また、Kubernetes 1.34以降と、対象ハードウェア用のDRAドライバーが必要です。フラグの詳細はSettingsリファレンスを参照してください。

Karpenter CapacityBuffer:予備ノードを常に確保

新しいノードが起動してクラスターに参加するまでには時間がかかります。スパイクが発生するワークロードや待てないワークロードにとって、この遅延は痛手です。PodはPendingのままとなり、トラフィックをさばくためのスケールアップが間に合いません。CapacityBufferを使えば、あらかじめ予備容量を確保しておけるため、新しいノードを待つことなくPodをすぐにスケジュールできます。

この機能は仮想のプレースホルダーPodで動作します。これらのPodはKarpenterの計画の中にのみ存在し、クラスター内に実際のPodとして作られることはありません。仮想PodによってKarpenterは予備ノードを維持し、実際のPodが予備スペースを使用すると自動的に補充されます。

予備容量のサイズは、次の2つの方法のいずれかで指定します。

1. podTemplateRef: バッファ1単位を表すPodTemplateを指定し、replicasやlimitsを設定します。
2. scalableRef: Deployment、StatefulSet、またはReplicaSetを指定し、パーセンテージを設定して予備容量をそのワークロードに連動させます。

以下は5単位の固定バッファの例です。

yaml

apiVersion: autoscaling.x-k8s.io/v1alpha1
kind: CapacityBuffer
metadata:
  name: web-app-buffer
  namespace: default
spec:
  provisioningStrategy: "buffer.x-k8s.io/active-capacity"
  podTemplateRef:
    name: web-buffer-template
  replicas: 5
  limits:
    cpu: "20"
    memory: "40Gi"

あるいは、予備容量をワークロードに連動させるには、Deploymentを指定してパーセンテージを設定します。以下の例では、バッファ容量をapi-service Deploymentのレプリカ数の20%に保つため、そのDeploymentのスケールに合わせて予備容量が増減します。

yaml

apiVersion: autoscaling.x-k8s.io/v1alpha1
kind: CapacityBuffer
metadata:
  name: api-service-buffer
  namespace: default
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: api-service
  percentage: 20

これらを複数設定した場合、最終的な数はmin(max(replicas, percentage), limits)となります。つまり、replicasとpercentageは大きい方が採用され、limitsが上限として機能します。

ノードのクリーンアップについて1つ知っておくべきことがあります。Karpenterは、バッファ容量を保持しているノードを「空」として削除しません。仮想バッファPodがあることで空とはカウントされず、KarpenterはNode has buffer podsという理由でマークします。それ以外のクリーンアップはすべて通常どおり実行されますが、代替ノードもバッファPodを収容できる必要があるため、予備容量は常に維持されます。

CapacityBufferはアルファ版で、デフォルトでは無効です。CapacityBuffer=trueフィーチャーゲートで有効化します。v1.13で追加され、v1.14では内部APIが更新されてステータスメトリクスが追加されましたが、依然としてアルファ版であり、APIは変更される可能性があります。まずはテストクラスターで試してください。また、予備容量にはコストがかかることも忘れないでください。アイドル状態のノードにも料金が発生するため、実際に必要なバーストに合わせてサイズを設定しましょう。