Karpenterとは｜EKSのノード自動スケーリングの仕組みと導入手順

Karpenterとは｜ノード自動スケーリングを担うコントローラー

Karpenterとは、Kubernetesクラスタのノードを自動で増減させるコントローラーです。クラスタ内にPodとして常駐し、スケジューラが配置先を決められなかったPodを監視します。

もともとAWSが開発を主導していましたが、現在はkubernetes-sigs/karpenterとしてKubernetesのSIG配下で開発されています。コア部分とクラウド別のプロバイダ実装が分離されており、AWS向けの実装がいちばん成熟しています。公式ドキュメントはkarpenter.shにまとまっています。

Karpenterが解決しようとした課題

従来のEKSでは、Auto Scaling groupとCluster Autoscalerの組み合わせでノードを増減させていました。この方式だと、CPU重視のワークロード用、メモリ重視用、GPU用、ゾーン別……とノードグループが増えていきます。

数十個のノードグループを人の手で設計し、保守し続ける。ここが運用のボトルネックになっていました。

Karpenterはこの中間層を取り払いました。「どんなノードを立ててよいか」の制約だけを宣言しておけば、あとは実際のPodの要求を見て、その都度ちょうどいいインスタンスを選びます。

動作の流れ｜Pending PodからEC2起動まで

処理は次の順で進みます。

1. kube-schedulerが配置先を見つけられず、PodがPending状態になる

2. Karpenterがそのポッドのリソース要求・nodeSelector・Affinity・Tolerationを読み取る

3. 条件を満たすインスタンスタイプを候補集合から絞り込む

4. EC2のAPIを直接呼んでノードを起動し、Podをそこへ載せる

5. ワークロードが減ってノードが不要になったら削除する

ASGという中継点がないぶん、条件が合えばノードが使える状態になるまでの時間を短縮しやすい、というのが設計上の狙いです。クラウドコスト最適化ベンダー各社の比較記事では、Karpenterが45〜60秒、Cluster Autoscalerが3〜4分といった測定値が紹介されています。ただしこれらは各社が自社環境で測った値であり、AMIサイズ・ブートストラップ処理・リージョン・インスタンスタイプで大きく変わります。一般的な保証値ではないため、自分の環境で一度は計測してください。

主要リソース｜NodePool・EC2NodeClass・NodeClaim

Karpenterの設定は、役割の違う3つのカスタムリソースに分かれています。

NodePoolが「ポリシー」、EC2NodeClassが「ハードウェアとOSの指定」、NodeClaimが「発注書」だと捉えると整理しやすいでしょう。

Kubernetes自体の基礎をおさらいしたい場合は、Kubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説を先に読んでおくと、この後の話が入りやすくなります。

ミニFAQ

Q. KarpenterはEKS専用ですか？

いいえ。コア実装はクラウド非依存で、AWS以外のプロバイダ実装も存在します。ただし本番実績・ドキュメントの厚さ・機能の追随速度はAWS向けが先行しており、EKS以外で使う場合は対象プロバイダの対応状況を確認してから採用を決めてください。

KarpenterとCluster Autoscalerの違い

結論から書くと、ワークロードの要求が多様で変動が大きいクラスタはKarpenter、容量が静的で均質なクラスタはCluster Autoscalerでも十分です。

アーキテクチャの違い

AWSのEKSベストプラクティスガイドでも、Karpenterは「高負荷が急に立ち上がる、あるいは計算要件が多様なクラスタ」に向くとされています。逆に、ワークロードが安定していて容量が読める環境では、マネージドノードグループのほうが運用が素直です。

ビンパッキングとコストの差

Cluster Autoscalerはノードグループの型が決まっているため、要求が小さいPodにも大きめのノードが割り当たる場面が出ます。Karpenterは「要求に合うサイズ」を選び直せるので、無駄が出にくい構造です。

ただしコスト削減幅を一律に語るのは避けたほうがよいです。クラウドコスト最適化ベンダーのブログでは20〜40%の削減例が紹介されていますが、これは自社顧客の移行事例という母集団の数字で、元の構成がどれだけ過剰だったかに左右されます。ノードグループを丁寧にサイジングしていた環境なら、差はもっと小さくなります。

クラウドコストそのものを扱う仕事に興味があるなら、FinOps・クラウドコスト最適化案件｜単価相場と必要スキル・参入方法も参考になります。

Cluster Autoscalerを残したほうがよいケース

• AzureやGCPが主戦場、あるいはマルチクラウドで同じ仕組みを使いたい

