Container Service for Kubernetes:スポットインスタンスの使用

前提条件

基本概念

• スポットインスタンス

  スポットインスタンスは、コスト効率が高く、プリエンプション（強制終了）可能なコンピューティングインスタンスです。Alibaba Cloud のアイドル状態の計算容量に対して入札を行い、コンテナを実行できます。このインスタンスは、入札価格が現在の市場価格を下回った場合、または在庫不足によりリソースが再割り当てされた場合に終了します。スポットインスタンスの詳細については、「スポットインスタンスとは？」をご参照ください。

• Knative

  Knative は、クラウドネイティブ・クロスプラットフォームのサーバーレスアプリケーションオーケストレーションの標準を確立することを目的としています。主な特徴には、リクエストベースのオートスケーリング、ゼロスケール、マルチバージョン管理、トラフィックベースのカナリアリリース、関数デプロイメント、およびイベント駆動型アーキテクチャが含まれます。Knative の詳細については、「ACK Knative の概要」および「ACK Serverless Knative の概要」をご参照ください。

仕組み

Knative では、サーバーレスワークロードは主に Knative Service を通じて管理され、着信リクエストに基づいて Pod が自動的にスケーリングされます。スポットインスタンスを利用するには、特定の Pod アノテーションを設定するだけで済みます。仮想ノードは、Pod アノテーションに基づいて対応する Elastic Container Instance (ECI) のリソース仕様を自動的にプロビジョニングします。また、仮想ノードはスポットインスタンスの自動的な置き換えも提供するため、利用がさらに自動化されます。

Knative とスポットインスタンスを組み合わせるメリットは以下のとおりです：

• サーバーレスシナリオに最適：短期間のウェブリクエストなど、必要に応じてリソースを動的に使用し、処理完了後に即座に解放するタスクに適しており、長期的なリソース割り当てを回避できます。

• グレースフルシャットダウンとの自然な連携：このプロセスではアプリケーションがグレースフルシャットダウンをサポートする必要がありますが、Knative は各 Pod に queue-proxy サイドカーコンテナを挿入することでこれを支援します。Pod が終了される際、queue-proxy コンテナはまずすべてのアクティブなリクエストの完了を待ってから、アプリケーションコンテナをシャットダウンします。

• コスト効率が高い：コスト意識の高い Knative ユーザーにとって、スポットインスタンスの利用は大幅なコスト削減を実現します。

構成と例

スポットインスタンスの構成

Knative Service の Pod テンプレートに、以下のアノテーションを追加してスポットインスタンスを構成します。

例 1：SpotWithPriceLimit 戦略の使用

以下の YAML 例では、ecs.c6 インスタンスタイプのスポットインスタンスを作成します。

• 作成時に、指定されたインスタンスタイプおよび価格上限を満たす在庫が存在しない場合、作成は失敗します。

• 作成後、インスタンスは保証された 1 時間の保護期間中実行されます。この期間が終了すると、市場価格が入札価格を上回った場合や、指定インスタンスタイプの在庫が不足した場合に、スポットインスタンスが再割り当てされます。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      labels:
        alibabacloud.com/eci: "true"
      annotations:
        k8s.aliyun.com/eci-use-specs : "ecs.c6.large"           # ECS インスタンスタイプを指定します。
        k8s.aliyun.com/eci-spot-strategy: "SpotWithPriceLimit"  # カスタム価格上限を設定する戦略を使用します。
        k8s.aliyun.com/eci-spot-price-limit: "0.25"            # 最大時間単位価格を設定します。
    spec:         
      containers:
      - env:
        - name: TARGET
          value: "Knative"
        image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

例 2：オンデマンドインスタンスへの自動フォールバックの有効化

以下の YAML 例では、ecs.c6 インスタンスタイプのスポットインスタンスを作成します。

• 作成時に、指定されたインスタンスタイプおよび価格上限を満たす在庫が存在する場合、スポットインスタンスが作成されます。このインスタンスは保証された 1 時間の保護期間中実行されます。この期間が終了すると、市場価格が入札価格を上回った場合や、指定インスタンスタイプの在庫が不足した場合に、スポットインスタンスが再割り当てされます。

• 作成時に、指定されたインスタンスタイプおよび価格上限を満たす在庫が存在しない場合、代わりにオンデマンドインスタンスが作成されます。このインスタンスはシステムによって自動的に再割り当てされることはありません。インスタンス作成後、kubectl describe pod コマンドを実行して Pod の Events を確認できます。SpotDegraded Event が表示された場合、Pod はオンデマンドインスタンスへダウングレードされています。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      labels:
        alibabacloud.com/eci: "true" 
      annotations:
        k8s.aliyun.com/eci-use-specs : "ecs.c6.large"           # ECS インスタンスタイプを指定します。
        k8s.aliyun.com/eci-spot-strategy: "SpotWithPriceLimit"  # カスタム価格上限を設定する戦略を使用します。
        k8s.aliyun.com/eci-spot-price-limit: "0.05"             # 最大時間単位価格を設定します。
        k8s.aliyun.com/eci-spot-fallback: "true"                # スポット在庫が不足した場合に、自動的にオンデマンドインスタンスへフォールバックします。
    spec:         
      containers:
      - env:
        - name: TARGET
          value: "Knative"
        image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

ステップ 1：スポットインスタンスの構成

計算リソースのコストを最小限に抑えるために、Knative Service に k8s.aliyun.com/eci-spot-strategy アノテーションを追加できます。この構成により、オンデマンドインスタンスと比較して低価格で提供される ECI スポットインスタンスの利用が優先されます。

