Karpenter vs Cluster Autoscaler：AWS EKS ノードオートスケーリング比較

はじめに

深夜 3 時。Grafana の赤いアラートを見つめています。Pod は Pending のまま 4 分。トラフィックのピークなのに、ノードはまだ「起動中」です。

隣のクラスター管理者はとっくに寝ています。オートスケーリングは 55 秒でノードを立ち上げました。

誇張ではありません。Karpenter と Cluster Autoscaler の、実際の差です。

正直、最初この数字を見たときは半信半疑でした。「1 分と 3 分の差が、本当にそんなに大きいのか？」と。EKS 上で両方を動かしてみて初めて実感しました。この差は、オートスケーリング戦略全体を見直したくなるほど大きいのです。

Reintech の 2026 年レポートによると、Karpenter のスケールアウトは 60 秒以内、Cluster Autoscaler（以下 CA）は 3〜5 分かかります [1]。コスト面では、実ユーザーが 20〜40% の節約を報告 [2]。Salesforce は 1000 以上のクラスター規模で移行を完了しています [3]。

この記事では、2 つのツールの違い、選び方、移行の進め方を整理します。実データ、設定例、移行タイムラインを使って答えていきます。

アーキテクチャ比較：なぜ速度差がこれほど大きいのか

要点はシンプルです。CA はノードグループに依存し、Karpenter はノードを直接プロビジョニングします。

聞こえは簡単ですが、アーキテクチャの差がオートスケーリング全体のフローに直結します。

Cluster Autoscaler の「迂回」フロー

CA の動きは、遠回りに見えます。

Pod のスケジューリングが失敗すると、CA はまず事前定義されたノードグループ（Node Group）を確認します。各ノードグループは固定のインスタンスタイプに紐づいています。例えば node-group-1 が m5.large、node-group-2 が c5.xlarge、といった具合です。

次に「どのノードグループが適切か」を判断し、クラウド API（AWS Auto Scaling Groups API）でスケールアウトをリクエストします。その後、ASG がインスタンスを起動し、クラスターに参加し、ノードが Ready になって、ようやく Pod をスケジュールできます。

合計 4〜5 ステップ。各ステップに遅延が乗ります。

特に「ノードグループの確認 → 選択」がボトルネックになりやすいです。Pod が GPU を必要とするのに、ノードグループに GPU タイプがなければ、CA は手詰まりです。既存グループから選ぶしかありません。

Karpenter の「直球」アプローチ

Karpenter はまったく違います。

Pod がスケジュールできない？問題ありません。Karpenter は Pod の要件を直接見ます。CPU はどれくらい？メモリは？GPU は必要？特殊な toleration や nodeSelector はある？

要件を分析したら、EC2 API を直接呼び出して最適なインスタンスを Provisioning します。ノードグループも ASG も不要。Pod 要件にそのままマッチします。

あとはノード起動 → クラスター参加 → Pod スケジューリング。2 つのコアステップで、中間の迂回が消えます。

AWS 公式ドキュメントも明言しています。Karpenter は 1 分以内にコンピューティングリソースを起動できます [4]。

たとえ話

CA をレストランの注文フローに例えると——客が唐揚げを頼みたい。ウェイターはまずメニューにあるか確認（ノードグループ確認）。あれば注文（ASG 呼び出し）、厨房が下ごしらえ（インスタンス起動）、料理提供（Pod スケジューリング）。

Karpenter はオープンキッチン。客の要望（Pod specs）を見て、冷蔵庫から素材を取り出し（EC2 API）、その場で調理して提供。

どちらが速いか、一目でわかります。

なぜ CA はノードグループに依存するのか

CA は設計当初からマルチクラウド対応が前提です。ノードグループの仕組みで、AWS・GCP・Azure に同じロジックを適用できます（呼び名だけ違う：AWS は ASG、GCP は MIG、Azure は VMSS）。

反面、ノードグループを事前定義する必要があります。新しいインスタンスタイプを使いたい？ノードグループを追加。Spot を使いたい？Spot 用ノードグループを追加。運用コストは増え、柔軟性は下がります。

Karpenter は AWS ネイティブ設計です。ノードグループという中間層を挟まず、EC2 API と直接やり取りします。マルチクラウド対応は弱い（現状は主に AWS）一方、速度と設定のシンプルさで勝ちます。

パフォーマンスベンチマーク：実環境での差

Karpenter はスケールアウトが速く、スケールイン効率も高い。

この章のデータは、CHKK の技術テストと実ユーザーのフィードバックが主なソースです。

スケールアウト速度：実測比較