• ノードグループ単位の権限分離・ガバナンスを組織ルールとして運用している

• 予約インスタンスやSavings Plansで容量を固定しており、構成が均質

• 既存のASG運用（AMIパイプライン、起動テンプレート）に資産が蓄積している

なお、Karpenter v1系のAPIではカスタム起動テンプレートのサポートがありません。ユーザーデータやカスタムAMIはEC2NodeClass側で指定する形に変わります。ASG時代の資産をそのまま持ち込めない点は、移行計画で見落としやすいところです。

Karpenterのコスト最適化とノード削除（Disruption）の仕組み

Karpenterがノードを消す条件は4種類あります。ここを理解しないまま導入すると、稼働中のPodが想定外のタイミングで移動します。

詳細は公式のDisruptionドキュメントが一次情報です。

Consolidation｜詰め直しでノードを減らす

consolidationPolicyには、空ノードだけを消す設定と、使用率が低いノードも対象にする設定があります。後者を選ぶと、2台に散っているPodを1台に寄せて片方を落とす、といった動きをします。

ここで最重要の前提があります。Consolidationが見ているのはresources.requestsであって、limitsではありません。

requestsを小さく書いたままlimitsだけ大きいPodがあると、詰め込まれた先で同時にバーストしてOOMが起きます。AWSのベストプラクティスでも、Consolidationを使うならCPU以外のリソースはrequestsとlimitsを揃えることが推奨されています。requestsを書き忘れがちなチームでは、Kubernetes公式のLimitRange設定で名前空間ごとの既定値を入れておくと事故が減ります。

Drift・Expirationでノードを入れ替える

expireAfterを設定すると、一定期間が経ったノードが自動で退役します。AMIの更新を「作り直し」で回す運用と相性がよい仕組みです。

一方で、長時間走るバッチや状態を持つPodが載っているノードが寿命を迎えると、処理が中断されます。このため本番では、GPUノードなど止めたくない用途のNodePoolでexpireAfterを無効にしておく構成がよく採られます。

スポットインスタンスと中断ハンドリング

Karpenterはスポット利用時にPrice Capacity Optimizedという配分戦略を使います。中断されにくく、かつ安いプールから取る戦略です。

ポイントはインスタンスタイプを絞りすぎないこと。候補を数種類に限定すると、そのプールが枯渇した瞬間にPodがPendingのまま滞留します。ゾーンをまたいで分散させるのも効きます。

中断への備えとしては、専用のSQSキューを用意してKarpenterに教えておきます。スポット中断の2分前通知を受け取った時点で、Karpenterが対象ノードにtaintを付けてdrainし、先に代替ノードを立て始めます。Node Termination Handlerとの併用は公式に非推奨とされているため、どちらか一方に寄せてください。

止めたくないPodを守る

• Pod側に「中断しない」注釈（karpenter.sh/do-not-disrupt）を付けると、そのPodが終わるまでノードが保持されます

• PodDisruptionBudgetで最低稼働数を宣言しておけば、退避時にまとめて落ちる事態を防げます

• DaemonSet以外の残りPodがJobだけになった場合、成功・失敗が確定していればKarpenterはノードを回収できます

limitsと請求アラームで暴走を止める

NodePoolにはcpuとmemoryの上限を設定できます。設定しなければ、需要がある限りノードは増え続けます。

ここで注意したいのは、上限はNodePool単位でしか設定できず、クラスタ全体のグローバル上限という概念がないことです。NodePoolを複数作っている場合、合計値は自分で管理するしかありません。請求アラームやCost Anomaly Detectionを併用して、金額側からも歯止めをかけておくのが現実的です。

Karpenterの導入手順｜EKSでの流れ

導入前に確認すること

• コントローラーの置き場所：Karpenter自身をKarpenterが管理するノードに載せてはいけません。最小1ノードのマネージドノードグループか、EKS Fargateのプロファイルを用意します

• 権限：コントローラーがEC2のAPIを叩けるIAM権限と、起動されるノード用のインスタンスプロファイルが要ります

• プライベートクラスタ：外向きの通信がない構成では、STSとSSMのVPCエンドポイントが必須です。これが無いと認証エラーやAMI解決エラーで起動に失敗します

• 価格データ：Price List Query API用のVPCエンドポイントは存在しません。Karpenterはオンデマンド価格をバイナリに同梱しており、その価格データが更新されるのはKarpenterをアップグレードしたときだけです

導入の5ステップ

1. IAMロール・インスタンスプロファイル・中断通知用のSQSキューを作成する

