アップグレード失敗時の動作を制御する

このガイドでは、コンテナーネットワーク機能 (CNF) の Azure Operator Service Manager (AOSM) アップグレード失敗時の動作の機能について説明します。再試行を高速化するために、障害発生時に一時停止を使用します。開始点に戻るには、障害発生時にロールバックを使用します。

障害発生時の一時停止の概要

AOSM を使用したアップグレードはすべて、サイトネットワークサービス (SNS) の reput 操作から始まります。リプット操作は、ネットワーク関数設計バージョン (NFDV) で検出されたネットワーク関数アプリケーション (nfApps) を処理します。 reput 操作では、次の既定のロジックが実装されます。

ユーザーは、失敗時に停止を有効にして、SNSの評価操作を開始します。
nfApps は、 updateDependsOn 順序に従うか、表示される順番で処理されます。
nfApp のインストールまたはアップグレード操作が失敗した場合、その操作と nfApp のアトミックロールバック設定が受け入れられます。
事前に完了した NfApps は、それ以上操作されません。
タスクは終了し、SNS リソースは失敗状態のままになります。

障害発生時に一時停止すると、AOSM は、 testOptions、 installOptions、または upgradeOptions 操作パラメーターを使用して、失敗した nfApp のみをロールバックします。失敗した nfApp の後に続く nfApps に対しては、いかなるアクションも実行されません。この方法を使用すると、エンドユーザーは失敗した nfApp のトラブルシューティングを行い、その時点からアップグレードを再開できます。既定の動作として、この方法が最も効率的な方法ですが、バージョンが混在している状態ではネットワーク機能 (NF) の不整合が発生する可能性があります。

アップグレードが成功しました

すべての nfApp が、Helm インストールまたは Helm アップグレードエラーを生成せずに目的のターゲット状態に達した場合、アップグレードは成功したと見なされます。このような状況では、Azure Operator Service Manager は次の操作状態とメッセージを返します。

  - Upgrade Succeeded
    - Provisioning State: Succeeded
    - Message: <empty>

アップグレードに失敗しました

nfApp が helm インストールまたは helm アップグレードの失敗を生成した場合、アップグレードは失敗したと見なされます。このような状況では、Azure Operator Service Manager は次の操作状態とメッセージを返します。

  - Upgrade Failed
    - Provisioning State: Succeeded
    - Message: Application(<ComponentName>) : <Failure Reason>

障害発生時のロールバックの概要

nfApp のバージョンが一致しないリスクに対処するために、Azure Operator Service Manager では、障害発生時の NF レベルのロールバックがサポートされます。このオプションを有効にすると、nfApp 操作が失敗した場合、失敗した nfApp と、以前に完了したすべての nfApps の両方を、初期バージョンの状態にロールバックできます。このメソッドは、NF が nfApp バージョンの不一致に公開される時間を最小限に抑えるか、または排除します。オプションの失敗時のロールバック機能の働きは次のとおりです。

ユーザーは、失敗時にロールバックを有効にして、SNS の再投入操作を開始します。
nfApps は、 updateDependsOn 順序に従うか、表示される順番で処理されます。
すべての NfApps のアトミック状態は true に強制され、指定された演算子値はすべて無視されます。
現在の nfApp バージョンのスナップショットがキャプチャされ、格納されます。
スナップショットは、正常に完了したアクションを元に戻すために実行される個々の nfApp アクションを決定するために使用されます。
- helm install 削除されたコンポーネントに対するアクション、
- アップグレードされたコンポーネントに対する helm rollback アクション、
- helm delete 新しくインストールされたコンポーネントに対するアクション
nfApp のインストールまたはアップグレード操作が失敗した場合、失敗した nfApp のアトミックロールバックが最初に実行されます。
アトミックロールバックの後、以前に完了した NfApps が元のスナップショットバージョンに復元され、最新のアクションが最初に元に戻されます。
タスクは終了し、SNS リソースは失敗状態のままになります。

注意

ユーザーが失敗時のロールバックを有効にしない場合、AOSM はスナップショットを作成しません。
失敗時のロールバックは、正常に完了した nfApps にのみ適用されます。
アトミックロールバックのエラーは、ロールバックエラーとして扱われません。

アップグレードが成功しました

  - Upgrade Succeeded
    - Provisioning State: Succeeded
    - Message: <empty>

ロールバックが成功しました

以前に完了したすべての NfApps が、Helm ロールバックエラーを生成せずに元のスナップショット状態に達した場合、ロールバックは成功したと見なされます。このような状況では、Azure Operator Service Manager は次の操作状態とメッセージを返します。

  - Upgrade Failed, Rollback Succeeded
    - Provisioning State: Failed
    - Message: Application(<ComponentName>) : <Failure Reason>; Rollback succeeded