CHKK のテストデータはわかりやすいです [5]：

• Karpenter：CPU 集約型 Pod の起動時間は約 55 秒
• Cluster Autoscaler：同じ負荷で 3〜4 分

AWS 公式の「1 分以内」とほぼ一致しています [4]。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

Reddit では、あるユーザーが独自テストを行い、差はそこまで大きくないと報告していました。ノード Ready までの遅延はほぼ同じで、クラスター規模が小さかった（10 ノード程度）からだろう、とのこと [6]。単一ユーザーの参考値として扱うのが妥当です。

スケールイン効率：どちらが節約に効くか

スケールアウトの速さは表向きの話。本当に効くのはスケールイン効率です。

CA のスケールインは定期スキャン型です。一定間隔（デフォルト 10 秒）でクラスターを見て、長時間アイドルなノードがあれば、閾値（デフォルト 10 分）超えでスケールインをトリガーします。

Karpenter は Consolidation を使います。ノード利用率をリアルタイム監視し、統合できるなら統合、置き換えできるなら置き換えます。

例：3 つの m5.xlarge ノードがあり、利用率が 30%、25%、20%。Karpenter は「これらの Pod を 1 つの m5.large に収められるか？」と判断し、可能なら 3 台を 1 台に置き換えます。

AWS 公式ブログのデータでは、Spot と Consolidation を組み合わせると、オンデマンド比で最大 90% のコスト削減が可能です [7]。

大規模クラスターでの差

CA は大規模クラスター（100+ ノード）でボトルネックになりやすいです。

ScaleOps のブログによると、ノードグループが増えるほど CA のスケジューリング判断が遅くなります [8]。全ノードグループを走査して最適なものを探すからです。グループが増えると走査時間が伸び、レイテンシも増えます。

Karpenter はノードグループに縛られません。Pod 要件を直接分析して最適なインスタンスタイプを選びます。クラスター規模が大きくてもロジックは同じです。

実践ケース：バッチ処理

実際に見たシナリオを紹介します。

あるデータパイプラインが毎時バッチを走らせ、50 個の worker Pod が必要でした。CA 環境では Pod が Pending のまま 3 分待ち、バッチ起動が遅れ、パイプライン全体のサイクルが伸びました。

Karpenter 移行後は 50 秒以内に全 Pod が Running。バッチは定刻起動し、下流処理も正常化しました。

バッチ処理は起動遅延に敏感です。3 分の待ちはデータパイプライン全体の遅延につながります。1 分以内のスケールアウトは、この種のワークロードでは必須に近いです。

コスト削減：20〜40% の仕組み

Karpenter のコスト優位性は、Spot インスタンス、Consolidation、インスタンス選択戦略の 3 つから来ます。

どれも単体では新しくありません。組み合わせると 20〜40% の節約——Reintech レポートの実ユーザーデータ [2]——になります。

Spot インスタンス：最大 90% 削減

AWS Spot インスタンスは、オンデマンド比で最大 90% 安くなります [7]。AWS 公式データで、信頼性は高いです。

ただし Spot はいつ中断されてもおかしくありません。AWS は 2 分前に通知し、インスタンスを回収します [7]。

CA で Spot を使うには、Spot ノードグループを手動作成し、中断処理ロジックも自前で組む必要があります。手順が煩雑で、ミスも起きやすいです。

Karpenter は Spot 中断を自動処理します。通知を受けたら 2 分以内に cordon（スケジュール不可マーク）と drain（Pod 移行）を完了。追加スクリプトは不要で、ロジックは組み込み済みです。

PCO 戦略：Spot を賢く選ぶ

Karpenter は Price Capacity Optimized（PCO） 戦略を使います [7]。

要するに、中断確率が最も低い Spot プールを先に選び、その中で最も安いインスタンスを取ります。

最安プールは中断しやすく、最安定プールは節約効果が薄い。PCO はその中間でバランスを取ります。

AWS 公式ブログの説明 [7]：

1. Karpenter が Spot プールの中断率を監視（AWS 公式データ）
2. 中断率の高いプールを除外
3. 残りから最も安いインスタンスタイプを選択

設定不要。Karpenter がデフォルトで有効にします。

Consolidation：リアルタイムで節約

Consolidation は前章で触れました。ここでは設定を詳しく。

Karpenter は 2 つの Consolidation 戦略をサポート [7]：

• WhenEmpty：ノードが完全にアイドルなら削除
• WhenUnderutilized：利用率が低ければ統合または置換を試みる

デフォルトは WhenUnderutilized で、より積極的です。

例：

