このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

EKS オートモードでのコスト最適化

EKS オートモードでは、統合、ビンパッキング、適切なサイジングを通じてクラスターのコンピューティングコストが継続的に最適化されます。ただし、特定のワークロード設定では、これらの最適化を妨げられる場合があります。このトピックでは、コスト最適化の仕組み、コスト最適化を妨げるもの、コスト効率を維持するためにクラスターを設定する方法について説明します。

EKS オートモードによるコストの最適化方法

EKS オートモードでは、次のメカニズムを通じてコンピューティングコストが削減されます。

これらの最適化は、手動操作なしで継続的に実行されます。ただし、特定のポッドアノテーションと NodePool 設定により、統合の有効化が妨げられる場合があります。

組み込みノードプールとコストガードレール

組み込みの general-purpose ノードプールと system ノードプールでは、既にいくつかのコスト保護のためのデフォルトが適用されています。

組み込みノードプールのみを使用している場合は、既にこれらのガードレールによるメリットを得ています。インスタンスファミリーの除外とインスタンスサイズの制約に関するこのトピックのガイダンスは、これらの制限を継承しないカスタム NodePool を作成するときに最も関連します。

ただし、組み込みノードプールでも、以下のセクションは適用されます。

統合を防ぐもの

ノードの中断がワークロードの可用性要件に違反すると EKS オートモードで判断されると、統合が防がれます。次の設定では、統合が妨げられます。

do-not-disrupt 注釈

karpenter.sh/do-not-disrupt 注釈により、ノードで注釈付きポッドが実行されている限り、ノードを保持するように EKS オートモードに指示されます。これにより、ノードが十分に活用されていなくても、ノードが統合、置換、または終了されるのを防ぎきます。

metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

考慮すべき代替案:

ポッド中断の予算 (PDB)

maxUnavailable: 0 または minAvailable を現在のレプリカ数以上に設定する PDB により、影響を受けるポッドのすべての統合が効果的に防がれます。PDB を確認して、一度に少なくとも 1 つのポッドを中断できることを確認します。

NodePool の制限をコスト上限として使用する

NodePool の limits により、NodePool がプロビジョニングできるコンピューティングリソースの合計に絶対的な上限が設定されます。この制限に達すると、EKS オートモードによってその NodePool の新しいノードの起動が停止されます。これは、ポッドが保留中であっても行われます。

特に、無制限のスケーリングが適切でない非本番稼働、テスト、またはバーストのワークロードを処理する NodePool に対して、コストガードレールとして limits を使用します。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
  limits:
    cpu: "500"
    memory: 1000Gi

この例では、ci-runners NodePool はプロビジョニングするすべてのノードで合計 500 vCPU または 1000 GiB のメモリを超えることはできません。この制限を超えるポッドは、キャパシティが解放されるまで Pending 状態のままになります。

コスト管理のためにインスタンスファミリーを除外する

デフォルトの EKS オートモードでは、幅広いインスタンスタイプから選択することでスケジューリングの柔軟性が最大化されます。特殊なハードウェアを必要としないワークロードの場合は、コストの高いインスタンスタイプが起動されないようにインスタンスファミリーを制限します。

高速インスタンスを除外する

GPU またはアクセラレーターリソースをリクエストしないワークロードの場合は、高速インスタンスファミリーを NodePool から除外します。これにより、キャパシティの制約中に高速インスタンスが選択されるシナリオを回避できます。

spec:
  template:
    spec:
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]

コンピューティング最適化、汎用、メモリ最適化のカテゴリのみを指定することで、高速 (P、G、Inf、Trn) やその他の特殊なインスタンスファミリーを選択から除外できます。

インスタンスの選択がキャパシティの制約とどのように相互作用するか

EKS オートモードでは、通常のインスタンスの選択中は高速およびエキゾチックのインスタンスタイプの優先順位が下がります。ただし、持続的な起動障害が発生すると、EKS オートモードでは残りの使用可能なインスタンスタイプから起動され、ワークロードの可用性が優先されます。これは例えば、すべての優先インスタンスタイプで EC2 のサービスクォータが一時的に使い果たされた場合に発生します。

このフォールバック動作を防ぐには、ワークロードに必要なインスタンスカテゴリのみに NodePool 要件を明示的に制限します。優先タイプが使用できず、NodePool 設定で他のタイプが許可されていない場合、ポッドはコストの高いインスタンスにスケジュールされずに、Pending 状態のままになります。

インスタンスサイズを制約する

インスタンスファミリーの制限に加えて、NodePool 内の最大インスタンスサイズを制限できます。インスタンスサイズの制約により、統合できない単一ノードからのコストエクスポージャーが制限されます。例えば、do-not-disrupt 注釈によってブロックされたノードは、ワークロードが小さい場合でも縮小できません。

eks.amazonaws.com/instance-cpu ラベルを使用して、NodePool 要件の最大インスタンスサイズを制限します。

requirements:
  - key: "eks.amazonaws.com/instance-cpu"
    operator: Lte
    values: ["32"]

この設定により、EKS オートモードではこの NodePool で 32 vCPU を超えるインスタンスを起動できなくなります。

既存のクラスターで最適化の機会を特定するには、実行中の最大のインスタンスを確認します。大きなノードの統合が一貫して防がれている場合、そのアイドルキャパシティのノードあたりのコストは比例して高くなります。

バーストワークロードに推奨されるパターン

CI/CD パイプライン、バッチジョブ、エフェメラルランナーでは、コスト効率を維持するために特定の設定を必要とするバーストとアイドルのパターンが作成されます。

バーストワークロードに推奨されるデフォルト

例: CI ランナー NodePool

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: Lte
          values: ["32"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
  limits:
    cpu: "500"
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

この設定では、次のようになります。

ノードのライフサイクルとコスト

EKS オートモードでは、ノードが目的の仕様から逸脱した場合 (新しいオートモード AMI のリリース後など)、またはノードの有効期限が近づいた場合、グレースフルな中断によってノードが置き換えられます。グレースフルな置き換え中に、以下が行われます。

大規模なノードまたは多数のノードがあるクラスターの場合、この重複により定期的にコストが増加する可能性があります。影響を最小限に抑えるには、以下が必要です。

ノードのライフサイクルの詳細については、「Amazon EKS Auto Mode マネージドインスタンスについての説明」を参照してください。