ロールバックに失敗しました

以前に完了した nfApps が元のスナップショット状態に到達できず、代わりに Helm ロールバックエラーが発生した場合、ロールバックは失敗したと見なされます。このような状況では、Azure Operator Service Manager はロールバック対象の nfApps の処理を停止し、次の操作状態とメッセージで終了します。

  - Upgrade Failed, Rollback Failed
    - Provisioning State: Failed
    - Message: Application(<ComponentName>) : <Failure reason>; Rollback Failed (<RollbackComponentName>) : <Rollback Failure reason>

失敗時にロールバックを構成する

障害動作を制御する最も柔軟な方法は、新しい構成グループスキーマ (CGS) パラメーター ( rollbackEnabled) を拡張して、NF ペイロード内の roleOverrideValues を介して構成グループ値 (CGV) 制御を可能にすることです。まず、CGS パラメーターを定義します。

{
  "description": "NF configuration",
  "type": "object",
  "properties": {
    "nfConfiguration": {
      "type": "object",
      "properties": {
        "rollbackEnabled": {
          "type": "boolean"
        }
      },
      "required": [
        "rollbackEnabled"
      ]
    }
  }
}

注意

nfConfigurationが roleOverrideValues パラメーターを介して指定されていない場合、既定ではロールバックは無効になります。

新しい rollbackEnable パラメーターが定義されたので、オペレーターは NF リプットペイロードの一部として、 roleOverrideValuesの下にランタイム値を指定できるようになりました。

example:
{
  "location": "eastus",
  "properties": {
    // ...
    "roleOverrideValues": [
          "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
            "{\"name\":\"nfApp1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",
            "{\"name\":\"nfApp2\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",
          //... other nfApps overrides
       ]
  }
}

注意

各 roleOverrideValues エントリは、NfAapps の既定の動作をオーバーライドします。
nfConfigurationの複数のエントリがroleOverrideValuesで見つかった場合、NF のリプットは無効な要求として返されます。

ロールバックをサポートしていない nfApps を管理する

ほとんどの発行元には、helm rollback と互換性のない nfApp があります。これらの nfApps は、一般的に厳密な回復性要件をサポートしていないサードパーティから提供されている可能性があります。これらの nfApps は、複雑なスキーマ管理要件を持つデータベースアプリケーションである可能性があります。ロールバックをサポートしていない nfApps を使用してサービスをオンボードする場合は、次の制限事項を考慮してください。

nfApps はロールバックをサポートしていないため、スキップできません。
nfApp のロールバック順序は変更できません。
Incremental-NFDV アプローチは、このような状況で使用する必要があります。

インクリメンタル NFDV を使用した選択的ロールバック

ネットワーク関数の構成には、helm ロールバックをサポートしていない nfAppa が含まれる場合があります。既知の例は Elastic と VoltDb です。これらの nfApps のいずれかをロールバックしようとする試みは、nfApp を壊してしまいます。パブリッシャーの機能強化を追求し、これらの nfApps ロールバックに苦情を申し立てるのが最適なソリューションです。ロールバックをスキップするパラメーターはサポートされていません。NFDV で定義されていないデプロイ済み状態のリスクが発生するためです。この非決定的な動作により、テストの対象領域が大幅に増加し、デプロイの信頼性の保証が損なわれます。代わりに、増分 NFDV メソッドを使用すると、確定的な展開状態を確保しながら、選択的ロールバックの実行が可能になります。

増分型の NFDV アプローチ

パブリッシャーは、CGV の applicationEnablement、 skipUpgrade 、および nfRollbackEnabled 構成を複数の NFDV と組み合わせて使用して、ロールバックの互換性に基づいて nfApps をセットに論理的にセグメント化することをお勧めします。この増分 NFDV 戦略を使用すると、オペレーターはデプロイを複数の操作に分割し、選択したチャートのロールバックをバイパスすると同時に、残りのチャートのロールバックを維持することができます。この方法では、NFDV レベルのコンストラクトを使用して、グラフごとのロールバック動作を効果的にシミュレートします。次の例では、ネットワーク関数が 20 個の nfApps で構成され、ロールバックをサポートしていない nfApp が 5 個あるとします。

NFDV1
- 初期バージョン 1 のインストールを実行します。
  - 有効な状態の 20 個の nfApp をすべて格納します。