# Karpenter NodePool — Consolidation 設定
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized  # 積極的な統合
    consolidateAfter: 1m                     # アイドル 1 分後にトリガー

CA にはこの機能がありません。長時間アイドルなノードを定期的に削除するだけで、「小ノードを統合して大ノードにする」「高価なインスタンスを安価なものに置き換える」といった最適化はできません。

ROI 計算：実際の数字

月額 $50,000 のクラスター（100 ノード、混合インスタンスタイプ）を想定します。

Karpenter 移行後、控えめに 20% 削減：$10,000/月。

Spot を十分活用し Consolidation も効かせれば 40% 削減：$20,000/月。

年間 $120,000〜$240,000 の節約。Reintech の実ユーザーデータ [2] に基づく試算です。実際の効果はワークロード、Spot 比率、Consolidation 設定次第です。

設定比較：どちらが楽か

CA の Spot 設定フロー：

1. Spot ASG を作成（インスタンスタイプを手動選択）
2. ASG の Spot allocation strategy を設定
3. 中断処理スクリプトを作成（通知監視、手動 drain）
4. CA の --node-group-auto-discovery パラメータを設定

Karpenter の Spot 設定：

# 1 つの NodePool で完了
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]  # Spot / On-demand を自動選択
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]  # c/m/r シリーズで多様化
  disruption:
    consolidationPolicy: WhenUnderutilized

1 つの YAML で Spot 選択、インスタンスタイプの多様化、Consolidation をカバー。中断処理、最適インスタンス選択、ノード統合も自動です。

手間の差ははっきりしています。

設定の複雑さ：初期コストと長期コスト

CA は設定が速い。Karpenter は学習に時間がかかるが、長期運用コストは逆転します。

Reintech レポート [1] では、CA 設定は「数時間」、Karpenter は「1〜2 日」とされています。

最初は大げさに感じましたが、実際に触ってみると、おおむねその通りでした。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

CA：始めやすい、後から大変

CA の設定フロー：

# CA Deployment（簡略版）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  containers:
  - name: cluster-autoscaler
    image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.30.0
    command:
    - ./cluster-autoscaler
    - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled
    - --scale-down-unneeded-time=10m
    - --scale-down-delay-after-add=10m

コアパラメータは数個：ノードグループ検出、スケールイン閾値、遅延時間。Deployment を置き、ノードグループ（ASG）を作れば動き始めます。数時間で済む、は本当です。

ただし運用コストは後から来ます。

新インスタンスタイプを追加したい？ノードグループを追加。Spot を使いたい？Spot ノードグループを追加。グループが増えるほど管理が煩雑に——各 ASG に min/max、インスタンスタイプ、ラベル設定が別々に必要です。

長期的には YAML の山になり、1 パラメータの変更が複数グループに波及します。

Karpenter：始めに時間、後は楽

Karpenter の難しさは概念理解にあります。

NodePool、Disruption、Consolidation、requirements——初めて触れたとき、各パラメータの意味を把握するのに丸 1 日かかりました。

# Karpenter NodePool（完全版）
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: karpenter.k8s.aws/instance-generation
        operator: Gt
        values: ["5"]  # 第 5 世代以上
      nodeClassRef:
        name: default
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 1m
  limits:
    cpu: 1000
    memory: 1000Gi

CA の Deployment よりパラメータは多いです。理解すれば、1 つの NodePool で複数インスタンスタイプ、Spot/On-demand 混合、自動 Consolidation をまとめて管理できます。

運用コストはほぼゼロに近いです。

新インスタンスタイプを追加？requirements の values に系列を足すだけ。Consolidation を調整？consolidationPolicy を変えるだけ。ノードグループの山を維持する必要はありません。

2 つのトレードオフ

Reintech のアドバイス [1] は実用的です：

• CA が向く：エンジニアリングリソースが限られ、シンプルな設定を好む、ワークロードが同質
• Karpenter が向く：プラットフォームエンジニアリングチームがある、ワークロードが多様、コスト重視、学習時間を投資できる

個人で 10〜20 ノードを維持するなら、CA のシンプルさが合うかもしれません。

50+ ノードをチームで運用する、またはバッチ + Web + GPU など多様なワークロードなら、Karpenter の長期コストの方が低くなります。

移行ロードマップ：CA から Karpenter へ

移行期間は 2〜4 週間。最大のリスクは 2 システムの並行稼働です。

Reintech レポート [1] の数字に、Salesforce の事例 [3] が説得力を添えます——1000 以上の EKS クラスターで移行完了。Karpenter transition tool（公式移行ツール）と並行稼働戦略を組み合わせました。

