すべてのプロダクト
Search

このプロダクト

    Container Compute Service:ハードウェア例外を持つインスタンスの自動ローテーションの構成

    ドキュメントセンター

    Container Compute Service:ハードウェア例外を持つインスタンスの自動ローテーションの構成

    最終更新日:Mar 04, 2026

    基盤となるインフラストラクチャでハードウェア例外が発生した場合、Alibaba Cloud Service (ACS) は Kubernetes イベントや条件などの方法を使用して報告します。詳細については、「GPU 障害診断と復旧」をご参照ください。サービス中断を回避するために、acs-instance-helper コンポーネントを構成して障害処理を有効にできます。この機能は、ワークロードのスケールアウトとエビクションを自動化し、運用保守効率を向上させ、サービス安定性を確保します。

    仕組み

    ACS インスタンスの基盤となるインフラストラクチャで、計画的な運用保守イベントや、損傷した GPU などのハードウェア障害が発生した場合、サービス安定性やパフォーマンスに影響を与えたり、ダウンタイムのリスクをもたらしたりする可能性があります。acs-instance-helper コンポーネントを構成することで、完全に自動化された障害処理を実現できます。

    1. 自動障害監視：コンポーネントは、Pod の障害 Condition を継続的にリッスンします。基盤となるインフラストラクチャは、GPU 障害、マシン全体の障害、計画的なノード再起動運用保守イベントなどのイベントに対して、このシグナルを自動的に報告します。

    2. アラインされたウィンドウ処理：コンポーネントは、基盤となるノードによって報告された障害処理期限と、オプションの運用保守ウィンドウ設定に基づいて処理時間を決定します。期限が許す場合、コンポーネントは事前設定された運用保守ウィンドウが開始されるまで待機してから処理を開始します。

    3. トリガーされたローテーション更新：コンポーネントは、Deployment や CloneSets などのステートレスアプリケーションに対して、オンライン スケールアウトポリシー (最初にスケールアウトし、次に破棄する) を自動的に使用して、障害のあるノード上の Pod のスムーズなローテーションを実行します。

      重要

      非オンラインアプリケーションの場合、acs-instance-helper は異常な状態を検出した後、インスタンスを直接エビクションします。

    適用範囲

    • ご利用の ACS クラスターのバージョンは 1.28 以降です。

    • ACK Virtual Node コンポーネントがインストールされており、そのバージョンは v2.16.0 以降です。詳細については、「ACK Virtual Node」をご参照ください。

    コンポーネントのインストール

    1. ACS コンソールで、対象のクラスター名をクリックします。 左側のナビゲーションウィンドウで、Applications > [Helm] を選択します。

    2. [Helm] ページで、[作成] をクリックします。

      1. 基本情報：[Chart] 検索ボックスに「acs-instance-helper」と入力し、検索結果から選択します。

      2. パラメーター：Chart Version には、最新バージョンを選択します。

    acs-instance-helper コンポーネントのグローバル設定の構成 (オプション)

    コンポーネントに対して、追加でサポートされるワークロードタイプと運用保守ウィンドウを構成できます。

    コンソール

    1. 対象クラスターの詳細ページの左側のナビゲーションウィンドウで、Configurations > ConfigMaps を選択します。

    2. ConfigMaps ページで、Create from YAML をクリックします。次に、以下のマニフェストを [Templates] エリアにコピーし、Create をクリックします。

    kubectl

    1. クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続します。

    2. 以下の YAML マニフェストを acs-instance-helper-global-configmap.yaml という名前のファイルとして保存します。次に、kubectl apply -f acs-instance-helper-global-configmap.yaml コマンドを実行します。

    apiVersion: v1
kind: ConfigMap
metadata:
  name: acs-instance-helper-global-config
  namespace: kube-system
