Irakurri ingelesez

Partekatu honen bidez:

Introducción a los procedimientos de actualización seguros

  • Artikulua

En este artículo se presentan los procedimientos de actualización seguros (SUP) de Azure Operator Service Manager (AOSM). Este conjunto de características permite a un usuario final ejecutar de forma segura actualizaciones complejas de cargas de trabajo de Container Network Function (CNF) hospedadas en Azure Operator Nexus, conforme a los requisitos de Actualización de software en servicio (ISSU) del asociado, si procede. Busque futuros artículos en estos servicios para expandir las características y funcionalidades de SUP.

Introducción a las actualizaciones seguras

Un servicio de red determinado compatible con Azure Operator Service Manager se compone de una a varias funciones de red basadas en contenedores (CNF) que, con el tiempo, requerirán actualizaciones de software. Para cada actualización, es necesario ejecutar de una a varias operaciones de Helm, actualizando las aplicaciones de funciones de red dependientes (NfApps), en un orden determinado, de manera que afecte lo menos posible al servicio de red. En Azure Operator Service Manager, los procedimientos de actualización segura representan un conjunto de características, que pueden automatizar las operaciones de CNF necesarias para actualizar un servicio de red en Azure Operator Nexus.

  • Actualización de la reputación de un SNS: ejecute la operación de actualización de Helm en todas las NfApps de la NFDV.
  • Nexus Platform: admite operaciones de la reputación de un SNS en los destinos de la plataforma Nexus.
  • Tiempos de espera de operación: capacidad de establecer tiempos de espera operativos para cada operación de NfApp.
  • Operaciones sincrónicas: capacidad de ejecutar una operación de NfApp en serie cada vez.
  • Pausar en caso de error: en función de la marca, establezca el comportamiento de error para revertir solo la última operación de NfApp.
  • Validación de pruebas de gráfico único: ejecutar una operación de prueba de Helm después de crear o actualizar.
  • Refactorización de la reputación de un SNS: métodos mejorados, agrega el orden de actualización y la comprobación de limpieza.
  • Mejora del control de opciones de actualización: exponga parámetros de forma más eficaz.
  • Omisión de NfApp si no hay ningún cambio: omita el procesamiento de NfApps si no hay cambios.
  • Ejecución de la reversión de nivel de NF en caso de error: en función de la marca, revierta todas las NfApps completadas en caso de error.
  • Carga previa de imágenes: capacidad de cargar previamente imágenes en el repositorio perimetral.

Enfoque de actualización segura

Para actualizar un servicio de red de sitio (SNS) de Azure Operator Service Manager existente, el operador ejecuta una solicitud de actualización de reputación en el recurso SNS implementado. Cuando el SNS contiene CNF con varias NfApps, la solicitud se agrupa en todas las NfApps definidas en la versión de definición de función de red (NFDV). De forma predeterminada, en el orden en que aparecen, u opcionalmente, en el orden definido por el parámetro UpdateDependsOn.

Para cada NfApp, la solicitud de actualización de reputación admite el aumento de una versión del gráfico de Helm, la adición o eliminación de valores de Helm o la adición o eliminación de cualquier NfApp. Los tiempos de espera se pueden establecer por cada NfApp, en función de los runtime permitidos conocidos, pero las NfApp solo se pueden procesar en serie, una tras otra. La actualización de reputación implementa la siguiente lógica de procesamiento:

  • NfApps se procesa siguiendo el orden updateDependsOn o en el orden secuencial que aparecen.
  • Se omiten las NfApps con el parámetro applicationEnabled establecido como deshabilitar.
  • Las NfApps con el parámetro skipUpgrade establecido como habilitado se omiten si no se detectan cambios.
  • Las NFApps que son comunes entre NFDV antiguos y nuevos se actualizan.
  • Las NFApps que solo están instaladas en el nuevo NFDV.
  • Las NFApps implementadas, pero no referenciadas por el nuevo NFDV, se eliminan.

Para garantizar los resultados, las pruebas de NfApp se realizan mediante Helm, ya sean pruebas previas o posteriores a la actualización de Helm o pruebas independientes de Helm. En el caso de los errores de las pruebas previas y posteriores, se respeta el parámetro atomic. Con atomic/true, el gráfico con errores se revierte. Con atomic/false, no se ejecuta ninguna reversión. Para obtener más información sobre las pruebas de Helm independientes, consulte el siguiente artículo: Ejecución de pruebas después de la instalación o actualización