- CGV1 の場合: rollbackEnabled: true。
  - 最初のインストールでは、エラーによってグラフが削除され、ロールバックは使用されません。
NFDV2:
- バージョン 2 への最初の手順のアップグレードを実行します。
  - 20 個の nfApp をすべて含みますが、ロールバックをサポートせずに 5 つの nfApp のみを有効にします。
- CGV2 の場合:
  - ロールバックをサポートする 15 nfApps に対して skipUpgrade: true を使用します。
  - nfRollbackEnabled: false を設定します。
    - 成功すると、5 つの nfApp のみがアップグレードされます。
    - 失敗した場合、ロールバックは実行されません。
      - グラフの制限により、ワークロードは非決定的な状態のままです。ロールバックはできません。回復するには、次の 2 つのオプションがあります。
        
        NFDV2 を修正し、もう一度アップグレードを試してください。
        
        で NFDV1 にダウングレードする skipUpgrade: false
NFDV3:
- バージョン 2 への 2 番目の手順のアップグレードを実行します
  - 20 個の nfApp をすべて含みますが、ロールバックがサポートされている 15 個の nfApp のみを有効にします。
- CGV3 の場合:
  - NFDV2 を介してアップグレードされた 5 nfApps の場合は、 skipUpgrade: true を使用します。
  - nfRollbackEnabled: true を設定します。
    - 成功すると、残りの 15 nfApps がアップグレードされます
    - 失敗すると、ロールバックが発生して開始状態が復元されます。

注意

ロールバックと互換性のない 5 つのグラフには、NFDV3 のグラフにランタイムアップグレードの依存関係を含めてはなりません。
AOSM のロールバック設計では、ロールバックによってワークロードの状態が以前の NFDV 状態に復元されることを前提としています。

このアプローチは、標準のHelm操作をサポートしないアプリケーションのより明確な分離と容易な管理を実現します。操作のべき等性と、最後の操作によって反映されるクラスター内の状態を維持します。 NFDV 2/3 は、目標状態の違いがあっても、インストール操作に直接使用できます（以前のバージョンのインストールは必要ありません）。全体的なアップグレード時間とデプロイの信頼性は変わりません。

ロールバックが失敗する場合のトラブルシューティング

ポッドの状態を理解する

効果的なトラブルシューティングを行うには、さまざまなポッドの状態を理解することが重要です。最も一般的なポッドの状態は次のとおりです。

保留中: ポッドのスケジュール設定が Kubernetes によって進行中です。
実行中: ポッド内のすべてのコンテナーが実行中であり、正常です。
失敗: ポッド内の 1 つ以上のコンテナーが、0 以外の終了コードで終了します。
CrashLoopBackOff: ポッド内のコンテナーが繰り返しクラッシュし、Kubernetes で再起動できません。
ContainerCreating: コンテナーの作成がコンテナーランタイムによって進行中です。

ポッドの状態とログを確認する

まず、kubectl コマンドを使用してポッドの状態とログを確認します。

$ kubectl get pods
$ kubectl logs <pod-name>

get pods コマンドは、現在の名前空間内のすべてのポッドをその現在の状態と一緒に一覧表示します。 logs コマンドは、特定のポッドのログを取得し、エラーや例外を検査できるようにします。ネットワークの問題をトラブルシューティングするには、次のコマンドを使用します。

$ kubectl get services
$ kubectl describe service <service-name>

get services コマンドは、現在の名前空間内のすべてのサービスを表示します。このコマンドは、関連付けられているエンドポイントや関連するエラーメッセージなど、特定のサービスに関する詳細を提供します。 PVC で問題が発生した場合は、次のコマンドを使用してデバッグできます。

$ kubectl get persistentvolumeclaims
$ kubectl describe persistentvolumeclaims <pvc-name>

"get persistentvolumeclaims" コマンドは、現在の名前空間内のすべての PVC を一覧表示します。 describe コマンドは、状況、関連ストレージ・クラス、関連するイベントまたはエラーなど、特定の PVC に関する詳細情報を提供します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-11

アップグレード失敗時の動作を制御する

障害発生時の一時停止の概要

アップグレードが成功しました

アップグレードに失敗しました

障害発生時のロールバックの概要

アップグレードが成功しました

ロールバックが成功しました

ロールバックに失敗しました

失敗時にロールバックを構成する

ロールバックをサポートしていない nfApps を管理する

インクリメンタル NFDV を使用した選択的ロールバック

増分型の NFDV アプローチ

ロールバックが失敗する場合のトラブルシューティング

ポッドの状態を理解する

ポッドの状態とログを確認する

フィードバック

その他のリソース