2. Helmチャートでコントローラーを専用の名前空間へ導入する（公式のGetting Startedが手順の基準）

3. EC2NodeClassでAMI・サブネット・セキュリティグループを指定する。サブネットとセキュリティグループはタグで探索させる形が一般的です

4. NodePoolで許可するインスタンスタイプ・ゾーン・capacity-type・limits・disruptionを定義する

5. 検証用のDeploymentをスケールさせ、ノードが起動して統合されるところまで一通り確認する

所要期間の目安として、EKSクラスタをすでに運用していてIAM設計の勘所がある担当者が1名で進める前提なら、検証クラスタでの一連の動作確認は1〜2日。本番のNodePool設計、PDB整備、既存ノードグループからの段階移行まで含めると2〜4週間を見ておくと余裕があります。ワークロードの種類が多い環境や、セキュリティレビューの工程が挟まる組織ではこれより伸びます。移行期間中はCluster Autoscalerと併走させず、対象のワークロードをNodePool側へ順に寄せる進め方が安全です。

なお、必要なEKSのバージョン、Karpenterのバージョン、権限の付与方式（IRSAかPod Identityか）は更新が入りやすい部分です。本番導入の際は、採用するバージョン・IAM権限・ネットワーク構成・PDB設計を公式ドキュメントと自社の運用基準に照らして確認してください。

Helmチャートの管理そのものに不安がある場合は、Helmとは｜Kubernetesのチャート作成と運用・Helm 4の変更点を併せて確認しておくとよいでしょう。

NodePool設計の実務ポイント

• 複数チームで共有するクラスタなら、OSやインスタンス要件の違いごとにNodePoolを分ける

• 複数のNodePoolが同じPodにマッチすると、Karpenterはどれを使うかをランダムに選びます。相互排他にするか、重み付けを設定すること

• GPUのような高価なノードはtaintを付けて、toleration付きのPodだけが載るようにする

• 「このインスタンスタイプは使わせたくない」という除外指定は、許可リストより運用が楽な場面が多いです

ミニFAQ

Q. 既存のマネージドノードグループは全部消してよいですか？

全部は消さないでください。Karpenterのコントローラー自身を動かす場所が必要になります。最小構成のノードグループを1つ残すか、EKS Fargateへ逃がすかの二択で考えるのが定石です。

EKS Auto ModeとセルフマネージドKarpenterの使い分け

EKS Auto Modeは、ノードの用意からAMIのパッチ適用、ネットワークやストレージの設定までをAWS側に任せるEKSのモードです。ノードのスケーリングにはKarpenterと同じ考え方が使われており、コントローラー相当の処理がAWS管理側で動くため、デプロイやアップグレードを自分で面倒みる必要がありません。正式な機能範囲は更新されるので、採用前にAWS公式ドキュメントで確認してください。

AWSのEKS Auto Modeに関するベストプラクティスも判断材料になります。

判断の軸はシンプルです。AMIを細かく作り込む要件やホストアクセスの要件があるならセルフマネージド、逆に専任のプラットフォーム担当を置けないチームならAuto Modeの上乗せ分は十分に見合います。クラスタ内の構成管理をGitOpsで回している環境であれば、ArgoCDとは｜GitOpsの仕組み・Kubernetes運用と案件動向で扱っている運用と組み合わせやすいのはセルフマネージド側です。

運用で詰まりやすい5つのポイント

1. requestsが実態とズレていて詰め直しが荒れる

いちばん多いパターンです。requestsを小さく書いた状態でConsolidationを有効にすると、ノードがぎゅうぎゅうに詰められてOOMが発生します。導入前にリソース要求の棚卸しを済ませておいてください。

2. AMIを最新追従のままにしている

AMIの指定を「常に最新」にしておくと、検証していないAMIが本番に降ってきます。AWSのベストプラクティスでは、本番クラスタでは検証済みAMIをピン留めし、新版は非本番で先に試すことが強く推奨されています。

3. プライベート構成でVPCエンドポイントが足りない

外向き通信のないVPCでは、STSとSSMのエンドポイントが無いとノードが1台も立ちません。認証タイムアウトやSSMパラメータ取得失敗のログが出ている場合は、まずここを疑ってください。

4. ノード入れ替えでDNSが不安定になる

ノードが頻繁に入れ替わる環境では、CoreDNSが終了途中のPodへクエリを流してしまうことがあります。lameduckの時間とreadinessプローブの設定を見直しておくと、入れ替え時の名前解決エラーが落ち着きます。メトリクスで挙動を追うなら、Prometheus & Grafanaとは｜メトリクス監視の基本・Datadogとの違い・案件単価をフリーランス視点で解説の構成が使えます。

