Karpenterの最適化：効率とコストを両立させる方法

Karpenterは、Kubernetesのリソース効率を管理するために設計されたKubernetesネイティブのオートスケーラーです。保留中のワークロードに応じてノードを動的にプロビジョニングし、アプリケーションが必要とするリソースを、必要なタイミングで確実に利用できるようにします。これにより、運用効率を高め、クラウド支出を削減することを目指します。

しかし、Karpenterで効率とコスト効率を両立させるのは簡単ではありません。Karpenterは強力な機能を備えていますが、デフォルト設定や推奨ベストプラクティスの一部は、パフォーマンスを向上させる一方で、意図せずコストの増加を招くことがあります。そのため、一般的なガイドラインに従うだけでなく、自社のワークロードの要件やコスト面の事情に合わせて調整することが重要です。

本記事では、Karpenterの概要とアーキテクチャ、コストと効率のためのベストプラクティスを解説し、最後に「ベストプラクティスは環境に合わせて調整すべき」という私たち自身の実体験を共有します。

Karpenterを最適化するためのベストプラクティス

Karpenterを最適化するためのベストプラクティスを見ていきましょう。

1. ノード有効期限の設定: expireAfterパラメータを設定して、ノードが定期的に置き換えられ、最新のセキュリティパッチやパフォーマンス改善が反映されるようにしましょう。この予防的なアプローチにより、長期的なドリフトや潜在的な脆弱性のリスクを低減できます。セキュリティとコスト効率のバランスを取るため、ワークロードの種類に応じた適切な有効期限を設定することが重要です。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: nodepool
spec:
  template:
    spec:
      expireAfter: 168h # 7 days

2. Termination Grace Periodの設定: terminationGracePeriodパラメータは、Karpenterがノードを強制終了する前にドレインを待つ最大時間を定義します。この猶予期間を適切に設定することで、Podが正常に終了するための十分な時間の確保と、コスト削減のためにノードを速やかに入れ替えることのバランスが取れます。短くしすぎると突然の終了によってワークロードが不安定になるリスクがあり、逆に長すぎるとコスト削減が遅れます。環境に応じて猶予期間を算出することをおすすめします。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: nodepool
spec:
  template:
    spec:
      terminationGracePeriod: 30m

3. karpenter.sh/do-not-disruptアノテーションの活用: 統合処理中に重要なPodが退避されるのを防ぐため、このアノテーションを適用しましょう。重要なワークロードを保護できる一方で、多用すると定期的な更新時にノードの削除がブロックされ、リソースの無駄につながります。このアノテーションは、本当に重要な短時間のプロセスやインタラクティブなジョブに限定し、どうしても必要な場合を除き、長時間稼働するステートフルサービスへの適用は避けるべきです。

apiVersion: v1
kind: Node
metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"  #Node -Level Control

4. Pod Disruption Budget（PDB）の適用: PDBは、中断時に維持すべき最小Pod数を指定することで、ノード中断イベント中のアプリケーションの可用性を確保します。PDBを設定する際は、ワークロードのSLA（サービスレベル契約）に基づいてminAvailableとmaxUnavailableのいずれかを選択する必要があります。PDBをKarpenterと組み合わせることで、ノードの正常なドレインを可能にし、ダウンタイムを最小限に抑えられます。また、有効性を維持するため、オートスケーリングの変化を反映してPDBを定期的に更新すべきです。

5. NodePoolの構成とレイヤー化された制約: ワークロードごとに最適化されたNodePoolを設計することで、リソース使用率と耐障害性を高められます。たとえば、ステートフルとステートレスのワークロードでNodePoolを分けることで、インスタンスタイプの選択を最適化できます。また、ノードセレクター、アフィニティ、tolerationを活用してスケジューリングをさらに細かく制御し、耐障害性を損なうことなくワークロードを適切なノードに配置できます。

6. コスト最適化のための統合ポリシー: Karpenterの統合機能は、使用率の低いノードを特定し、ワークロードをより少ないノードに集約することでリソース使用を最適化します。このプロセスは、効率的なビンパッキングとリソース集約によるコスト削減につながります。ただし、統合中に発生しうる中断と、コスト削減や運用効率向上のメリットとのバランスを取ることが重要です。

