次の方法で共有

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

  • [アーティクル]

概要

このガイドでは、コンテナー ネットワーク機能 (CNF) の Azure Operator Service Manager (AOSM) アップグレード失敗時の動作の機能について説明します。 これらの機能では、AOSM の安全なアップグレード プラクティス イニシアチブの一環として、失敗時の一時停止を使用して再試行を高速化するか、失敗時のロールバックを使用して開始点に戻るかを選択できます。

失敗時の一時停止

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

  • NfApp は、updateDependsOn の順序に従うか、表示される順番に処理されます。
  • パラメーター "applicationEnabled" が無効に設定されている NfApp はスキップされます。
  • 存在するにもかかわらず、新しい NFDV によって参照されない NFApp は削除されます。
  • NfApp アップグレードのいずれかが失敗し、ロールバックが検討される場合、実行順序が一時停止します。
  • 失敗により、NF リソースは失敗した状態のままになります。

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

失敗時のロールバック

NfApp のバージョンが一致しないリスクに対処するために、AOSM では失敗時の NF レベルのロールバックがサポートされるようになりました。 このオプションを有効にすると、NfApp 操作が失敗した場合、失敗した NfApp と、すでに完了したすべての NfApp の両方を初期バージョンの状態にロールバックできます。 この方法では、NF が NfApp バージョンの不一致にさらされる時間が最小限に抑えられるか、排除されます。 オプションの失敗時のロールバック機能の働きは次のとおりです。

  • ユーザーが sSNS reput 操作を開始し、失敗時のロールバックを有効にします。
  • 現在の NfApp バージョンのスナップショットがキャプチャされ、格納されます。
  • このスナップショットは、正常に完了したアクションを元に戻すために実行される個々の NfApp アクションの判別に使用されます。
    • 削除されたコンポーネントに対する "helm install" アクション
    • アップグレードされたコンポーネントに対する "helm rollback" アクション
    • 新しくインストールされたコンポーネントに対する "helm delete" アクション
  • NfApp エラーが発生し、AOSM はアップグレード前のスナップショット バージョンの状態に NfApp を復元します。最新のアクションが最初に元に戻されます。

Note

  • ユーザーが失敗時のロールバックを有効にしない場合、AOSM はスナップショットを作成しません。
  • 失敗時のロールバックが適用されるのは、正常に完了した NFApp のみです。
    • 失敗した NfApp のロールバックを制御するには、testOptions、installOptions、または upgradeOptions パラメーターを使用してください。

AOSM は、それぞれの結果に応じて、次の操作状態とメッセージを返します。

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

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

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

失敗時のロールバックを構成する方法

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

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

Note

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

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

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

Note

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

失敗時のロールバックをトラブルシューティングする方法

ポッドの状態を理解する

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

  • 保留中: ポッドのスケジュール設定が 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 に関する詳細情報を提供します。