こんにちは。shibatchといいます。少し前になりますが、4月28日に、Cloud Native Days Summer 2025 プレイベントに登壇しました。進化するK8s運用:KarpenterによるCluster Autoscalerからの脱却、運用ノウハウ完全公開と題しまして、KarpenterというKubernetes上で動作するソフトウェアについて紹介しました。
#CNDS2025 続いてのセッションは、@hokatabiによる、「進化するK8s運用:KarpenterによるCluster Autoscalerからの脱却、運用ノウハウ完全公開」です!
— CloudNative Days (@cloudnativedays) April 22, 2025
YouTubeの視聴はこちらから!https://t.co/eV9VMbAMUH pic.twitter.com/C051sCVa3p
30分の登壇で、時間を余すことなくKarpenterについて自分の知見を一から十まで共有したので、この記事ではスマートフォンでも読みやすいように内容をかいつまんでご紹介します。
なお、内容の詳細は以下の登壇資料をご覧ください。
1. はじめに
1.1 自己紹介
技術部 技術基盤グループに所属し、複数のKubernetesクラスタの設計、構築、運用、セキュリティ対策などを担当しています。特にAWSでのプラットフォーム基盤の設計、構築に強みを持っています。
1.2 GMOペパボのマルチブランド戦略とKubernetes
GMOペパボでは、複数のサービスをマルチブランド戦略で展開しています。Kubernetesもさまざまなサービスで導入されていますが、本日はそのうちの2つのサービス(SUZURIとminne)でのKubernetesクラスタについての話になります。
1.3 アジェンダ
- Karpenter入門編
- インストール編
- 運用編
2. Karpenter入門編
2.1 Karpenterとは
私がKarpenterを知ったのはCloud Native Days Tokyo 2023です(この時の参加レポートはこちら - CloudNative Days Tokyo 2023に参加しました )。
Karpenterは、Kubernetesクラスタ用のノードの動的なスケールアウトとスケールインを自動化するノードプロビジョナーです。AWS EKSで動作し、EC2の運用負荷を低減し、Spotインスタンスも利用できます。
2.2 Karpenterの特徴
Karpenterの特徴としては以下の5点が挙げられます:
- コスト最適化が容易
- Podのリソースリクエストに基づいて最適なノード台数を自動でプロビジョニング
- 最適なインスタンスタイプを自動選択
- 強力なSpotインスタンスを用いたコスト最適化設計
- ノードの起動が速い
2.3 Cluster Autoscalerとの比較
Karpenterが登場する前は、EKSでのデファクトのノードプロビジョナーはCluster Autoscalerでした。Karpenterとどのように違いがあるか見てみましょう。
項目 | Cluster Autoscaler | Karpenter |
---|---|---|
デプロイ | ノードグループに依存したスケーリング設定 | ノードグループに依存しない、シンプルなスケーリング設定 |
インスタンスタイプ | ノードグループとインスタンスタイプが1:1、Spot/On-Demandのどちらかを選択 | 1つのノードプールで複数のインスタンスタイプから自動選択、Spot/On-Demandも自動選択 |
スケーリング速度 | Karpenterより遅い | Cluster Autoscalerより速い |
Spotインスタンス | キャパシティリバランシングまたは中断通知によるDrain | 中断通知によるDrainのみ |
このように、KarpenterはCluster Autoscalerと比較して簡単な設定で運用できる点が強みです。対しCluster Autoscalerはスポットインスタンスの中断制御においてはまだ一日の長があると言う状況です。
2.4 結局、こういう人におすすめ
Karpenterはほったらかしでコスト最適化したい という用途に向きます!
3. インストール編
3.1 インストール手順概要
公式ドキュメントでは以下の4点がインストール手順として載っています:
- CloudFormationテンプレートをダウンロード&デプロイ
- eksctlコマンドでクラスタを作成
- helmでKarpenterをインストール
- Karpenterの設定(NodeClass, NodePool)を定義
ただし、いくつかつまずきポイントがあります…
3.2 インストールの注意点
公式のインストール手順はCloudFormation&eksctlコマンドを使う前提であり、Terraformを使うことは想定されていません。既存のクラスタにインストールする場合や、Terraformで管理している場合は、CloudFormationの内容をTerraformコードに書き換える必要があります。
3.3 つまづきポイント
- IAMの設定が多くて複雑。Terraformへの変換漏れがあると当然インストールで失敗する
- Cluster Autoscalerからの移行はドキュメントにない情報がある
- SQSによるSpotインスタンスの中断制御周り
3.4 Cluster Autoscalerからの移行の戦略
Cluster Autoscalerからインプレースな移行はできます。移行する場合は、ノードグループの単位で、影響の少ないものから徐々に移行していくことでできました。
4. Karpenter運用編
4.1 Karpenterのしくみ
Karpenterの基本的なCustom Resourceは以下です:
- NodeClass:ノードが起動するためのuserdataを定義
- NodePool:ノードに付与するtag、taint、どのNodeClassを使うか、どのインスタンスタイプを使うかを定義
4.2 NodeClass
AMIは特定のタグがついているものの最新版を取ってくるようにしています。
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2023
amiSelectorTerms:
- tags:
role: my_eks_cluster # 👈これ
また、userdataでWazuhやSpegelの設定をしています。
4.3 NodePool
複数のNodePoolを作成し、weightを設定することで、Spotインスタンスを優先しつつ、取得できない場合はOn-Demandインスタンスを取得するようにしています。
% kubectl get nodepool -o wide
NAME NODECLASS NODES READY AGE WEIGHT CPU MEMORY
arm64-default default 78 True 30d 20 412 2907533476Ki
multi-default default 17 True 30d 10 76 517494820Ki
4.4 NodePool - disruption(中断制御)
NodePoolのdisruption。これはKarpenterの目玉機能です。設定することで、ノードの自動的な管理・コスト最適化をしてくれます。ちゃんとpodをdrainしてからノードを終了してくれるのでサービスへの影響が抑えられる設計になっています。disruptionの設計を怠ることでコストが上昇した経験も共有しました。
4.5 Karpenterで避けた方がよい設定
以下のような設定はKarpenterの設定と競合し、ノードの作成と中止を繰り返すような動作をすることがあるので避けるべきです:
- Pod側で凝ったスケジュールの設定
- DeploymentへのAvailability Zone分散とHost分散の同時設定
- Podを削除するアプリケーションとの組み合わせ
- Deschedulerとの同時設定
5. まとめ
- Karpenterは導入はちょっと複雑、導入できたら管理は簡単
- Spotインスタンスでのコスト最適化がこれひとつで完結する
- 運用からEC2インスタンスのコスト最適化が手離れする感覚が非常に良い
- まだまだまとまったノウハウがアウトプットされていない印象がある
- 特に日本語は!!
- 今のAWSの戦略をみると今後のスタンダードになることは間違いないので、気になっている人の参考になれば幸いです
登壇に関して
登壇後の懇親会では、「Karpenter気になっていたけれど、触れずにいた部分を網羅的に知れてよかった」「今日はKarpenterの発表が気になって現地に来た」といったコメントをいただけて嬉しかったです。また、冒頭にも書きましたがKarpenterを初めて知ったのはこのCloudNativeDaysで、ここでインプットした知識を同じイベントで還元できたのは感慨深いものがありましたし、スタッフの方も喜んでいただけたようでした。CNDS2025は5/23から開催です!私はオンラインで参加しますが、今後も知見を得ては還元するサイクルを回していきたいです。