共用方式為

Azure 運算子服務管理員用來進行網路功能上線和部署的最佳做法

  • 發行項

Microsoft 針對使用 Azure 運算子服務管理員來管理網路功能 (NF) 開發了許多經過實證的做法。 本文會提供可供 NF 廠商、電信業者及其合作夥伴遵循以實現最佳設計的指導方針。 在進行 NF 的上線和部署時，請牢記這些做法。

一般考量

我們的建議是，先使用快速入門來熟悉整體流程，將最簡單的 NF (一或兩個圖表) 進行上線和部署。 在後續反覆進行時，再新增必要設定的詳細資料。 在進行快速入門的過程中，請考慮下列幾點：

  • 建構符合計劃用途的成品。 考慮將全域成品與您想要隨網站或執行個體而異的成品區隔開來。
  • 確保服務是由多個 NF 組成，且這些 NF 具有符合您網路需求的參數集。 例如，您可能有一個具有 1,000 個值的圖表，並且您只自訂了其中的 100 個值。 請確保您只在設定群組結構描述 (CGS) 層中公開 100 個 (後續章節會有更廣泛的說明)。
  • 及早思考要如何區隔基礎結構 (例如叢集) 或成品存放區以及供應商之間的存取，尤其是在單一服務內。 讓您的發行者資源集符合此模型。
  • Azure 運算子服務管理員網站是邏輯上的概念，所代表的是部署目的地。 範例包括適用於容器化網路功能 (CNF) 的 Kubernetes 叢集，或適用於虛擬化網路功能 (VNF) 的 Azure 運算子連接點擴充自訂位置。 其不會代表實體邊緣網站，因此會有多個網站共用相同實體位置的使用案例。
  • Azure 運算子服務管理員提供了各種 API 讓您輕鬆地與 ADO 或其他管線工具合併。

發行者考量

  • 建議您為每個 NF 供應商建立單一的發行者。 這種做法可為所有供應商提供最佳的支援、維護和治理體驗，並在網路服務由多個廠商的多個 NF 組成時簡化設計。

  • 在所需的 Azure 運算子服務管理員發行者資源和成品集合完成測試並獲准用於生產環境後，建議您將整個集合標記為不可變以避免集合意外變更，並確保部署體驗會一致。 請考慮依靠不變性功能來區分生產環境所用的資源和成品以及測試和開發用途所用的資源和成品。 您可以查詢發行者資源和成品資訊清單的狀態，以判斷哪些項目標記為不可變。 如需詳細資訊，請參閱發行者租用戶、訂用帳戶、區域和預覽管理。

    請記住下列邏輯：

    • 如果網路服務設計功能 (NSDV) 標記為不可變，CGS 也必須標記為不可變。 否則，部署呼叫會失敗。
    • 如果網路功能設計版本 (NFDV) 標記為不可變，成品資訊清單也必須標記為不可變。 否則，部署呼叫會失敗。
    • 如果只有成品資訊清單或 CGS 標記為不可變，則不論 NFDV 和 NSDV 是否標記為不可變，部署呼叫都會成功。
    • 將成品資訊清單標記為不可變，可確保該資訊清單中所列的所有成品 (通常是圖表、影像和 Azure Resource Manager 範本 [ARM 範本]) 也都會藉由在成品存放區上強制執行必要權限來標記為不可變。

  • 請考慮使用各方同意的命名慣例和治理技術，來協助弭平任何剩餘缺口。

網路功能定義群組和版本考量

網路功能定義群組 (NFDG) 代表您打算跨多個服務獨立重複使用的最小元件。 NFDG 的所有組件一律會一起部署。 這些組件稱為 networkFunctionApplications。 例如，在一律會一起部署的情況下，將由多個 Helm 圖表和影像組成的單一 NF 以單一 NFDG 的形式上線是再自然不過的事了。 如果一律會一起部署多個 NF，則讓所有 NF 共用單一 NFDG 是合理的做法。 單一 NFDG 可以有多個 NFDV。