7. SpotインスタンスとOn-Demandインスタンスのバランス: SpotとOn-Demandインスタンスを組み合わせることで、重要なコンポーネントの安定性を確保しながらコストメリットを活かせます。Savings Plansのcommitmentsに合わせて、適切な重み付けとインスタンス数の上限でNodePoolを設定しましょう。この戦略により、重要なワークロードの信頼性を損なうことなくコストを最適化できます。

私たちの体験談：ベストプラクティスが裏目に出たとき

                                                                                                                                                                                                                                                                                                                                                                         - 執筆：[Olexandr Veleten](https://www.linkedin.com/in/aleksandr-veleten/)

私たちは、Karpenterが推奨するベストプラクティスに従って運用してきました。ノードにはexpireAfterパラメータを設定し、定期的なローテーションを確保していました。

重要なワークロードには、統合処理中の中断を防ぐためにkarpenter.sh/do-not-disruptアノテーションを適用しました。理屈の上では、このアプローチは完璧に見えました。

ノードが有効期限に達すると、Karpenterは想定どおり新しいノードのプロビジョニングを開始しました。しかしここで問題が発生しました。do-not-disruptアノテーションによってホストしている重要なPodの退避が妨げられたため、既存のノードを終了できなかったのです。その結果、古いノードと新しいノードが一時的に同時稼働する状態となり、キャパシティが実質的に2倍に、そして必然的にコストも2倍になってしまいました。

これに対処するため、terminationGracePeriodパラメータを設定しました。これは、強制終了までにノードのドレインに許容される最大時間を定義するものです。このパラメータによりノードは最終的に廃止されますが、新たな課題も生じます。Pod Disruption Budget（PDB）が適切に設定されていない状態で複数のステートフルノードが同時に終了されると、クラスタの安定性が損なわれる恐れがあるのです。

こうした複雑さを踏まえ、ステートフルなワークロードについてはexpireAfter設定を無効にすることにしました。代わりに、計画されたメンテナンスウィンドウ中、またはおよそ半年ごとのKubernetesアップグレードに合わせて、これらのノードを手動で更新する方針を選びました。このアプローチにより、ノードのライフサイクルイベントを自分たちでコントロールでき、コスト効率とクラスタの安定性の両方を確保できました。

この経験から得た重要な教訓は、ベストプラクティスは貴重な指針ではあるものの、万能の解決策ではないということです。 ワークロードと運用環境の固有の要件に合わせて構成を評価・調整することが不可欠です。そうすることで、予期せぬ結果を招くことなく、Karpenterのようなツールの潜在能力を最大限に引き出せます。

KarpenterとCluster Autoscalerの比較

Karpenterは、Kubernetesクラスタのスケーリングに対するよりモダンで柔軟なアプローチであり、より高速なプロビジョニングと効率的なリソース利用を実現します。ワークロード要件が変動する動的な環境に特に適しています。一方、Cluster Autoscalerはより成熟したソリューションで、事前定義されたノードグループとの相性が良く、幅広いクラウドプロバイダーをサポートしています。より静的な環境や、複数のクラウドプロバイダーを利用する場合には信頼できる選択肢です。

>> スマートなPodのライトサイジングでKarpenterを最大限に活用する方法はこちらをご覧ください。

PerfectScaleでKarpenterを最大限に活用する

KarpenterとPerfectScaleを組み合わせることで、Kubernetesクラスタの効率を大幅に高められます。Karpenterはインテリジェントなジャストインタイムのノードプロビジョニングを提供しますが、ワークロードの過去のリソース使用状況や信頼性要件に対する深い洞察は不足しがちです。PerfectScaleはワークロードのパターンを分析し、最適化の推奨事項を提供することでこのギャップを埋めます。この相乗効果により、Karpenter単体で得られる効果に加えて、さらに30〜50%のコスト削減を実現したお客様もいます。たとえばPerfectScaleは、Karpenterがリソースを過剰にプロビジョニングする可能性のあるシナリオを特定し、不要なコストや信頼性への影響を防ぐ構成を提案できます。PerfectScaleを試して、Karpenterで管理するクラスタをどのように強化できるかをぜひご確認ください。サインアップまたはデモを予約して詳細をご覧ください。