デフォルトでは、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 にマウントされているとき、プロビジョナーはWaitForFirstConsumerStorageClass をサポートしません。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"
}