data:
  customOnlineWorkloads: foo.io/SomeWorkload,bar.io/AnotherWorkload
  hardwareFaultEvictionSeconds: "60"
  maintenanceTime: "2025-10-09T10:00:00+08:00"
  maintenanceDuration: "4h"
  maintenanceWeeklyPeriod: "Saturday,Sunday"
  # maintenanceRecurrence: "FREQ=WEEKLY;BYDAY=SA,SU"  # 運用保守ウィンドウ：毎週土曜日と日曜日

    以下のセクションを展開して、設定項目の説明を表示します。

    設定項目の説明

    設定キー

    説明

    例の値

    customOnlineWorkloads

    アプリケーションを「オンライン サービス」タイプとしてマークし、障害が発生したノード上の Pod のスムーズなローテーションを実現するために、オンライン スケールアウト ポリシー（まずスケールアウトし、その後破棄）を使用します。

    コンポーネントは、デフォルトで Deployment ワークロードをサポートします。他のカスタムワークロードタイプのサポートを追加するには、この項目を設定します。

    重要

    • カスタムワークロードコントローラーが、数が不十分な場合に自動的に追加することで、Pod レプリカの数を維持できることを確認してください。

    • 障害発生時のロスレスローテーションは、すべてのカスタムワークロードで保証されるわけではありません。カスタムワークロードでこの機能を有効にする場合は、徹底的にテストしてください。

    foo.io/SomeWorkload,bar.io/AnotherWorkload

    hardwareFaultEvictionSeconds

    「スケールアウトとエビクション」ポリシーを使用するサービスの場合、これはスケールアウトの完了から障害のあるインスタンスのエビクションの開始までの待機時間 (秒単位) です。

    • デフォルト値は "300" (5 分) です。値は文字列形式である必要があります。たとえば、"60" です。

    "60"

    maintenanceTime

    RFC3339 形式で運用保守ウィンドウの開始時刻を定義します。この項目を構成すると、クラスターの運用保守ウィンドウが有効になります。

    +08:00 や UTC のような明確なタイムゾーン識別子を使用してください。

    2025-10-09T10:00:00+08:00

    運用保守ウィンドウが 2025 年 10 月 9 日午前 10 時 (UTC+8) に開始されることを宣言します。

    maintenanceDuration

    各運用保守ウィンドウの期間を指定します。

    • これは maintenanceTime が構成された後にのみ有効になります。

    • 値は文字列形式である必要があります。"3"、"3h"、"3H" などの形式がサポートされています。

    • デフォルト値は "3" で、これは 3 時間を意味します。

    "4h"

    maintenanceWeeklyPeriod

    どの曜日が運用保守日であるかを指定する簡略化された方法です。

    • これは maintenanceTime が構成された後にのみ有効になります。

    • 有効な値は Monday、Tuesday、Wednesday、Thursday、Friday、Saturday、および Sunday です。複数の値をコンマで区切ります。

    • この項目を構成すると、maintenanceRecurrence の値が上書きされます。

    Saturday,Sunday

    maintenanceRecurrence

    RFC5545 繰り返しルール構文を使用して運用保守サイクルを定義し、より高い柔軟性を提供します。

    • これは maintenanceTime が構成された後にのみ有効になります。

    • 現在、FREQ=WEEKLY のみがサポートされています。COUNT および UNTIL パラメーターはサポートされていません。

    • maintenanceWeeklyPeriod も構成されている場合、この項目は無視されます。

    FREQ=WEEKLY;BYDAY=SA,SU

    障害処理時間は、障害処理期限と構成された運用保守ウィンドウの両方によって決定されます。期限前に運用保守ウィンドウが利用可能な場合、acs-instance-helper コンポーネントは、そのウィンドウ内で障害修復を実行することを優先します。プロセス全体が単一の運用保守ウィンドウ内で完了しない場合、残りの操作は次の運用保守ウィンドウで継続されます。

    image

    ワークロードの作成と構成

    ワークロードのアノテーションを構成することで、障害処理機能を有効にできます。

    障害処理機能では、インスタンスを直接削除する代わりに、Eviction API を使用してエビクションを繰り返し試行することにより、インスタンスをローテーションします。エビクションの同時実行数を制御し、サービス中断を防止するために、PodDisruptionBudget（PDB） ポリシーを設定できます。詳細については、「PDB リソースを使用した Pod のエビクション同時実行数の制御」をご参照ください。

    コンソール

    1. 対象クラスターの左側のナビゲーションウィンドウで、Workloads > Deployments を選択します。

    2. Deployments ページで、Create from YAML をクリックします。以下の内容を [Template] エリアにコピーし、Create をクリックします。

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: hardware-fault-helper-example
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hardware-fault-helper-example
  template:
    metadata:
      labels:
        app: hardware-fault-helper-example
      annotations:
        # Key annotation: Enables the fault handling feature for the workload
        # キーアノテーション：ワークロードの障害処理機能を有効にします
        "ops.alibabacloud.com/enable-hardware-fault-helper": "true"
    spec:
      containers:
        - image: registry-cn-hangzhou.ack.aliyuncs.com/dev/hello-world:v1
          name: main-container
          resources:
            limits:
              cpu: 100m
              memory: 100Mi
      restartPolicy: Always

    3. ポップアップウィンドウで、対象のステートレスアプリケーションを見つけて ビュー をクリックします。Pod ステータスが Running であることを確認します。

    kubectl

    1. 以下の YAML コンテンツを `app.yaml` という名前のファイルとして保存し、`kubectl apply -f app.yaml` コマンドを実行します。

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: hardware-fault-helper-example
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hardware-fault-helper-example
  template:
    metadata:
      labels:
        app: hardware-fault-helper-example
      annotations:
        # Key annotation: Enables the fault handling feature for the workload
        # キーアノテーション：ワークロードの障害処理機能を有効にします
        "ops.alibabacloud.com/enable-hardware-fault-helper": "true"
    spec:
      containers:
        - image: registry-cn-hangzhou.ack.aliyuncs.com/dev/hello-world:v1
          name: main-container
          resources:
            limits:
              cpu: 100m
              memory: 100Mi
      restartPolicy: Always

    2. 対象アプリケーションの Pod ステータスが Running であることを確認します。

      kubectl get pods -l app=hardware-fault-helper-example

    エラーシナリオのシミュレーションと結果の観察

    実際のシナリオでは、基盤となる制御システムが自動的に Condition を追加します。ここでは、Pod の 1 つに手動で Condition を挿入することにより、エラー シナリオをシミュレートします。

    1. エラーのシミュレート: POD_NAME を実際の Pod 名に置き換えて、宛先 Pod にハードウェアエラー Condition を注入します。

      エラー処理期限は、message フィールドで指定された時間です。
      kubectl patch pod POD_NAME --type='merge' --subresource=status -p='{
  "status": {
    "conditions": [
      {
        "type": "Interruption.HardwareFault",
        "status": "True",
        "reason": "MockForTest",
        "message": "Underlying infrastructure issue [Reboot] scheduled at 2099-03-12T09:00:00.000+08:00",
        "lastProbeTime": "'$(date -u +"%Y-%m-%dT%H:%M:%SZ")'",
        "lastTransitionTime": "'$(date -u +"%Y-%m-%dT%H:%M:%SZ")'"
      }
    ]
  }
}'

    2. スケールアウトの観察：エラーが注入されると、`acs-instance-helper` は O&M ウィンドウ構成 に基づいてスケールアウトをトリガーします (構成が存在しない場合は即座にトリガーします)。新しい Pod が作成され、元のワークロードのステータスは影響を受けません。

      kubectl get pods -l app=hardware-fault-helper-example

      想定される出力：

      NAME                                             READY   STATUS    RESTARTS   AGE