Consideraciones para las actualizaciones en el servicio

Azure Operator Service Manager generalmente es compatible en las actualizaciones de servicio, un método de actualización que avanza una versión de implementación sin interrumpir el servicio en ejecución. Son necesarias algunas consideraciones para garantizar el comportamiento adecuado de AOSM durante las operaciones de la ISSU.

  • Cuando AOSM realiza una actualización en un conjunto ordenado de varias nfApps, AOSM primero actualiza o crea todas las nfApps nuevas y después elimina todas las nfApps antiguas. Este enfoque garantiza que el servicio no se vea afectado hasta que todas las nuevas nfApps estén listas, pero requiere una capacidad extra de la plataforma para hospedar de forma transitoria tanto las nfApps antiguas como las nuevas.
  • Cuando AOSM actualiza una NfApp con múltiples réplicas, AOSM respeta la configuración del perfil de implementación para la opción de actualización progresiva o recreación. Si se usa la actualización progresiva, exponga los valores de maxUnavailable y maxSurge como parámetros CGS, que después pueden establecerse mediante el operador CGV en tiempo de ejecución.

En última instancia, la posibilidad de que un determinado servicio se actualice sin interrupciones es una característica del propio servicio. Consulte más a fondo con el editor del servicio para comprender las capacidades de actualización en servicio y garantizar que están alineadas con las opciones de comportamiento adecuadas de AOSM.

Requisitos previos de actualización segura

Cuando planifique una actualización mediante Azure Operator Service Manager, solucione los siguientes requisitos antes de la ejecución de la actualización para optimizar el tiempo dedicado a intentar la actualización.

  • Incorpore artefactos actualizados mediante flujos de trabajo de editor o diseñador.

    • El editor, el almacén, el diseño del servicio de red (NSDg) y el grupo de diseño de la función de red (NFDg) son estáticos y no necesitan cambiar.
      • Se necesita un nuevo manifiesto de artefacto para almacenar los nuevos gráficos e imágenes. Para más información, consulte la documentación de incorporación para obtener detalles sobre cómo cargar nuevos gráficos e imágenes.
    • Se necesitan nuevas versiones de la NFDV y de diseño de servicios de red (NSDV), en el marco del NFDg y NSDg existentes.
      • Tratamos los cambios básicos en la NFDV en la sección paso a paso.
      • El nuevo NSDV solo es necesario si se introduce una nueva versión de esquema de grupo de configuración (CGS).
    • Si es necesario, nuevo CGS.
      • Obligatorio si una actualización introduce nuevos parámetros de configuración expuestos.

  • Cree artefactos actualizados mediante el flujo de trabajo del operador.

    • Si es necesario, cree nuevos valores de grupo de configuración (CGV) basados en el nuevo CGS.
    • Reutilice y cree una carga útil confirmando los objetos de servicio del sitio y de la red del sitio existentes.

  • Actualice las plantillas para garantizar que los parámetros de actualización se establecen en función de la confianza en la actualización y el comportamiento de error deseado.

    • La configuración usada para producción puede suprimir los detalles de los errores, mientras que la configuración usada para la depuración o las pruebas puede optar por exponer estos detalles.

Procedimiento de actualización segura

Siga el siguiente proceso para desencadenar una actualización con Azure Operator Service Manager.

Creación de un nuevo recurso NFDV

Para las nuevas versiones de la NFDV, debe estar en un formato SemVer válido, en el que solo se permitan valores de incremento superiores de actualizaciones de revisión y versiones menores. No se permite una versión de la NFDV inferior. Dada una CNF implementada mediante NFDV 2.0.0, la nueva NFDV puede ser de la versión 2.0.1, o 2.1.0, pero no 1.0.0, o 3.0.0.

Actualización de nuevos parámetros de la NFDV

Las versiones del gráfico de Helm se pueden actualizar o los valores de Helm se pueden actualizar o parametrizar según sea necesario. También se pueden agregar nuevas NfApps cuando no existían en la versión implementada.

Actualización de la NFDV para el pedido de NfApp deseado

UpdateDependsOn es un parámetro de NFDV que se usa para especificar el orden de NfApps durante las operaciones de actualización. Si no se proporciona UpdateDependsOn, se usa el orden en serie de las aplicaciones de CNF, tal como aparece en la NFDV.

Actualización de la NFDV para el comportamiento de actualización deseado

