すべてのプロダクト
Search
ドキュメントセンター

Elastic Container Instance:Pod の障害処理ポリシーの構成

最終更新日:May 28, 2025

デフォルトでは、Elastic Container InstanceベースのPodの作成に失敗した場合、システムは自動的にPodの再作成を再試行します。作成結果を迅速に取得し、できるだけ早く障害を処理したい場合は、Podの障害処理ポリシーを変更できます。

構成の説明

リソース不足が原因で、仮想ノード上にPodを作成できない場合があります。デフォルトでは、システムは自動的にリソースの再スケジュールを行い、Podの再作成を試みます。 k8s.aliyun.com/eci-fail-strategy アノテーションを追加して、Podの障害処理ポリシーを設定し、Podの作成に失敗した場合にPodを再作成するかどうかを指定できます。

重要
  • アノテーションは、Pod の構成ファイル内のメタデータに追加する必要があります。たとえば、Deployment を作成する場合は、spec.template.metadata セクションにアノテーションを追加する必要があります。

  • Elastic Container Instance の機能を使用するには、Elastic Container Instance ベースの Pod を作成するときにのみアノテーションを追加できます。Pod の更新時にアノテーションを追加または変更しても、これらのアノテーションは有効になりません。

次の表に、k8s.aliyun.com/eci-fail-strategy アノテーションの有効な値を示します。

説明

シナリオ

fail-back

Podの作成に失敗した後、システムは自動的にPodの再作成を試みます。Podは、正常に再作成されるまでPending状態のままです。Podが再作成されると、Podの状態はRunning状態に変わります。

高い成功率が必要で、Podの配信の遅延を許容できます。

fail-over

fail-overとfail-backの効果は同じです。

fail-fast

Podの作成に失敗した後、システムは直接エラーを報告します。PodはProviderFailed状態になります。上位層のオーケストレーションは、システムがPodの再作成を再試行するか、Podを実際のノードにスケジュールするかを決定します。

高い効率が必要で、Podを迅速に配信したいと考えています。システムは最適化された障害処理ロジックを提供します。

説明
  • k8s.aliyun.com/eci-fail-strategy: "fail-fast" アノテーションが Elastic Container Instance ベースの Pod の構成ファイル内のメタデータに追加されている場合、動的にプロビジョニングされたディスク ボリュームが Pod にマウントされているとき、プロビジョナーは WaitForFirstConsumer StorageClass をサポートしません。

  • k8s.aliyun.com/eci-reschedule-enable アノテーションを使用して再スケジュールを構成することはお勧めしません。

構成例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  labels:
    app: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-test
      labels:
        app: nginx
        alibabacloud.com/eci: "true" 
      annotations:
        k8s.aliyun.com/eci-fail-strategy: "fail-fast" # Podの作成に失敗した場合、システムはPodの再作成を試みずに直接エラーを報告します。
        k8s.aliyun.com/eci-use-specs: "ecs.c6.large"
    spec:
      containers:
      - name: nginx
        image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
        ports:
        - containerPort: 80

上記のYAMLファイルの例では、Podの障害処理ポリシーはfail-fastです。PodがPending状態のまま長時間経過する場合は、pod status.reasonを確認できます。

  • pod status.reasonがContainerInstanceScheduleFailedの場合、Podのスケジュールに失敗しています。この場合、ContainerInstanceCreated条件を表示し、条件のreasonとmessageに基づいて原因を特定できます。その後、Podの仕様の変更や複数ゾーンの構成など、適切な対策を講じてPodを作成できます。詳細については、ContainerInstanceCreatedを参照してください。

  • pod status.reasonが空の場合、ContainerInstanceCreated条件を表示し、条件の値に基づいてスケジューリング状態を確認できます。ほとんどの場合、障害処理ポリシーがfail-fastの場合、pod status.reasonは空ではありません。

    • ContainerInstanceCreatedの値がTrueの場合、Podは正常にスケジュールされていますが、サンドボックスの作成中に例外が発生しています。

    • ContainerInstanceCreatedの値がFalseで、reasonの値がCreatingでない場合、Podのスケジュールに失敗しており、Podがスケジュールされるまで待つ必要があります。

たとえば、リソース不足が原因でPodの作成に失敗したとします。次のサンプルコードは、Podの障害処理ポリシーがfail-fastの場合のContainerInstanceCreated条件の例です。

説明

Podの障害処理ポリシーがfail-backの場合、Podの作成に失敗した後、システムは自動的にPodを再スケジュールします。この場合、pod status.reasonはContainerInstanceScheduleFailedではありません。ContainerInstanceCreated条件を表示し、条件のreasonとmessageに基づいて、現在のスケジューリングサイクルにおけるスケジューリング失敗の原因を特定できます。

{
    "conditions": [
        {
            "lastProbeTime": "2023-03-30T18:11:31Z",
            "lastTransitionTime": "2023-03-30T18:11:31Z",
            "message": "指定されたインスタンスの在庫がないため、ECIの作成に失敗しました。 %s",
            "reason": "ContainerGroup.NoStock",
            "status": "False",
            "type": "ContainerInstanceCreated"
        }
    ],
    "Reason":"ContainerInstanceScheduleFailed",
    "phase": "Pending"
}