若為容器化網路功能定義版本 (CNF NFDV)，networkFunctionApplications 清單只能包含 Helm 套件。 在一律會一起部署和刪除的情況下，納入多個 Helm 套件是合理的做法。

若為虛擬化網路功能定義版本 (VNF NFDV)，networkFunctionApplications 清單必須至少包含一個 VhdImageFile 和一個 ARM 範本。 ARM 範本應該部署單一虛擬機器 (VM)。 若要為單一 VNF 部署多個 VM，請務必針對每個 VM 使用不同的 ARM 範本。

ARM 範本只能部署來自下列資源提供者的 Resource Manager 資源：

  • Microsoft.Compute
  • Microsoft.Network
  • Microsoft.NetworkCloud
  • Microsoft.Storage
  • Microsoft.NetworkFabric
  • Microsoft.Authorization
  • Microsoft.ManagedIdentity

注意

針對包含上述清單以外任何項目的 ARM 範本，VNF 上的所有 PUT 呼叫和 Re-PUT 都會導致驗證錯誤。

會觸發網路功能設計版本次要或主要版本更新的常見使用案例

  • 針對會觸發 deployParametersMappingRuleProfile 變更的現有版本，更新其 CGS/設定群組值 (CGV)。
  • 更新在 NFDV 中硬式編碼的值。
  • 將元件標記為非使用中，以防止透過 applicationEnablement: Disabled 部署元件。
  • 新的 NF 版本，例如圖表和影像。

注意

每當指定 NF 的承載有所變更時所需的變更數目下限。 未公開新 CGS 參數的次要或主要 NF 版本只需要更新成品資訊清單、推送新的影像和圖表，以及更改 NFDV 版本。

網路服務設計群組和版本考量

網络服務設計群組 (NSDG) 由一或多個 NFDG 以及同時部署的任何基礎結構元件 (例如連接點 Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS] 叢集和虛擬機器) 組成。 網站網路服務 (SNS) 指的是單一 NSDV。 這類設計可以保證網路服務會以一致且可重複的方式，從單一 SNS PUT 部署至指定網站。

NSDG 的範例如下：

  • 驗證伺服器功能 (AUSF) NF
  • 整合資料管理 (UDM) NF
  • 支援 AUSF/UDM 的系統管理 VM
  • Unity Cloud (UC) 工作階段管理功能 (SMF) NF
  • 作為 AUSF、UDM 和 SMF 部署目的地的 NAKS 叢集

這五個元件會構成單一 NSDG。 單一 NSDG 可以有多個 NSDV。

會觸發網路服務設計版本次要或主要版本更新的常見使用案例

  • 建立或刪除 CGS。
  • 與其中一個要部署的 NF 相關聯的 NF ARM 範本中的變更。
  • 基礎結構 ARM 範本中的變更，例如 AKS/NAKS 或 VM。

注意

NFDV 中的變更不應觸發 NSDV 更新。 NFDV 值應公開為 CGS 內的參數，讓運算子可以使用 CGV 來控制要部署的項目。

設定群組結構描述考量

建議您一律從整個 NF 的單一 CGS 開始。 如果有網站特定或執行個體特定的參數，仍建議您將其留在單一 CGS 內。 有多個元件 (NF 很少見，基礎結構較常見) 或設定跨多個 NF 共用時，建議分割成多個 CGS。 CGS 的數目會定義 CGV 的數目。

案例

  • 針對 NSD 內的所有 NF，一律會部署 FluentD、Kibana 和 Splunk (常見的第三方元件)。 建議您將這些元件分組到單一 NFDG。
  • NSD 有多個會全部共用一些設定 (部署位置、發行者名稱和幾個圖表設定) 的 NF。

在此案例中，建議您使用單一的全域 CGS 來公開常見的 NF 和第三方元件設定。 您可以視需要定義 NF 特定的 CGS。