Asegúrese de establecer los tiempos de espera de aplicación de CNF deseados, el parámetro atomic y el parámetro rollbackOnTestFailure. Puede ser útil cambiar estos parámetros a lo largo del tiempo, ya que se obtiene más confianza en la actualización.

Problema de reputación de un SNS

Una vez completada la incorporación, se envía la operación de reputación. Según el número, el tamaño y la complejidad de las NfApps, la operación de reputación puede tardar un tiempo en completarse (varias horas).

Examen de los resultados de reputación

Si se notifica un resultado correcto, la actualización se completa y el usuario debe validar el estado y la disponibilidad del servicio. Si se notifica un error, siga los pasos descritos en la sección recuperación de errores de actualización para continuar.

Procedimiento de reintento de actualización segura

En los casos en los que se produce un error en una actualización de reputación, se puede seguir el siguiente proceso para reintentar la operación.

Diagnóstico de una NfApp con errores

Resuelva la causa principal del error de la NfApp mediante el análisis de registros y otra información de depuración.

Omisión manual de los gráficos completados

Después de corregir el error de la NfApp, pero antes de reintentar la actualización, considere la posibilidad de cambiar el parámetro applicationEnablement para acelerar el comportamiento del reintento. Este parámetro se puede establecer en false, donde se debe omitir una NfApp. Este parámetro puede ser útil cuando una NfApp no requiere una actualización.

Reintentos de reputación de un SNS (repetir hasta que se realiza correctamente)

De forma predeterminada, la reputación reintenta NfApps en el orden de actualización declarado, a menos que se omitan mediante la marca applicationEnablement.

Omitir nfApps mediante applicationEnablement

En el recurso de NFDV, en deployParametersMappingRuleProfile hay la propiedad applicationEnablement de tipo de enumeración, que toma valores: Desconocido, Habilitado o Deshabilitado. Se puede usar para excluir las operaciones de NfApp durante la implementación de la función de red (NF).

Cambios del publicador

En el caso de la propiedad applicationEnablement, el publicador tiene dos opciones: proporcionar un valor predeterminado o parametrizarlo.

NFDV de ejemplo

El publicador usa NFDV para establecer valores predeterminados para applicationEnablement.