第 1 週：準備

目標：Karpenter インストール、NodePool 作成、IAM 権限設定。

タスク：

1. Karpenter をインストール（helm または eksctl）
2. NodePool を作成（まずはシンプルに、Spot/On-demand 混合）
3. IAM 権限を設定（EC2 権限が必要）
4. Karpenter が正常に Provisioning できることを確認

注意点：

• IAM 権限は漏れなく。ec2:RunInstances、ec2:TerminateInstances、ec2:DescribeInstances などが必要
• NodePool の limits は適切に（例：cpu: 100 で無限 Provisioning を防止）
• CA は止めない。並行稼働のまま、Karpenter は予備として動かす

第 2 週：テスト

目標：非クリティカルなワークロードを Karpenter に移し、性能を比較監視。

タスク：

1. テストワークロードを選ぶ（バッチ、低優先度サービス）
2. nodeSelector または affinity で Karpenter ノードへ向ける
3. スケールアウト速度、Spot 中断処理、Consolidation 効果を観察
4. CA と Karpenter の遅延・コストを比較

注意点：

• テストはクラスターリソースの 10〜20% に抑える
• 監視重点：Pod Pending 時間、ノード起動時間、Spot 中断回数、ノード利用率
• 性能が悪ければ NodePool の requirements や consolidationPolicy を調整

第 3 週：並行稼働

目標：本番ワークロードを段階的に移行。CA と Karpenter を並行運用。

タスク：

1. 毎日 10〜15% の本番ワークロードを移行
2. nodeSelector で Pod 配置を制御（CA ノード / Karpenter ノード）
3. 両システムのスケーリング頻度、コスト、安定性を監視
4. 問題があればロールバック（Pod を CA ノードへ戻す）

注意点：

• 並行稼働中は干渉のリスクあり。CA がスケールアウトしたノードを Karpenter の Consolidation が誤削除する、など。nodeSelector で分離が鍵
• Pod Pending が 3 分超でアラート（AWS 公式推奨 [7]）
• コストが上がったら Spot 比率と Consolidation 設定を確認

第 4 週：完全切り替え

目標：CA を無効化、ノードグループを整理、Karpenter が全ワークロードを引き継ぐ。

タスク：

1. CA を無効化（Deployment の replicas を 0）
2. CA のノードグループ（ASG）をクリーンアップ
3. 全 Pod の nodeSelector を外し、Karpenter に自動スケジューリング
4. 全量 Karpenter の性能を監視、NodePool を調整

注意点：

• CA 停止前に Karpenter が全ワークロードを引き継いでいることを確認
• ASG 削除前に、稼働中ノードがないことを確認
• 切り替え後、数日間観察して異常がないか見る

Salesforce の移行経験

Salesforce の事例は AWS Architecture Blog に詳述されています [3]。

移行フロー：

1. Karpenter transition tool で CA ノードグループ設定を検出し、同等の NodePool を生成
2. CA と Karpenter を並行稼働し、ワークロードを段階移行
3. 各クラスターのスケーリング遅延とコスト変化を監視
4. CA 無効化後、ノードグループをクリーンアップ

transition tool が設定移行を簡素化。CA のノードグループ設定が NodePool に自動変換され、手動設定時間を省けます。

"1000 以上の EKS クラスターで Cluster Autoscaler から Karpenter への移行を完了しました。Karpenter transition tool で設定変換を簡素化しています。"

リスク回避チェックリスト

1. 並行稼働：CA をいきなり止めず、一定期間並行運用
2. nodeSelector 制御：ラベルで Pod 配置を分離し、干渉を防止
3. limits 設定：NodePool に CPU/Memory limits で過剰スケールアウトを防止
4. 監視アラート：Pod Pending が 3 分超でアラート [7]
5. ロールバック準備：CA 設定ファイルを残し、いつでも戻せるように

意思決定フレームワーク：2026 年はどう選ぶか

正解は 1 つではなく、優先順位次第です。

Reintech の意思決定テーブル [1] に、AWS 公式情報を補足しました。

5 次元の判断マトリックス

典型的なシナリオ

シナリオ 1：小チーム、シンプルなワークロード

• クラスター規模：10〜20 ノード
• ワークロード：Web 中心、トラフィック安定
• 優先：シンプルな設定、すぐ始めたい

推奨：CA。数時間で設定完了。小規模では運用コストも目立たない。Karpenter の学習コストは見合わないかもしれません。

シナリオ 2：中〜大規模チーム、コスト重視

