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

控制升级失败行为

项目
10/17/2024

概述

本指南介绍 Azure Operator Service Manager (AOSM) 面向容器网络函数 (CNF) 的升级失败行为功能。这些功能作为 AOSM 安全升级实践计划的一部分，提供更快的重试、失败时暂停和返回到起点以及失败回滚之间的选择。

失败时暂停

使用 AOSM 的任何升级都从站点网络服务 (SNS) 信誉操作开始。信誉操作处理在网络函数设计版本 (NFDV) 中找到的网络函数应用程序 (NfApp)。信誉操作实现以下默认逻辑：

对 NfApp 按照 updateDependsOn 排序或出现顺序进行处理。
跳过参数“applicationEnabled”设置为禁用的 NfApp。
存在但未被新的 NFDV 引用的NFApps 将被删除。
如果任何 NfApp 升级失败并考虑回滚，则会暂停执行序列。
失败使 NF 资源处于失败状态。

失败时暂停后，AOSM 仅通过 testOptions、installOptions 或 upgradeOptions 参数回滚失败的 NfApp。对任何继续失败的 NfApp 的 NfApp 不执行任何操作。此方法允许最终用户对失败的 NfApp 进行故障排除，然后从该点向前重启升级。作为默认行为，此方法是最高效的方法，但在混合版本状态下可能会导致网络函数 (NF) 不一致。

失败时回滚

为了解决 NfApp 版本不匹配的风险，AOSM 现在支持 NF 级别的失败时回滚。启用此选项后，如果 NfApp 操作失败，则失败的 NfApp 和所有之前完成的 NfApp 都可以回滚到初始版本状态。此方法最大程度地减少或消除 NF 暴露给 NfApp 版本不匹配的时间。可选的失败时回滚功能如下所示：

用户启动 sSNS 信誉操作，并启用失败时回滚。
捕获并存储当前 NfApp 版本的快照。
快照用于确定为成功完成的撤消操作而采取的单个 NfApp 操作。
- 已删除组件上的“helm 安装”操作，
- 已升级组件上的“helm 回滚”操作，
- 新安装的组件的“helm 删除”操作
发生 NfApp 失败，AOSM 在升级之前将 NfApps 还原到快照版本状态，并首先还原最新的操作。

注意

如果用户未启用失败时回滚，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 信誉有效负载的一部分。

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 信誉作为错误请求返回。

如何排查失败时回滚问题

了解 Pod 状态

了解不同的 Pod 状态对于有效故障排除至关重要。下面是最常见的 Pod 状态：

挂起：Kubernetes 正在进行 Pod 计划。
正在运行：Pod 中的所有容器都在运行且正常运行。
失败：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 的详细信息，包括状态、关联的存储类以及任何相关事件或错误。

通过