JSON 
{ 
      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
          {
            "artifactProfile": {
              "helmArtifactProfile": { 
                "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role1releasenamespace}",
                "releaseName": "{deployParameters.role1releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest"
          },
          {
            "artifactProfile": {
              "helmArtifactProfile": {
                 "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role2releasenamespace}",
                "releaseName": "{deployParameters.role2releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest1"
          }
        ],
        "nfviType": "AzureArcKubernetes"
      },
      "description": "null",
      "deployParameters": {"type":"object","properties":{"role1releasenamespace":{"type":"string"},"role1releasename":{"type":"string"},"role2releasenamespace":{"type":"string"},"role2releasename":{"type":"string"}},"required":["role1releasenamespace","role1releasename","role2releasenamespace","role2releasename"]},
      "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

Recurso de esquema de grupo de configuración (CGS) de ejemplo

El editor usa CGS para exigir que el operador proporcione una variable roleOverrideValues en tiempo de ejecución. RoleOverrideValues puede incluir valores que no son predeterminados para applicationEnablement.

JSON 
{
  "type": "object",
  "properties": {
    "location": {
      "type": "string"
    },
    "nfviType": {
      "type": "string"
    },
    "nfdvId": {
      "type": "string"
    },
    "helloworld-cnf-config": {
      "type": "object",
      "properties": {
        "role1releasenamespace": {
          "type": "string"
        },
        "role1releasename": {
          "type": "string"
        },
        "role2releasenamespace": {
          "type": "string"
        },
        "role2releasename": {
          "type": "string"
        },
        "roleOverrideValues1": {
          "type": "string"
        },
        "roleOverrideValues2": {
          "type": "string"
        }
      },
      "required": [
        "role1releasenamespace",
        "role1releasename",
        "role2releasenamespace",
        "role2releasename",
        "roleOverrideValues1",
        "roleOverrideValues2"
      ]
    }
  },
  "required": [
    "nfviType",
    "nfdvId",
    "location",
    "helloworld-cnf-config"
  ]
}

Cambios del operador

Los operadores heredan los valores applicationEnablement predeterminados tal y como se definen en NFDV. Si applicationEnablement está parametrizado en CGS, debe pasarse a través de la propiedad deploymentValues en tiempo de ejecución.

Recurso de valor de grupo de configuración (CGV) de ejemplo

El operador utiliza CGV para establecer las variables roleOverrideValues en tiempo de ejecución. RoleOverrideValues incluye valores que no son predeterminados para applicationEnablement.

JSON 
{
  "location": "<location>",
  "nfviType": "AzureArcKubernetes",
  "nfdvId": "<nfdv_id>",
  "helloworld-cnf-config": {
    "role1releasenamespace": "hello-test-releasens",
    "role1releasename": "hello-test-release",
    "role2releasenamespace": "hello-test-2-releasens",
    "role2releasename": "hello-test-2-release",
    "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\"}}"
  }
}

Plantilla de ARM NF de ejemplo

El operador usa la plantilla de ARM NF para enviar la variable roleOverrideValues, establecidas por CGV, en el proveedor de recursos (RP). El operador puede cambiar la configuración applicationEnablement en CGV, según sea necesario, y volver a enviar la misma plantilla de ARM NF, para modificar el comportamiento entre iteraciones.

JSON 
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "nameValue": {
      "type": "string",
      "defaultValue": "HelloWorld"
    },
    "locationValue": {
      "type": "string",
      "defaultValue": "eastus"
    },
    "nfviTypeValue": {
      "type": "string",
      "defaultValue": "AzureArcKubernetes"
    },
    "nfviIdValue": {
      "type": "string"
    },
    "config": {
      "type": "object",
      "defaultValue": {}
    },
    "nfdvId": {
      "type": "string"
    }
  },
  "variables": {
    "deploymentValuesValue": "[string(createObject('role1releasenamespace', parameters('config').role1releasenamespace, 'role1releasename',parameters('config').role1releasename, 'role2releasenamespace', parameters('config').role2releasenamespace, 'role2releasename',parameters('config').role2releasename))]",
    "nfName": "[concat(parameters('nameValue'), '-CNF')]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
    {
      "type": "Microsoft.HybridNetwork/networkFunctions",
      "apiVersion": "2023-09-01",
      "name": "[variables('nfName')]",
      "location": "[parameters('locationValue')]",
      "properties": {
        "networkFunctionDefinitionVersionResourceReference": {
          "id": "[parameters('nfdvId')]",
          "idType": "Open"
        },
        "nfviType": "[parameters('nfviTypeValue')]",
        "nfviId": "[parameters('nfviIdValue')]",
        "allowSoftwareUpdate": true,
        "configurationType": "Open",
        "deploymentValues": "[string(variables('deploymentValuesValue'))]",
        "roleOverrideValues": [
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
      }
    }
  ]
}

Omitir NfApps que no tienen ningún cambio

La característica skipUpgrade está diseñada para optimizar el tiempo necesario para las actualizaciones de CNF. Cuando el publicador habilita esta marca en roleOverrideValues en upgradeOptions, el nivel de servicio de AOSM realiza determinadas comprobaciones previas para determinar si se puede omitir una actualización de un elemento nFApplication específico. Si se cumplen todos los criterios de comprobación previa, se omite la actualización para esa aplicación. De lo contrario, se ejecuta una actualización en el nivel de clúster.

Criterios de comprobación previa

Se puede omitir una actualización si se cumplen todas las condiciones siguientes:

  1. El estado de aprovisionamiento de nfApplication es Correcto.
  2. No hay ningún cambio en el nombre o la versión del gráfico de Helm.
  3. No hay ningún cambio en los valores de Helm.

Habilitación o deshabilitación de la característica skipUpgrade

La característica skipUpgrade está deshabilitada de manera predeterminada. Si este parámetro opcional no se especifica en roleOverrideValues en upgradeOptions, las actualizaciones de CNF continúan de la manera tradicional, donde se actualizan nfApplications en el nivel de clúster.

Habilitación de SkipUpgrade con el recurso de función de red

Para habilitar la característica SkipUpgrade mediante roleOverrideValues, consulte el ejemplo siguiente.

JSON 
{
    "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\"}}}}}"
        ]
    }
}

Explicación del ejemplo

  • NfApplication: hellotest
    • La marca skipUpgrade está habilitada. Si la solicitud de actualización de hellotest cumple los criterios de comprobación previa, la actualización se omitirá.
  • NfApplication: runnerTest
    • No se ha especificado la marca skipUpgrade. Por tanto, runnerTest ejecuta una actualización tradicional de Helm en el nivel de clúster, incluso si se cumplen los criterios de comprobación previa.