ただし、市場価格が入札価格を上回った場合や在庫が不足した場合にスポットインスタンスが再割り当てされ、サービス中断が発生する可能性があります。業務継続性を維持するため、k8s.aliyun.com/eci-spot-fallback: "true" アノテーションも併せて追加できます。この設定により、スポットインスタンスがリソース不足により利用不可となった場合、Knative Service は自動的にオンデマンドインスタンスへフォールバックし、サービスの安定性と信頼性を確保します。このアプローチは、コスト削減と高可用性の両立を実現します。

1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。

2. クラスターリスト ページで、クラスター名をクリックします。左側のナビゲーションウィンドウで、アプリケーション > Knative をクリックします。

3. [Knative] ページで、[サービス管理] タブをクリックします。[名前空間] ドロップダウンリストから [デフォルト] を選択し、[テンプレートで作成] をクリックします。[サンプルテンプレート] ドロップダウンリストで、[カスタム] を選択します。次のサンプルコードをエディターに貼り付けて、[作成する] をクリックして、helloworld-go という名前の Knative サービスを作成します。

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: helloworld-go
   spec:
     template:
       metadata:
         labels:
           alibabacloud.com/eci: "true" 
         annotations:
           k8s.aliyun.com/eci-use-specs : "ecs.c6.large"           # ECS インスタンスタイプを指定します。
           k8s.aliyun.com/eci-spot-strategy: "SpotAsPriceGo"       # 市場価格に従う戦略を使用します。
           k8s.aliyun.com/eci-spot-duration: "1"                   # 保護期間を設定します。デフォルトは 1 時間です。インスタンス作成時に異なる期間を指定できます。
           k8s.aliyun.com/eci-spot-fallback: "true"                # スポット在庫が不足した場合に、自動的にオンデマンドインスタンスへフォールバックします。
       spec:         
         containers:
         - env:
           - name: TARGET
             value: "Knative"
           image: registry-vpc.{REGION-ID}.aliyuncs.com/knative-samples/helloworld-go:160e4dc8 # {REGION-ID} をご利用のクラスターが展開されているリージョン ID（例：cn-hangzhou）に置き換えてください。

   上記の YAML 例では、ecs.c6 インスタンスタイプのスポットインスタンスを作成します。

   • 作成時に、指定インスタンスタイプのスポット在庫が不足している場合、代わりにオンデマンドインスタンスが作成されます。

   • 作成後、インスタンスは保証された 1 時間の保護期間中実行されます。この期間中は、市場価格が入札価格を上回ったとしても、インスタンスは再割り当てされません。保護期間終了後、市場価格が入札価格を上回った場合や在庫が不足した場合に、Alibaba Cloud によりスポットインスタンスが自動的に再割り当てされる可能性があります。コントローラーが再割り当てられた Pod を置き換える際、k8s.aliyun.com/eci-spot-fallback: "true" 設定により、スポット在庫が不足していた場合には新しいオンデマンドインスタンスが作成され、サービス可用性が維持されます。

（任意）ステップ 2：スポットインスタンスのグレースフルシャットダウンの構成

期限切れのスポットインスタンスに対するグレースフルハンドリングの構成

ECI スポットインスタンスの再割り当てによる業務障害を最小限に抑えるため、仮想ノードは構成可能なグレースフルシャットダウン機能を提供します。スポット Pod にアノテーション k8s.aliyun.com/eci-spot-release-strategy: api-evict を追加できます。仮想ノードが SpotToBeReleased Event を受信すると、Eviction API を呼び出してスポットインスタンスを強制終了します。API 経由の強制終了は、お客様が設定した PodDisruptionBudgets および terminationGracePeriodSeconds を尊重します。Eviction オブジェクトを API 経由で作成することは、ポリシー制御された Pod の DELETE 操作を実行することと同等です。

1. API 呼び出し：仮想ノードが SpotToBeReleased イベントを受信すると、Eviction API を呼び出します。

2. PDB の確認：API サーバーが、強制終了対象の Pod に設定された PDB を確認します。

3. 強制終了の実行：API サーバーが強制終了要求を検証した後、以下の手順で Pod を強制終了します：

   1. Pod は削除タイムスタンプを更新し、API サーバーが終了対象の Pod を認識できるようにします。また、お客様が設定した猶予期間が付与されます。

   2. Pod が実行されている仮想ノードの kubelet が Pod を認識し、グレースフルシャットダウンを開始します。

   3. kubelet が Pod を終了する際、クラスターのコントロールプレーンは、Pod を関連する Endpoints および Endpointslices から切り離します。この時点で、Pod コントローラーはその Pod を有効なものとして認識しなくなります。

   4. 猶予期間が終了すると、kubelet が Pod を強制終了します。

   5. kubelet がシステムに Pod の削除を通知します。

   6. API サーバーが Pod を削除します。

4. Knative 環境では、Knative Service によって管理される各 Pod には queue-proxy サイドカーコンテナが含まれています。Pod が削除される際、queue-proxy はすべての進行中のリクエストの完了を待ってから、アプリケーションコンテナを停止します。このプロセスにより、スケールダウンや更新がスムーズに行われます。

関連ドキュメント

アプリケーションがコールドスタート遅延に敏感な場合、リザーブドインスタンス機能の利用を検討してください。これにより、コストと起動時間のバランスを取るために、低スペックのバースト可能パフォーマンスインスタンスを維持できます。詳細については、「リザーブドインスタンスの構成」をご参照ください。