選擇要公開的參數

  • CGS 應該只有 NF (第 0 /N 天設定) 或共用元件所使用的參數。
  • 很少設定的參數應該已定義預設值。
  • 如果使用多個 CGS，建議不要讓參數重疊，或只讓參數稍微重疊。 如果需要重疊，請確定參數名稱可在 CGS 之間清楚區分。
  • 應該針對 CGS 考慮可透過 API 定義的項目 (Azure 運算子連接點、Azure 運算子服務管理員)。 例如，反過來透過 CloudInit 檔案定義這些設定值。
  • 若不確定，公開參數並在 CGS 中指定合理的預設值是不錯的起點。 下列範例會顯示範例 CGS 和對應的 CGV 承載。
  • 所有 NF ARM 範本中都應使用並透過 CGS 來公開單一使用者指派的受控識別。

CGS 承載：

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

運算子傳遞的對應 CGV 承載：

{
"qwe": 20
}

Azure 運算子服務管理員所產生的 CGV 承載：

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

設定群組值考量

在提交 CGV 資源建立前，您可以驗證基礎 YAML 或 JSON 檔案的結構描述和值是否符合對應的 CGS 所預期的結構描述和值。 若要達成此目的，其中一個選項是使用適用於 Visual Studio Code 的 YAML 延伸模組。

CLI 考量

Azure 運算子服務管理員 CLI 延伸模組可協助發佈 NFD 和 NSD。 請使用此工具作為建立新 NFD 和 NSD 的起點。 請考慮使用 CLI 來建立初始檔案。 然後編輯檔案，以在納入基礎結構元件後再發佈檔案。

網站網路服務考量

建議您讓整個網站 (包括基礎結構) 使用單一 SNS。 SNS 應該部署任何所需的基礎結構 (例如 NAKS/AKS 叢集和虛擬機器)，然後在這之上部署所需的 NF。 這類設計可以保證網路服務會以一致且可重複的方式，從單一 SNS PUT 部署至指定網站。

建議您使用使用者指派的受控識別 (而非系統指派的受控識別) 來部署每個 SNS。 這個使用者指派的受控識別必須具有存取 NFDV 的權限，而且必須具備其上受控識別運算子的角色。 如需詳細資訊，請參閱建立和指派使用者指派的受控識別 (部分機器翻譯)。

每個使用案例的 Azure 運算子服務管理員資源對應

下列兩個案例可說明 Azure 運算子服務管理員的資源對應。

案例：單一網路功能

具有一或兩個應用程式元件的 NF 部署到 NAKS 叢集。

資源明細：

  • NFDG：如果元件可以獨立使用，則兩個 NFDG，每個元件各一個。 如果元件一律會一起部署，則單一 NFDG。
  • NFDV：視需要，根據先前會觸發 NFDV 次要或主要版本更新的＜常見使用案例＞章節中所述的使用案例而定。
  • NSDG：單一。 合併 NF 和 Kubernetes 叢集定義。
  • NSDV：視需要，根據先前會觸發 NSDV 次要或主要版本更新的＜常見使用案例＞章節中所述的使用案例而定。
  • CGS：單一。 我們的建議是，讓 CGS 針對要部署的每個元件和基礎結構各有一個子區段以方便管理，並讓 CGS 包含 NFD 的版本。
  • CGV：單一，根據 CGS 的數目。
  • SNS：每個 NSDV 一個。

案例：多個網路功能

具有一些共用和獨立元件的多個 NF 部署到 NAKS 叢集。

資源明細：

  • NFDG：
    • 所有共用元件的 NFDG。
    • 每個獨立元件或 NF 的 NFDG。
  • NFDV：先前會觸發 NFDV 次要或主要版本更新的＜常見使用案例＞章節中所述的每個使用案例，其每個 NFDG 多個 NFDV。
  • NSDG：單一。 合併所有 NF、共用和獨立元件，以及基礎結構 (Kubernetes 叢集或任何支援 VM)。
  • NSDV：視需要，根據先前會觸發 NSDV 次要或主要版本更新的＜常見使用案例＞章節中所述的使用案例而定。
  • CGS：
    • 單一。 全域適用於具有共用設定值的所有元件。
    • 每個 NF 的 NF CGS，包括 NFD 的版本。
    • 根據參數總數，請考慮將所有 CGS 合併成單一 CGS。
  • CGV：等於 CGS 的數目。
  • SNS：每個 NSDV 一個。

