Introducción a los procedimientos de actualización seguros

En este artículo se presentan los procedimientos de actualización seguros (SUP) de Azure Operator Service Manager (AOSM). Este conjunto de características habilita las actualizaciones a una función de red de contenedor compleja (CNF) hospedada en El operador de Azure Nexus. Estas actualizaciones generalmente admiten los métodos y requisitos de actualización de software de servicio (ISSU). Aunque en este artículo se presentan conceptos básicos, busque otros artículos que expandan las características y funcionalidades avanzadas de SUP.

Introducción a las actualizaciones seguras

Un servicio de red determinado compatible con AOSM, compuesto de uno a varios CNF, incluye componentes que, con el tiempo, requieren cambios de configuración o software. Para realizar estos cambios en el nivel de componente, es necesario ejecutar una a muchas operaciones de Helm, actualizando cada aplicación de función de red (nfApp) en un orden determinado y de una manera que afecte menos al servicio de red. Los procedimientos de actualización seguros de AOSM aplican las siguientes funcionalidades de alto nivel para controlar los requisitos de proceso de actualización y flujo de trabajo:

• Compatibilidad con la reputación SNS: ejecute la operación de actualización de Helm en todas las nfApps en la versión de diseño de función de red (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 nfApp.
• Operaciones sincrónicas: capacidad de ejecutar una operación nfApp serie a la vez.
• Orden de actualización de control: defina una secuencia nfApp diferente para instalar y actualizar.
• Pausar en caso de error: el comportamiento predeterminado se detiene después de un error en la operación nfApp.
• Reversión en caso de error: comportamiento opcional, la reversión completó nfApps antes de que se produjera un error en nfApp.
• Validación de pruebas de gráfico único: ejecutar una operación de prueba de Helm después de crear o actualizar.
• Omisión de NfApp si no hay ningún cambio: omita el procesamiento de NfApps si no hay cambios.
• 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 AOSM existente, el operador ejecuta una solicitud de reput 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, o opcionalmente, en el orden definido por updateDependsOn el parámetro .

Para cada nfApp, la solicitud de reput admite varios cambios, como aumentar una versión del gráfico de Helm, agregar o quitar valores de Helm o agregar o quitar cualquier nfApps. Aunque los tiempos de espera se pueden establecer por nfApp, en función de los entornos de ejecución permitidos conocidos, nfApps solo se puede procesar en orden serie, uno después del otro. La actualización de reputación implementa la siguiente lógica de procesamiento:

• nfApps se procesan siguiendo el updateDependsOn orden o en el orden secuencial que aparecen.
• se omiten nfApps con el parámetro applicationEnabled establecido en deshabilitar.
• nfApps con el parámetro skipUpgrade establecido en enabled se omiten si no se detecta ningún cambio.
• nfApps que son comunes entre NFDV antiguo y nuevo se actualizan mediante helm upgrade.
• nfApps que solo están en el nuevo NFDV se instalan mediante helm install.
• NfApps implementado, pero no al que hace referencia el nuevo NFDV, se eliminan mediante helm delete.

Para garantizar los resultados, las pruebas nfApp se admiten mediante métodos de Helm, ya sea pruebas desencadenadas por enlaces previos o posteriores de Helm, o mediante el enlace de pruebas de Helm independiente. Para un error de enlace previo o posterior, se respeta el atomic parámetro . Con atomic/true, el gráfico con errores se revierte. Con atomic/false, no se ejecuta ninguna reversión. Para un error de enlace de prueba de Helm independiente, rollbackOnTestFailure se respeta , siguiendo una lógica similar a atomic. 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

Cuando se produce un error en la operación nfApp y después de que se controle nfApp con errores a través atomic de parámetros o rollbackOnTestFailure , el operador puede controlar el comportamiento sobre cómo controlar cualquier nfApps cambiado antes de que se produzca un error en nfApp. Con el error en pausa, el operador puede forzar que AOSM se interrumpa después de solucionar el error nfApp, conservando el entorno de versión mixta. Con la reversión en caso de error, el operador puede forzar a AOSM a revertir cualquier nfApp anterior, restaurando la instantánea de entorno original. Para obtener más información sobre el control del comportamiento de errores de actualización, consulte el siguiente artículo: Control del comportamiento de errores de 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. Algunas consideraciones sobre el propietario de la función de red son necesarias para garantizar el comportamiento adecuado de AOSM durante las operaciones DE EMISIÓN.

• 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 nfApps nuevas estén listas, pero requiere capacidad adicional de plataforma para el hospedaje transitorio de nfApps antiguos y nuevos.
• 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 de servicios para comprender las capacidades de actualización mientras el servicio está en uso y validar que estén alineadas con las opciones adecuadas de comportamiento de AOSM.

Requisitos previos de actualización segura

Al planear una actualización mediante AOSM, solucione los siguientes requisitos de antemano de la ejecución de la actualización, para optimizar el tiempo invertido en intentar y garantizar el éxito de la actualización.

• Incorpore artefactos actualizados mediante flujos de trabajo de editor o diseñador.
  • En la mayoría de los casos, use el publicador existente para hospedar nuevos artefactos de versión.
    • El uso de un publicador existente admite helm upgrade para actualizar un SNS a una versión diferente.
    • El uso de un nuevo publicador requiere un helm delete en el SNS actual y, a continuación, un helm install para la nueva versión de SNS.
  • El almacén de artefactos, el grupo de diseño de servicios de red (NSDG) y el grupo de diseño de funciones de red (NFDG) son inmutables y no pueden cambiar.
    • Cambiar uno de estos recursos requiere la implementación de un nuevo SNS.
  • Se necesita un nuevo manifiesto de artefacto para almacenar los nuevos gráficos e imágenes.
    • Consulte la documentación de incorporación para obtener más información sobre cómo cargar nuevos gráficos e imágenes.
  • Se necesita una nueva NFDV y, opcionalmente, una nueva versión de diseño del servicio de red (NSDV).
    • Los cambios de NFDV pueden ser complejos. Solo tratamos los cambios básicos de este artículo.
    • 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 AOSM.

• Creación de un nuevo recurso NFDV
  • Para las nuevas versiones de NFDV, debe tener un formato SemVer válido. La nueva versión puede ser una actualización, un valor mayor frente a la versión implementada o una degradación, un valor inferior frente a la versión implementada. La nueva versión puede diferir en función de los valores principales, secundarios o de parche.
• Actualización de nuevos parámetros 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. Se pueden agregar nuevas nfApps en lugares donde no existían en la versión implementada.
• Actualización de NFDV para el orden de nfApp deseado
  • UpdateDependsOn es un parámetro NFDV que se usa para especificar el orden de nfApps durante las operaciones de actualización. Si updateDependsOn no se proporciona, se usa el orden en serie de las aplicaciones CNF, tal como aparece en NFDV.
• Actualización de la plantilla de ARM para el comportamiento de actualización deseado
  • Asegúrese de establecer cualquier aplicación timeoutCNF deseada, el parámetro atomic y el parámetrorollbackOnTestFailure. 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 reputaciones de 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 nfApps, la operación de reput puede tardar algún tiempo en completarse (varias horas).
• Examen de los resultados de reput
  • 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 nfApp con errores
  • Resuelva la causa principal del error de nfApp mediante el análisis de registros y otra información de depuración.
• Omitir manualmente los gráficos completados
  • Después de arreglar la nfApp fallida, pero antes de intentar un reintento de actualización, considere cambiar el parámetro applicationEnablement para acelerar el comportamiento de reintento. Este parámetro se puede establecer en false, en cuyo caso se debería omitir una nfApp. Este parámetro puede ser útil cuando una nfApp no requiere una actualización.
• Reintentos de reputaciones de SNS (repetir hasta que se realiza correctamente)
  • De manera predeterminada, la reputación vuelve a intentar nfApps en el orden de actualización declarado, a menos que se omitan mediante el indicador applicationEnablement.

Controlar los tiempos de espera con installOptions y UpgradeOptions

Cuando se inicia helm install una operación de SNS o , helm upgradese usa un valor de tiempo de espera predeterminado de 27 minutos. Aunque este valor se puede personalizar en el nivel de función de red global (NF), se recomienda personalizar este valor en el nivel NF del componente mediante roleOverrideValues en la plantilla de carga NF de NF. La exposición adicional de en roleOverrideValues CGS/CGV permite el control por parte del operador en tiempo de ejecución. En el ejemplo siguiente se muestran los parámetros installOptions y upgradeOptions admitidos aplicados en dos componentes de nfApp;

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

Omitir nfApps mediante applicationEnablement

En el recurso NFDV, en deployParametersMappingRuleProfile hay una propiedad applicationEnablement admitida de tipo enum, que toma valores de Unknown, Enabled o disabled. Se puede usar para excluir manualmente las operaciones nfApp durante la implementación de funciones de red. En el ejemplo siguiente se muestra un método genérico para parametrizar applicationEnablement como un valor incluido en la roleOverrideValues propiedad .

Cambios en la plantilla NFDV

Aunque no se requieren cambios de NFDV necesariamente, opcionalmente, el publicador puede usar NFDV para establecer un valor predeterminado para la applicationEnablement propiedad . Se usa el valor predeterminado, a menos que cambie a través de roleOverrideValues. Use la plantilla NFDV para establecer un valor predeterminado para applicationEnablement. En el ejemplo siguiente se establece el estado enabled como valor predeterminado para networkfunctionApplication hellotest.

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

Para administrar el applicationEnablement valor de forma más dinámica, el operador puede pasar un valor en tiempo real mediante la propiedad de plantilla roleOverrideValues NF. Aunque es posible que el operador manipule directamente la plantilla NF, en su lugar parametrice , roleOverrideValuespara que los valores se puedan pasar a través de una plantilla de CGV en tiempo de ejecución. En los ejemplos siguientes se muestran las modificaciones necesarias en el CGS, las plantillas NF y, por último, el CGV.

Cambios en la plantilla de CGS

La plantilla de CGS debe actualizarse para incluir una declaración de variable para cada línea para parametrizar en roleOverrideValues. En el ejemplo siguiente se muestran tres valores de invalidación.

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

Cambios en la plantilla de carga de NF

La plantilla NF debe actualizarse de tres maneras. En primer lugar, el parámetro de configuración implícito debe definirse como objeto de tipo. En segundo lugar, roleOverrideValues0, roleOverrideValues1y roleOverrideValues2 se deben declarar como variables asignadas al parámetro config. En tercer lugar, roleOverrideValues0se debe hacer referencia a , roleOverrideValues1y roleOverrideValues2 para la sustitución en roleOverrideValues orden adecuado y seguir la sintaxis adecuada.

  "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')]"
        ]
   }

Cambios en la plantilla de CGV

La plantilla de CGV ya se puede actualizar para incluir el contenido de cada variable que se va a sustituir en la propiedad roleOverrideValues en tiempo de ejecución. En el ejemplo siguiente se establece rollbackEnabled en true, seguido de conjuntos de invalidaciones para hellotest y 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\"}}"
}

Con este marco en funcionamiento, el operador puede gestionar cualquiera de los roleOverrideValues mediante simples actualizaciones del CGV, y luego adjuntar ese CGV a la operación SNS deseada.

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:

• El estado de aprovisionamiento de nfApplication es Correcto.
• No hay ningún cambio en el nombre o la versión del gráfico de Helm.
• 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 bajo upgradeOptions, las actualizaciones de CNF continúan de la manera tradicional, donde nfApplications son actualizados 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.

{
    "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 especifica la skipUpgrade marca . 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.

Referencia de la opción roleOverrideValues completa

Reunir todos los ejemplos de este y otros artículos, la siguiente referencia muestra todas las opciones admitidas actualmente disponibles a través del roleOverrideValues mecanismo.

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