你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

安全升级做法入门

2025-06-23

本文介绍 Azure Operator Service Manager (AOSM) 安全升级做法 (SUP)。此功能集允许升级到 Azure作员 Nexus 上托管的复杂容器网络功能（CNF）。这些升级通常支持服务软件升级（ISSU）中的合作伙伴方法和要求。虽然本文介绍了基本概念，但请查找其他扩展高级 SUP 特性和功能的文章。

安全升级简介

AOSM 支持的给定网络服务，由一个或多个 CNF 组成，包括一段时间内需要软件和/或配置更改的组件。若要进行这些组件级别的更改，必须运行一到多个 helm作，按特定顺序升级每个网络函数应用程序（nfApp），并至少影响网络服务的方式。 AOSM 安全升级做法应用以下高级功能来处理升级过程和工作流要求：

SNS 重放支持 - 在网络函数设计版本 (NFDV) 中的所有 nfApp 执行 Helm 升级操作。
Nexus 平台 - 在 Nexus 平台目标上支持 SNS 重放操作。
作超时 - 能够为每个 nfApp作设置作超时。
同步操作 - 能够一次运行一个串行 nfApp 操作。
控制升级顺序 - 定义用于安装和升级的不同 nfApp 序列。
在失败时暂停 - 默认行为是在 nfApp 操作失败后暂停。
失败时回滚 - 可选行为，在失败的 nfApp 之前回滚已完成的 nfApp。
单图表测试验证 - 在创建或更新后运行 Helm 测试操作。
无更改时跳过 nfApp - 无更改结果的情况下跳过 nfApp 处理。
映像预加载 - 能够将映像预加载到边缘存储库。

安全升级方法

若要更新现有的 AOSM 站点网络服务（SNS），作员针对已部署的 SNS 资源执行信誉请求。如果 SNS 包含具有多个 nfApp 的 CNF，则请求会散开到网络函数定义版本 (NFDV) 中定义的所有 nfApp 中。默认情况下，按顺序显示它们，或者（可选）按参数定义 updateDependsOn 的顺序显示。

对于每个 nfApp，信誉请求支持各种更改，包括增加 helm 图表版本、添加/删除 helm 值和/或添加/删除任何 nfApps。虽然可以根据已知的允许运行时为每个 nfApp 设置超时，但只能按串行顺序处理 nfApps，一个接一个。重放更新实现以下处理逻辑：

对 nfApp 按照 updateDependsOn 排序或出现顺序进行处理。
跳过参数 applicationEnabled 设置为禁用的 nfApp。
参数 skipUpgrade 设置为 enabled 的 nfApps 如果未检测到任何更改，则会被跳过。
使用旧版和新版 NFDV 之间常见的 nfApps 进行 helm upgrade升级。
仅使用 helm install新 NFDV 中安装的 nfApps。
已 helm delete部署但未由新 NFDV 引用的 nfApps 使用。

为了确保结果，nfApp 测试支持使用 helm 方法、helm 预挂钩或后挂钩触发的测试，或使用独立的 helm 测试挂钩。对于挂钩前或后挂钩失败， atomic 将遵循该参数。使用 atomic/true 时，失败的图表会回滚。使用 atomic/false 时，不执行任何回滚。对于独立的 helm 测试挂钩失败， rollbackOnTestFailure 遵循与原子类似的逻辑。有关独立 helm 测试的详细信息，请参阅以下文章：安装或升级后运行测试

如果发生 nfApp作失败，并且通过atomicrollbackOnTestFailure参数处理失败的 nfApp 后，作员可以控制如何在失败的 nfApp 之前处理任何 nfApps 更改的行为。如果暂停失败，作员可以在解决失败的 nfApp 后强制 AOSM 中断，从而保留混合版本环境。如果回滚失败，作员可以强制 AOSM 回滚任何以前的 nfApp，从而还原原始环境快照。有关控制升级失败行为的详细信息，请参阅以下文章：控制升级失败行为

服务内升级注意事项

Azure Operator Service Manager 在通常情况下支持服务中升级，这是一种推进部署版本但不中断运行中服务的升级方法。某些网络函数所有者注意事项是确保 ISSU作期间 AOSM 的正确行为所必需的。

如果 AOSM 针对一组有序的多个 nfApp 执行升级，则 AOSM 会首先升级或创建所有新的 nfApps，然后删除所有旧的 nfApps。此方法可确保在所有新的 nfApps 准备就绪之前，服务不会受到影响，但需要额外的平台容量来暂时托管旧版和新 nfApps。
如果 AOSM 升级具有多个副本的 nfApp，则 AOSM 会遵循用于滚动或重新创建选项的部署配置文件设置。在使用滚动时，暴露值 maxUnavailable 和 maxSurge 作为 CGS 参数，然后可以通过运算符 CGV 在运行时设置这些参数。

最终，给定服务在不中断的情况下升级的能力是服务本身的一项功能。请与服务发布者进一步咨询，了解服务内升级功能，并确保它们与适当的 AOSM 行为选项保持一致。