軟體升級考量

假設 NF 支援就地/服務內升級，針對 CNF：

  • 如果新增圖表和影像，Azure 運算子服務管理員會安裝新的圖表。
  • 如果移除某些圖表和影像，Azure 運算子服務管理員會刪除 NFDV 中不再宣告的圖表。
  • Azure 運算子服務管理員會驗證源自相同 NFDG/NSDG、以及因此源自相同發行者的 NFDV/NSDV。 不支援跨發行者來升級。

針對 VNF：

  • 目前不支援就地升級。 您必須使用更新的影像並排具現化新的 VNF。 然後刪除 SNS 來刪除較舊的 VNF。
  • 如果將 VNF 部署為一對 VM 以實現高可用性，則可以將網路服務設計為可以一個接一個地刪除和升級 VM。 建議您使用下列設計，以允許刪除和升級個別 VM：
    • 使用專用的 ARM 範本來部署每個 VM。
    • 從 ARM 範本中，必須透過 CGS 公開兩個參數：VM 名稱，用以允許指出哪個執行個體是主要/次要，以及部署原則，以控制是否允許部署 VM。
    • 在 NFDV 中，deployParameters 和 templateParameters 必須參數化為可讓您為每個參數使用 CGV 來提供唯一值。

高可用性和災害復原考量

Azure 運算子服務管理員是跨可用性區域部署的區域服務，可用性區域所在的區域可支援這些可用性區域。 如需可使用 Azure 運算子服務管理員的所有區域，請參閱依區域提供的 Azure 產品。 如需具有可用性區域的 Azure 區域清單，請參閱選擇適合您的 Azure 區域。

請考慮下列高可用性和災害復原需求：

  • 若要提供異地備援，請確定在您打算部署 NF 的每個區域中都有發行者。 請考慮使用管線來確保發行者成品和資源會跨區域保持同步。
  • 在每個 Microsoft Entra 租用戶的每個區域中，發行者名稱必須是唯一的。

注意

如果區域變成無法使用的狀態，您可以使用其他區域中的發行者資源來部署 (而非升級) NF。 假設發行者之間的成品和資源完全相同，您只需要變更 SNS 資源承載中的 networkServiceDesignVersionOfferingLocation 值。

resource sns 'Microsoft.HybridNetwork/sitenetworkservices@2023-09-01’ = {
 name: snsName
 location: location
 identity: {
  type: 'SystemAssigned'
 }
 properties: {
   publisherName: publisherName
   publisherScope: 'Private'
   networkServiceDesignGroupName: nsdGroup
   networkServiceDesignVersionName: nsdvName
   networkServiceDesignVersionOfferingLocation: location

疑難排解考量

根據預設，在安裝和升級期間，不可部分完成的選項和等候選項會設定為 true，且作業逾時會設定為 27 minutes。 在上線期間，建議您將不可部分完成的旗標設定為 false，以防止 Helm 在失敗時復原。 要完成這一點，最佳方式是在 NF 的 ARM 範本內進行。

在 ARM 範本中，新增下列區段：

"roleOverrideValues": [
    "{\"name\":\"NF_component_name>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]

元件名稱定義於 NFDV 中：

     networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'fed-crds'
          dependsOnProfile: null
          artifactProfile: {
            artifactStore: {
              id: acrArtifactStore.id
            }

清除考量

請依下列順序刪除運算子資源，以確保不會留下任何孤立的資源：

  • SNS
  • Site
  • CGV

重要

請務必先刪除 SNS，再刪除 NFDV。

請依下列順序刪除發行者資源，以確保不會留下任何孤立的資源：

  • CGS
  • NSDV
  • NSDG
  • NFDV
  • NFDG
  • 成品資訊清單
  • 成品商店
  • 發行者

下一步