hardware-fault-helper-example-7cf4cf96c5-xxxxx   1/1     Running   0          2m21s
hardware-fault-helper-example-7cf4cf96c5-yyyyy   1/1     Running   0          36s # 新しくスケールアウトされた Pod

    3. スケールアウト イベントの表示: 障害が発生した Pod のイベントを確認します。NewInstanceCreationTriggered イベントが確認でき、これはスケールアウト操作が hardware-fault-helper によってトリガーされたことを示しています。

      kubectl describe po POD_NAME

      想定される出力：

      ...
  Normal  NewInstanceCreationTriggered  62s    hardware-fault-helper  controller default/hardware-fault-helper-example-7cf4cf96c5 (apiVersion:apps/v1, kind:ReplicaSet) will create a new instance

    4. エビクションイベントの確認: hardwareFaultEvictionSeconds で指定された時間が経過すると、障害のある Pod はオフラインになります (Terminating 状態になり、その後削除されます)。このとき、オフラインイベントを確認することもできます。

      kubectl describe po POD_NAME

      想定される出力：

      ...
  Warning  InstanceEvictedGracefully     2s     hardware-fault-helper  pod is deleted due to hardware fault
  Normal   Killing                       1s     kubelet                Stopping container main-container

    5. 回復の確認：最終的に、エラーが発生した Pod は完全に置き換えられ、新しく作成された Pod のみが残ります。

      kubectl get pods -l app=hardware-fault-helper-example

      想定される出力：

      NAME                                             READY   STATUS      RESTARTS   AGE
hardware-fault-helper-example-7cf4cf96c5-yyyyy   1/1     Running     0          5m5s

    課金

    acs-instance-helper コンポーネントをインストールすると、ご利用のクラスターに 2 つのレプリカを持つデプロイメントが作成されます。各レプリカには 1 vCPU と 2 GiB のメモリが割り当てられます。これらのリソースはご利用のクラスターから消費され、料金が発生します。課金の詳細については、「ACS コンピューティングパワーの課金」をご参照ください。

    よくある質問

    PDB リソースによる Pod エビクションの同時実行性の制御

    ノードのドレインや自動スケールインなどの外部イベントにより Pod をエビクションする必要がある場合、PodDisruptionBudget (PDB) ポリシーを設定して、サービスの可用性を確保できます。このポリシーは、以下のパラメーターを使用してエビクションの同時実行性をコントロールします。

    • maxUnavailable：エビクションプロセス中に利用不可にできる Pod の最大数を定義します。

    • minAvailable：エビクションプロセス中に利用可能な状態を維持する必要がある Pod の最小数を定義します。

    次の例では、エビクション中に少なくとも 1 つの Pod が利用可能な状態を維持することを保証します。

    apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
  namespace: YOUR_NAMESPACE # ポリシーが有効になる名前空間を指定します。指定しない場合、デフォルトは 'default' になります。
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: app