安全升级先决条件

使用 AOSM 规划升级时，在升级执行之前满足以下要求，以优化尝试并确保升级成功所用的时间。

使用发布者和/或设计器工作流加入更新的项目。
- 在大多数情况下，使用现有发布服务器托管新版本项目。
  - 使用现有发布服务器支持 helm upgrade 将 SNS 更新到其他版本。
  - 使用新发布服务器需要当前 SNS 的 helm delete，然后是新 SNS 版本的 helm install。
- 制品库、网络服务设计组（NSDG）和网络函数设计组（NFDG）是不可变的，无法更改。
  - 更改其中一个资源需要部署新的 SNS。
- 存储新的图表和图像需要新的项目清单。
  - 有关上传新图表和图像的详细信息，请参阅载入文档。
- 需要新的 NFDV 和（可选）网络服务设计版本（NSDV）。
  - NFDV 更改可能比较复杂。本文仅介绍基本更改。
  - 仅当引入新的配置组架构 (CGS) 版本时，才需要新 NSDV。
- 根据需要新建 CGS。
  - 升级引入新的公开配置参数时必需。

注释

同一 NSDG 和 NFDG 支持具有不同主要版本的 NSDV 和 NFDV

使用运营商工作流创建更新的项目。
- 根据需要基于新 CGS 创建新的配置组值 (CGV)。
- 通过确认现有站点和站点网络服务对象来重复使用和创建有效负载。
更新模板，以确保根据对升级和所需失败行为的置信度来设置升级参数。
- 用于生产的设置可能会抑制失败详细信息，而用于调试或测试的设置可能会选择公开这些详细信息。

安全升级过程

按照以下过程使用 AOSM 触发升级。

创建新的 NFDV 资源
- 对于新的 NFDV 版本，它必须采用有效的 SemVer 格式。新版本可以是相对于已部署版本的升级，即具有更高的价值，也可以是降级，即具有较低的价值。新版本可能因主版本、次要版本或修补程序版本而异。
更新新的 NFDV 参数
- Helm 图表版本可以更新，也可以根据需要更新或参数化 Helm 值。还可以添加已部署版本中不存在的新 nfApp。
更新 NFDV 以获取所需的 nfApp 顺序
- UpdateDependsOn 是一个 NFDV 参数，用于在更新操作期间指定 nfApps 的顺序。如果未提供 updateDependsOn，则使用 CNF 应用程序在 NFDV 中显示的串行排序。
更新 ARM 模板以执行所需的升级行为
- 请确保设置任何所需的 CNF 应用程序 timeout、 atomic 参数和 rollbackOnTestFailure 参数。随着时间的推移，更改这些参数可能很有用，因为升级中获得的置信度更高。
发出 SNS 重放
- 完成加入后，将提交重放操作。根据 nfApps 的数量、大小和复杂性，reput 操作可能需要一些时间才能完成（可能需要多个小时）。
检查重放结果
- 如果重放报告成功的结果，则升级完成，用户应验证服务的状态和可用性。如果重放报告失败，请按照升级失败恢复部分中的步骤继续操作。

安全升级重试过程

如果重放更新失败，可以按照以下过程重试该操作。

诊断失败的 nfApp
- 通过分析日志和其他调试信息来解决 nfApp 失败的根本原因。
手动跳过已完成的图表
- 修复失败的 nfApp 后，但在尝试升级重试之前，请考虑更改 applicationEnablement 参数以加速重试行为。可以将此参数设置为 false，在这种情况下应跳过 nfApp。此参数在 nfApp 不需要升级的情况下非常有用。
发出 SNS 重放重试（重复，直至成功）
- 默认情况下，重放会按照声明的更新顺序重试 nfApp，除非使用 applicationEnablement 标志跳过它们。

使用 installOptions 和 UpgradeOptions 控制超时

当 SNS作启动 a helm install 或 a helm upgrade时，将使用 27 分钟的默认超时值。虽然可以在全局网络函数（NF）级别自定义此值，但我们建议在 roleOverrideValues NF 有效负载模板中使用组件 NF 级别自定义此值。进一步公开 roleOverrideValues CGS/CGV 中的作可在运行时由作员控制。以下示例演示了跨两个 nfApp 组件应用的 supported installOptions 和 upgradeOptions 参数：

{
  "roleOverrideValues": [
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } }
  ]
}

跳过使用 applicationEnablement 的 nfApps

在 NFDV 资源中，位于 deployParametersMappingRuleProfile 下的属性 applicationEnablement 是一个枚举类型，其取值为未知、已启用或禁用。它可用于在网络函数部署期间手动排除 nfApp作。以下示例演示了一种泛型方法，用于将 applicationEnablement 参数化为 roleOverrideValues 属性中的包含值。

NFDV 模板更改

