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

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

EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する

キャパシティ予約へのワークロードのデプロイを制御できます。EKS 自動モードは、EC2 オンデマンドキャパシティ予約 (ODCR)、EC2 Capacity Blocks for ML、および中断可能なキャパシティ予約 (IODCR) をサポートしています。

EC2 オンデマンドキャパシティ予約 (ODCR)

EC2 オンデマンドキャパシティ予約 (ODCR) を使用すると、任意の期間中に特定のアベイラビリティーゾーンで Amazon EC2 インスタンスのコンピューティングキャパシティを予約できます。EKS Auto Mode を使用するとき、Kubernetes ワークロードをこれらの予約されたインスタンスにデプロイするかどうかを制御し、事前購入された容量の使用率を最大化したり、重要なワークロードが保証されたリソースにアクセスできるようにしたりすることができます。

デフォルトでは、EKS Auto Mode は自動的にオープン ODCR として起動します。ただし、NodeClass で capacityReservationSelectorTerms を設定することで、ワークロードが使用する ODCR を明示的に制御できます。設定された ODCR を使用してプロビジョニングされたノードには karpenter.sh/capacity-type: reserved があり、オンデマンドおよびスポットよりも優先されます。この機能を有効にすると、EKS Auto Mode はオープン ODCR を自動的に使用しなくなります。NodeClass で明示的に選択する必要があり、クラスター全体のキャパシティ予約の使用状況を正確に制御できます。

NodeClass の例

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
  # Optional: Selects upon on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        app: "my-app"
      # Optional owning account ID filter
      owner: "012345678901"

この NodeClass の例では、ODCR を選択するための 2 つのアプローチが示されています。1 番目の方法では、特定の ODCR が ID (cr-56fac701cc1951b03) で直接参照されます。2 番目の方法ではタグベースの選択を使用し、タグ Name: "targeted-odcr" で ODCR がターゲットされます。オプションとして、予約を所有する AWS アカウントでフィルタリングすることもできます。アカウント間シナリオや共有キャパシティ予約を使用する場合に特に便利です。

キャパシティ予約のスケジューリングラベル

NodeClass で capacityReservationSelectorTerms を設定すると、キャパシティ予約からプロビジョニングされたノードには追加のスケジューリングラベルが付けられます。これらのラベルを NodePool 要件またはポッドスケジューリング制約 (ノードアフィニティなど) として使用して、ワークロードの配置を制御できます。

これらのラベルは、karpenter.sh/capacity-type: reserved を持つノードにのみ存在します。

中断可能なキャパシティ予約 (IODCR)

中断可能なキャパシティ予約を使用すると、未使用のオンデマンドキャパシティ予約キャパシティを組織内の他のワークロードと共有できます。未使用のキャパシティを中断可能な ODCR として再利用することで、バッチ処理やデータ分析など、柔軟で耐障害性のあるオペレーションに適したワークロードは、一時的に利用可能なキャパシティのメリットを得ることができます。予約所有者はいつでもキャパシティを再利用できますが、中断可能な ODCR のコンシューマーは、ノードが終了する前に正常なシャットダウンまたはチェックポイントを可能にするために、終了前に中断通知を受け取ります。

中断可能なキャパシティ予約を、ID またはタグで、標準の ODCR と同じ方法で、capacityReservationSelectorTerms を使用して選択します。ワークロードが中断可能なリザーブドキャパシティと中断不可能なリザーブドキャパシティのどちらでスケジュールされるかを制御するには、eks.amazonaws.com/capacity-reservation-interruptible スケジューリングラベルを使用します。

キャパシティが再利用されると、実行中のインスタンスは EventBridge イベントを通じて 2 分間の中断警告を受け取ります。通知期間後、再利用されたキャパシティで実行中のインスタンスはシャットダウン状態になり、終了します。EKS Auto Mode は、2 分間の中断警告を受け取ると、中断可能なキャパシティ予約から起動されたノードのドレインを自動的に開始し、ノードが再利用される前にワークロードを適切に終了できるようにします。

EC2 Capacity Blocks for ML

Capacity Blocks for ML は、短期間の機械学習ワークロードをサポートするため、GPU ベースの高速コンピューティングインスタンスを将来の日付で予約します。キャパシティブロック内で実行されるインスタンスは、Amazon EC2 UltraClusters 内に自動的に互いに近く配置され、低レイテンシーでペタビットスケールのノンブロッキングネットワーキングを実現します。

サポートされているプラットフォームとインスタンスタイプの詳細については、「EC2 ユーザーガイド」の「Capacity Blocks for ML」を参照してください。

前述の ODCR と同じく、EKS 自動モードの NodeClass を作成し、その中で Capacity Block for ML を使用できます。

次のサンプル定義では、3 つのリソースを作成しています。

NodeClass の例

この NodeClass は、特定の Capacity Block for ML をその予約 ID で参照します。この ID は、EC2 コンソールから取得できます。

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: gpu
spec:
  # Specify your Capacity Block reservation ID
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03

詳細については、「Amazon EKS のノードクラスを作成する」を参照してください。

NodePool の例

この NodePool は、gpu NodeClass を参照し、以下の重要な設定を指定します。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: gpu
      requirements:
        - key: eks.amazonaws.com/instance-family
          operator: In
          values:
            - g6
            - p4d
            - p4de
            - p5
            - p5e
            - p5en
            - p6
            - p6-b200
        - key: karpenter.sh/capacity-type
          operator: In
          values:
            - reserved
            # Enable other capacity types
            # - on-demand
            # - spot
      taints:
        - effect: NoSchedule
          key: nvidia.com/gpu

詳細については、「EKS 自動モードl 用のノードプールを作成する」を参照してください。

ポッドの例

この例に示したポッドは、キャパシティブロックノードで動作するようにワークロードを設定する方法を示しています。

apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
spec:
  nodeSelector:
    # Select specific GPU type - uncomment as needed
    # eks.amazonaws.com/instance-gpu-name: l4
    # eks.amazonaws.com/instance-gpu-name: a100
    eks.amazonaws.com/instance-gpu-name: h200
    # eks.amazonaws.com/instance-gpu-name: b200
    eks.amazonaws.com/compute-type: auto
  restartPolicy: OnFailure
  containers:
  - name: nvidia-smi
    image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
    args:
    - "nvidia-smi"
    resources:
      requests:
        # Uncomment if needed
        # memory: "30Gi"
        # cpu: "3500m"
        nvidia.com/gpu: 1
      limits:
        # Uncomment if needed
        # memory: "30Gi"
        nvidia.com/gpu: 1
  tolerations:
  - key: nvidia.com/gpu
    effect: NoSchedule
    operator: Exists

詳細については、Kubernetes ドキュメントの「ポッド」を参照してください。

関連リソース