• クラスター規模：50+ ノード
• ワークロード：Web + バッチ + Spot タスクの混合
• 優先：コスト管理、自動化

推奨：Karpenter。20〜40% の節約は中〜大規模で顕著 [2]。Consolidation と Spot 自動化が運用負荷も下げます。

シナリオ 3：マルチクラウド

• クラスター：AWS + GCP + Azure
• 優先：統一されたオートスケーリング

推奨：CA。マルチクラウド対応が成熟。GCP/Azure もノードグループ機構あり。Karpenter は現状 AWS 中心。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

今後のトレンド：EKS Auto Mode

AWS は 2026 年に EKS Auto Mode をリリースしました——Karpenter ベースのネイティブソリューション [4]。

Karpenter のロジックを EKS に統合し、別途 Karpenter をインストールせずに EKS がノードをオートスケールします。

AWS の方向性を示すトレンドです。Karpenter のアーキテクチャが、AWS が認める将来像と言えます。

新規クラスターなら EKS Auto Mode を検討し、インストール・設定ステップを省略できます。

マルチクラウドサポート比較

CA：AWS、GCP、Azure をカバー。

• AWS：Auto Scaling Groups
• GCP：Managed Instance Groups
• Azure：Virtual Machine Scale Sets

ノードグループ機構がマルチクラウドに自然に適合します。

Karpenter：主に AWS。他クラウドは進展が遅い。

公式は AWS のみ。Azure 向けコミュニティ PR（一部機能）、GCP は初期段階。

マルチクラウドが必要なら、現時点では CA が唯一の成熟選択肢。長期的には Karpenter も整備が進む見込みです。

私の推奨

AWS 上のクラスターで、次を満たすなら：

1. 30 ノード超
2. ワークロードが多様
3. コストが重要な判断軸
4. プラットフォームエンジニアリングチームがある

Karpenter、または EKS Auto Mode を採用。

20 ノード未満、またはマルチクラウドなら、CA は依然として堅実な選択です。

2026 年の AWS EKS では Karpenter が推奨ソリューションですが、移行には 2〜4 週間の計画とテストが必要。急いで切り替えないでください。

まとめ

結論は 3 点に集約できます。

Karpenter は速度・コスト・柔軟性で優位。CA はシンプルさとマルチクラウド対応で依然価値がある。

2026 年の AWS EKS では Karpenter が推奨ですが、移行は 2〜4 週間の計画とテストが前提です。

AWS ネイティブでワークロードが多様、コスト重視なら、まずテスト用 NodePool を作ってみましょう。公式移行ガイド [9] を参照し、2 週間並行稼働してから段階的に切り替えてください。

マルチクラウド、または小規模で安定したワークロードなら、CA で十分。無理に移行する必要はありません。

次のアクション：

• Karpenter 公式移行ドキュメント [9] を読む
• テスト NodePool を作成し、バッチタスクを 1 本試す
• Pod Pending 時間とコスト変化を監視し、CA と比較する

今後も EKS クラスター管理の実践記事を続けます。ブログを購読して更新をお見逃しなく。

参考資料

[1] Reintech - Karpenter vs Cluster Autoscaler: Which Should You Use in 2026
https://reintech.io/blog/karpenter-vs-cluster-autoscaler-comparison-2026

[2] Reintech - ユーザーの実コスト削減レポート（20〜40%）

[3] AWS Architecture Blog - How Salesforce migrated from Cluster Autoscaler to Karpenter
https://aws.amazon.com/blogs/architecture/how-salesforce-migrated-from-cluster-autoscaler-to-karpenter-across-their-fleet-of-1000-eks-clusters/

[4] AWS EKS Official Docs - Scale cluster compute with Karpenter and Cluster Autoscaler
https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html

[5] CHKK - Karpenter vs. Cluster Autoscaler
https://www.chkk.io/blog/karpenter-vs-cluster-autoscaler

[6] Reddit r/kubernetes - ユーザー実測フィードバック（ノード Ready 遅延）
https://www.reddit.com/r/kubernetes/comments/zsmqrk/karpenter_vs_cluster_autoscaler_findings/

[7] AWS Blog - Using Amazon EC2 Spot Instances with Karpenter
https://aws.amazon.com/blogs/containers/using-amazon-ec2-spot-instances-with-karpenter/

[8] ScaleOps - Karpenter vs Cluster Autoscaler: Definitive Guide for 2025
https://scaleops.com/blog/karpenter-vs-cluster-autoscaler/

[9] Karpenter Official Docs - Migrating from Cluster Autoscaler
https://karpenter.sh/docs/getting-started/migrating-from-cas/