Compartir a través de

Control del comportamiento de errores de actualización

  • Artículo

Información general

En esta guía se describen las características de comportamiento de error de actualización de Azure Operator Service Manager (AOSM) para las funciones de red de contenedor (CNF). Estas características, como parte de la iniciativa de procedimientos de actualización seguros de AOSM, ofrecen una opción entre reintentos más rápidos, con pausa en caso de error, frente a volver al punto de partida, con reversión en caso de error.

Pausar en caso de error

Cualquier actualización mediante AOSM comienza con una reputación del servicio de red de sitio (SNS). La operación de reput procesa las aplicaciones de funciones de red (NfApps) que se encuentran en la versión de diseño de funciones de red (NFDV). La operación de reput implementa la siguiente lógica predeterminada:

  • NfApps se procesa siguiendo el orden updateDependsOn o en el orden secuencial que aparecen.
  • Se omiten nfApps con el parámetro "applicationEnabled" establecido en disable.
  • NfApps presentes, pero no se hace referencia a ellos por el nuevo NFDV se eliminan.
  • La secuencia de ejecución se pausa si se produce un error en alguna de las actualizaciones de NfApp y se considera una reversión.
  • El error deja el recurso NF en un estado de error.

Con pausa en caso de error, AOSM revierte solo la nfApp con errores, a través de los parámetros testOptions, installOptions o upgradeOptions. No se realiza ninguna acción en ninguna NfApps que continúe con el nfApp con errores. Este método permite al usuario final solucionar el error de NfApp y, a continuación, reiniciar la actualización desde ese momento hacia adelante. Como comportamiento predeterminado, este método es el método más eficaz, pero puede provocar incoherencias de función de red (NF) mientras se encuentra en un estado de versión mixta.

Revertir ante un error

Para solucionar el riesgo de que las versiones de NfApp no coincides, AOSM ahora admite la reversión de nivel NF en caso de error. Con esta opción habilitada, si se produce un error en una operación nfApp, se puede revertir el estado de la versión inicial a nfApps con errores y todas las nfApps completadas anteriormente. Este método minimiza o elimina la cantidad de tiempo que el NF se expone a errores de coincidencia de la versión de NfApp. La reversión opcional de la característica de error funciona de la siguiente manera:

  • Un usuario inicia una operación de reput de sSNS y habilita la reversión en caso de error.
  • Se captura y almacena una instantánea de las versiones actuales de NfApp.
  • La instantánea se usa para determinar las acciones individuales de NfApp realizadas para revertir las acciones que se completaron correctamente.
    • Acción de "instalación de Helm" en los componentes eliminados,
    • Acción de "reversión de Helm" en componentes actualizados,
    • Acción "helm delete" en los componentes recién instalados
  • Se produce un error de NfApp, AOSM restaura nfApps al estado de la versión de instantánea antes de la actualización, con las acciones más recientes revertidas primero.

Nota:

  • AOSM no crea una instantánea si un usuario no habilita la reversión en caso de error.
  • Una reversión en caso de error solo se aplica a nfApps completada correctamente.
    • Use los parámetros testOptions, installOptions o upgradeOptions para controlar la reversión de nfApp con errores.

AOSM devuelve el siguiente estado operativo y mensajes, dados los resultados respectivos:

  - 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>

Configuración de la reversión en caso de error

El método más flexible para controlar el comportamiento de los errores es ampliar un nuevo parámetro de esquema de grupo de configuración (CGS), rollbackEnabled, para permitir el control de valor de grupo de configuración (CGV) a través de roleOverrideValues en la carga NF. En primer lugar, defina el parámetro CGS:

{
  "description": "NF configuration",
  "type": "object",
  "properties": {
    "nfConfiguration": {
      "type": "object",
      "properties": {
        "rollbackEnabled": {
          "type": "boolean"
        }
      },
      "required": [
        "rollbackEnabled"
      ]
    }
  }
}

Nota:

  • Si nfConfiguration no se proporciona a través del parámetro roleOverrideValues, de forma predeterminada la reversión está deshabilitada.

Con el nuevo parámetro rollbackEnable definido, el operador ahora puede proporcionar un valor de tiempo de ejecución, en roleOverrideValues, como parte de la carga de reput nf.

example:
{
  "location": "eastus",
  "properties": {
    // ...
    "roleOverrideValues": [
          "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
            "{\"name\":\"nfApp1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",
            "{\"name\":\"nfApp2\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",
          //... other nfapps overrides
       ]
  }
}

Nota:

  • Cada entrada roleOverrideValues invalida el comportamiento predeterminado de NfAapps.
  • Si se encuentran varias entradas de nfConfiguration en roleOverrideValues, la reputación nf se devuelve como una solicitud incorrecta.

Solución de problemas de reversión en caso de error

Descripción de los estados del pod

Comprender los distintos estados de pod es fundamental para una solución de problemas eficaz. A continuación se muestran los estados de pod más comunes:

  • Pendiente: Kubernetes está en curso la programación de pods.
  • En ejecución: todos los contenedores del pod se están ejecutando y en buen estado.
  • Error: uno o varios contenedores del pod finalizan con un código de salida distinto de cero.
  • CrashLoopBackOff: un contenedor dentro del pod se bloquea repetidamente y Kubernetes no puede reiniciarlo.
  • ContainerCreating: el entorno de ejecución del contenedor está en curso para la creación del contenedor.

Comprobación del estado y los registros del pod

En primer lugar, compruebe el estado del pod y los registros mediante un comando kubectl:

$ kubectl get pods
$ kubectl logs <pod-name>

El comando get pods enumera todos los pods del espacio de nombres actual, junto con su estado actual. El comando logs recupera los registros de un pod específico, lo que le permite inspeccionar los errores o excepciones. Para solucionar problemas de red, use los siguientes comandos:

$ kubectl get services
$ kubectl describe service <service-name>

El comando get services muestra todos los servicios del espacio de nombres actual. El comando proporciona detalles sobre un servicio específico, incluidos los puntos de conexión asociados, y los mensajes de error pertinentes. Si tiene problemas con los PVC, puede usar los siguientes comandos para depurarlos:

$ kubectl get persistentvolumeclaims
$ kubectl describe persistentvolumeclaims <pvc-name>

El comando "get persistentvolumeclaims" enumera todos los PVC del espacio de nombres actual. El comando describe proporciona información detallada sobre una PVC específica, incluido el estado, la clase de almacenamiento asociada y los eventos o errores pertinentes.