5. インスタンスタイプを絞りすぎる

セキュリティ要件や社内ルールで候補を数種類に限定すると、スポットの可用性が一気に落ちます。除外したい型を落としていく引き算の設計にすると、候補の幅を保ちやすくなります。

Karpenterのスキルはフリーランス案件でどう扱われるか

結論として、Karpenter単体を名指しした案件はまだ多くありません。EKS運用やSRE、コスト最適化の案件要件に、使用技術のひとつとして並ぶ形がほとんどです。

求められる文脈

公開案件の募集要項を見ると、Karpenterは次のような文脈で登場します。

• EKSクラスタの新規構築・刷新（IaCと合わせてスキルセットが指定される）

• クラウドコスト削減プロジェクト（スポット活用・ビンパッキング改善）

• プラットフォームチームの立ち上げ（社内向け基盤の整備）

IaC側の前提としてTerraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説で扱う内容が同時に求められるケースが目立ちます。役割の全体像はプラットフォームエンジニアとは｜仕事内容・年収・SRE/DevOpsとの違いが参考になります。

単価の目安

首都圏中心の主要フリーランスエージェント数社の公開案件（週4〜5日・準委任）を2026年10月時点で確認した範囲では、EKS運用を含むSRE・インフラ案件は月70〜110万円前後のレンジで募集されるケースが見られます。これは公開案件ベースの目安であり、確認できた件数も十数件程度なので、観測ベースの参考値として読んでください。

このレンジの上側で声がかかるのは、Kubernetesの本番運用を3年以上経験し、障害対応とコスト削減の双方で成果を数字で語れる人です。非公開案件では個別条件で上振れするケースもありますが、こちらは案件ごとの事情に左右されます。

職種別の詳細はSREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安とAWSエンジニア フリーランスの単価相場｜経験・案件レイヤー別に解説で整理しています。自分がどのくらいの単価を狙えるか知りたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。Kubernetesを扱う案件そのものはKubernetes関連の案件一覧から探せます。

学習と証明の順序

いきなりKarpenterから入るより、スケジューリングの基礎を押さえたほうが結果的に早いです。Podのrequests・nodeSelector・Affinity・taint/tolerationを理解していないと、NodePoolの制約条件が何を指しているのか読めません。

資格で体系化したいならCKA資格とは｜Kubernetes認定の合格ライン・費用・出題範囲と勉強法が出題範囲の確認に使えます。クラスタの拡張という観点では、Kubernetes Operatorとは｜CRDの仕組みと自作の判断基準で扱うカスタムリソースの考え方がKarpenterの理解にそのまま効きます。

導入前チェックリスト

本番投入前に、この10項目を確認してください。

まとめ

Karpenterは、ノードグループという中間層を外してPodの要求から直接ノードを決めるオートスケーラーです。柔軟さとコスト効率を得られる代わりに、設計と前提条件の整備は自分たちで引き受けることになります。

要点を整理します。

• 動作の起点はPending Pod。NodePoolが制約、EC2NodeClassがAWS固有設定、NodeClaimが発注にあたる

• Cluster Autoscalerとの違いはASGを経由しないこと。マルチクラウドやガバナンス重視ならCAを残す判断もある

• コスト効果の主役はConsolidation。ただしrequestsが正確でなければ機能せず、OOMの原因にもなる

• ノード削除のトリガーはConsolidation・Drift・Expiration・Interruptionの4種類。止めたくないPodはPDBと中断防止の注釈で守る

• 運用を任せたいならEKS Auto Mode。管理対象EC2への追加料金とAMI選択・ホストアクセスの制約が対価になる

• 検証は1〜2日、本番移行はNodePool設計とPDB整備を含めて2〜4週間が目安

• 案件ではKarpenter単体ではなくEKS運用・コスト最適化の文脈で求められることがほとんど

次の一歩としては、検証クラスタを1つ立てて、requestsを変えながらノードが立つ様子を観察してみてください。ドキュメントを読むより挙動が早く掴めます。

参照した一次情報は次のとおりです。

• Karpenter公式ドキュメント

• Karpenter Disruption（ノード削除）

• Karpenter Getting Started

• AWS EKSベストプラクティスガイド｜Karpenter

• AWS EKSベストプラクティスガイド｜EKS Auto Mode

• Amazon EKS 料金

• kubernetes-sigs/karpenter（GitHub）