虽然不需要任何 NFDV 更改，但发布者可以选择使用 NFDV 设置属性的 applicationEnablement 默认值。默认值被使用，除非通过roleOverrideValues进行更改。使用 NFDV 模板设置默认值 applicationEnablement。以下示例将状态设置为 enabled networkfunctionApplication 的 hellotest 默认值。

      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
            "deployParametersMappingRuleProfile": {
              "applicationEnablement": "Enabled"
            },
            "name": "hellotest"
        ],
        "nfviType": "AzureArcKubernetes"
        },
      }

若要更动态地管理 applicationEnablement 值，作员可以使用 NF 模板 roleOverrideValues 属性传递实时值。虽然操作员可以直接操作 NF 模板，但转而参数化 roleOverrideValues，以便在运行时通过 CGV 模板传递值。以下示例展示对 CGS、NF 模板以及最终 CGV 的必要修改。

CGS 模板更改

必须更新 CGS 模板，以便为每个行包含一个变量声明以在 roleOverrideValues 下参数化。下面的示例演示了三个替代值。

        "roleOverrideValues0": {
          "type": "string"        
        },    
        "roleOverrideValues1": {
          "type": "string"        
        },        
        "roleOverrideValues2": {
          "type": "string"
        }

NF 有效负载模板更改

NF 模板必须用三种方式进行更新。首先，隐式配置参数必须定义为类型对象。其次，roleOverrideValues0、roleOverrideValues1和roleOverrideValues2必须声明为变量，并映射到配置参数。第三，roleOverrideValues0roleOverrideValues1必须按正确的顺序引用替换roleOverrideValues2，并roleOverrideValues遵循正确的语法。

  "parameters": {
    "config": {
      "type": "object",
      "defaultValue": {}
    }
  }
  "variables": {
    "roleOverrideValues0": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
  {
<snip>
     "roleOverrideValues": [
          "[variables('roleOverrideValues0')]",
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
   }

CGV 模板更改

CGV 模板现在可以更新，以便在运行时将每个变量的内容替换为 roleOverrideValues 属性。以下示例将 rollbackEnabled 设置为 true，然后对 hellotest 和 hellotest1 nfApplications 进行覆盖设置。

{
    "roleOverrideValues0": "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
    "roleOverrideValues1": "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\":\"Enabled\",\"helmMappingRuleProfile\":{\"releaseName\":\"override-release\",\"releaseNamespace\":\"override-namespace\",\"helmPackageVersion\":\"1.0.0\",\"values\":\"\",\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"}}}}}",
    "roleOverrideValues2": "{\"name\":\"hellotest1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Enabled\"}}"
}

有了此框架，操作员可以通过简单地更新 CGV 来管理任何 roleOverrideValues 操作，然后将该 CGV 附加到所需的 SNS 操作中。

跳过没有更改的 nfApp

skipUpgrade 功能旨在优化 CNF 升级所需的时间。当发布者在 roleOverrideValues 下的 upgradeOptions 中启用此标志时，AOSM 服务层会执行某些预检查，以确定是否可以跳过特定 nfApplication 的升级。如果符合所有预检查条件，则跳过该应用的升级。否则，将在群集级别执行升级。

预检查条件

如果符合以下所有条件，则可以跳过升级：

nfApplication 预配状态为“成功”。
Helm 图表名称或版本没有变化。
Helm 值没有更改。

启用或禁用 skipUpgrade 功能

默认情况下，skipUpgrade 功能被禁用。如果在 roleOverrideValues 下的 upgradeOptions 中没有指定这个可选参数，那么 CNF 升级将以传统的方式进行，即在 nfApplications 群集级别进行升级。

启用网络功能资源中的 SkipUpgrade

要通过 roleOverrideValues 启用 SkipUpgrade 功能，请参阅以下示例。

{
    "location": "eastus2euap",
    "properties": {
        "publisherName": "xyAzureArcRunnerPublisher",
        "publisherScope": "Private",
        "networkFunctionDefinitionGroupName": "AzureArcRunnerNFDGroup",
        "networkFunctionDefinitionVersion": "1.0.0",
        "networkFunctionDefinitionOfferingLocation": "eastus2euap",
        "nfviType": "AzureArcKubernetes",
        "nfviId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourcegroups/ashutosh_test_rg/providers/microsoft.extendedlocation/customlocations/ashutosh_test_cl",
        "deploymentValues": "",
        "roleOverrideValues": [
            "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"1\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\",\"skipUpgrade\":\"true\"}}}}}",
            "{\"name\":\"runnerTest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"}}}}}"
        ]
    }
}

示例说明

nfApplication： hellotest
- 已启用 skipUpgrade 标志。如果 hellotest 的升级请求满足预检查条件，则会跳过升级。
nfApplication： runnerTest
- 未指定 skipUpgrade 标志。因此，即使符合预检查条件，runnerTest 也会在群集级别执行传统 Helm 升级。

完整 roleOverrideValues 选项参考

将本文和其他文章中的所有示例组合在一起，以下参考演示了通过 roleOverrideValues 该机制提供的所有当前支持的选项。

{
  "roleOverrideValues": [
    {
      "nfConfiguration": {
        "rollbackEnabled": "true"
      }
    },
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    }
  ]
}

通过