控制升級失敗行為

發行項
09/04/2024

概觀

本指南說明容器網路功能 (CNF) 的 Azure 操作員服務管理員 (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 還原至升級前的快照版本狀態，並先恢復最新的動作。

注意

如果使用者未啟用失敗時復原，則 AOSM 不會建立快照。
失敗時復原僅適用於成功完成的 NFApp。
- 使用 testOptions、installOptions 或 upgradeOptions 參數來控制失敗 NfApp 的復原。

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>

如何設定失敗時復原

控制失敗行為的最彈性方法是擴充新的設定群組結構描述 (CGS) 參數 rollbackEnabled，以允許透過 NF 承載中的 roleOverrideValues 進行設定群組值 (CGV) 控制。首先，定義 CGS 參數：

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

注意

如果未透過 roleOverrideValues 參數提供 nfConfiguration，則預設會停用復原。

定義新的 rollbackEnable 參數後，操作員現在可以在 roleOverrideValues 下提供執行階段值，作為 NF Reput 承載的一部分。

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

注意

每個 roleOverrideValues 項目都會覆寫 NfAapp 的預設行為。
如果在 roleOverrideValues 中找到多個 nfConfiguration 項目，則會以不正確的要求傳回 NF Reput。

如何針對失敗時復原進行疑難排解

了解 Pod 狀態

了解不同的 Pod 狀態對於有效疑難排解至關重要。以下是最常見的 Pod 狀態：

Pending：Kubernetes 正在進行 Pod 排程。
Running：Pod 中的所有容器都正在執行且狀況良好。
Failed：Pod 中的一或多個容器會以非零結束代碼終止。
CrashLoopBackOff：Pod 內的容器不斷損毀，Kubernetes 無法重新啟動它。
ContainerCreating：容器正在由容器執行階段建立。

檢查 Pod 狀態和記錄

首先，使用 kubectl 命令檢查 Pod 狀態和記錄：

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

get pods 命令會列出目前命名空間中的所有 Pod，以及其目前狀態。 logs 命令會擷取特定 Pod 的記錄，讓您檢查任何錯誤或例外狀況。若要針對網路問題進行疑難排解，請使用下列命令：

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

get services 命令會顯示目前命名空間中的所有服務。該命令提供有關特定服務的詳細資料，包括相關聯的端點以及任何相關的錯誤訊息。如果您遇到 PVC 問題，可以使用以下命令來對其進行偵錯：

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

"get persistentvolumeclaims" 命令會列出目前命名空間中的所有 PVC。 describe 命令提供有關特定 PVC 的詳細資訊，包括狀態、相關聯的儲存類別，以及任何相關的事件或錯誤。

共用方式為