Freigeben über

Steuern des Verhaltens bei Upgradefehlern

  • Artikel

Übersicht

In diesem Leitfaden werden die von Features Azure Operator Service Manager (AOSM) zum Steuern des Verhaltens bei Upgradefehlern für Containernetzwerkfunktionen (CNFs) beschrieben. Diese Features bieten als Teil der AOSM-Initiative für sichere Upgrademethoden die Wahl zwischen schnelleren Wiederholungen mit „Anhalten bei Fehler“ und der Rückkehr zum Startpunkt mit „Rollback bei Fehler“.

Anhalten bei Fehler

Jedes Upgrade mit AOSM beginnt mit einem Reput-Vorgang des Standortnetzwerkdiensts (Site Network Service, SNS). Der Reput-Vorgang verarbeitet die Netzwerkfunktionsanwendungen (NfApps) in der Netzwerkfunktions-Entwurfsversion (Network Function Design Version, NFDV). Der Reput-Vorgang implementiert die folgende Standardlogik:

  • NfApps werden entweder in der updateDependsOn-Reihenfolge verarbeitet oder in der sequenziellen Reihenfolge, in der sie aufgeführt sind.
  • NfApps, für die der applicationEnabled-Parameter auf „disable“ festgelegt ist, werden übersprungen.
  • NFApps, die vorhanden sind, auf die jedoch nicht in der neuen NFDV verwiesen wird, werden gelöscht.
  • Die Ausführungssequenz wird angehalten, wenn eines der NfApp-Upgrades fehlschlägt und ein Rollback in Erwägung gezogen wird.
  • Durch den Fehler verbleibt die Netzwerkfunktionsressource (NF-Ressource) in einem fehlerhaften Zustand.

Bei „Anhalten bei Fehler“ setzt AOSM nur die fehlerhafte NfApp über die Parameter testOptions, installOptions oder upgradeOptions zurück. Für NfApps, die der fehlerhaften NfApp vorausgehen, werden keine Aktionen durchgeführt. Bei dieser Methode kann der Endbenutzer eine Problembehandlung für die fehlerhafte NfApp durchführen und das Upgrade dann ab diesem Punkt neu starten. Als Standardverhalten ist diese Methode am effizientesten, sie kann jedoch zu Inkonsistenzen der Netzwerkfunktionen (NF) führen, solange gemischte Versionen vorhanden sind.

Rollback bei Fehler

Um dem Risiko nicht übereinstimmender NfApp-Versionen entgegenzuwirken, unterstützt AOSM jetzt das Rollback bei Fehlern auf NF-Ebene. Wenn diese Option aktiviert ist, kann bei einem Fehler eines NfApp-Vorgangs sowohl für die fehlerhafte NfApp als auch alle zuvor abgeschlossenen NfApps ein Rollback auf den ursprünglichen Versionsstatus durchgeführt werden. Diese Methode minimiert bzw. eliminiert die Zeitspanne, in der die Netzwerkfunktion NfApp-Versionskonflikten ausgesetzt ist. Das optionale Feature „Rollback bei Fehler“ funktioniert wie folgt:

  • Ein Benutzer initiiert einen SNS-Reput-Vorgang und aktiviert „Rollback bei Fehler“.
  • Eine Momentaufnahme der aktuellen NfApp-Versionen wird erfasst und gespeichert.
  • Anhand der Momentaufnahme werden die einzelnen NfApp-Aktionen zum Rückgängigmachen erfolgreich abgeschlossener Aktionen bestimmt.
    • Aktion „helm install“ für gelöschte Komponenten
    • Aktion „helm rollback“ für aktualisierte Komponenten
    • Aktion „helm delete“ für neu installierte Komponenten
  • Ein NfApp-Fehler tritt auf, und AOSM stellt die NfApps im Versionsstatus der Momentaufnahme vor dem Upgrade wieder her, wobei die zuletzt ausgeführten Aktionen zuerst zurückgesetzt werden.

Hinweis

  • AOSM erstellt keine Momentaufnahme, wenn der Benutzer „Rollback bei Fehler“ nicht aktiviert.
  • Ein Rollback bei Fehler gilt nur für die erfolgreich abgeschlossenen NFApps.
    • Verwenden Sie die Parameter testOptions, installOptions oder upgradeOptions, um das Rollback der fehlerhaften NfApp zu steuern.

AOSM gibt entsprechend den jeweiligen Ergebnissen den folgenden Betriebsstatus und die folgenden Nachrichten zurück:

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

Konfigurieren von „Rollback bei Fehler“

Die flexibelste Methode zum Steuern des Fehlerverhaltens besteht darin, einen neuen Konfigurationsgruppenschema-Parameter (Configuration Group Schema, CGS) namens rollbackEnabled zu erweitern, damit der Konfigurationsgruppenwert (Configuration Group Value, CGV) über roleOverrideValues in den NF-Nutzdaten gesteuert werden kann. Definieren Sie zunächst den CGS-Parameter:

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

Hinweis

  • Wenn die nfConfiguration nicht über den roleOverrideValues-Parameter bereitgestellt wird, ist das Rollback standardmäßig deaktiviert.

Wenn der neue rollbackEnable-Parameter definiert wurde, kann der Operator jetzt als Teil der NF-Reput-Nutzdaten einen Laufzeitwert unter roleOverrideValues bereitstellen.

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

Hinweis

  • Jeder roleOverrideValues-Eintrag setzt das Standardverhalten der NfAapps außer Kraft.
  • Wenn mehrere Einträge von nfConfiguration im roleOverrideValues-Parameter vorhanden sind, wird der NF-Reput-Vorgang als ungültige Anforderung zurückgegeben.

Problembehandlung für „Rollback bei Fehler“

Grundlegendes zu Podstatus

Das Verständnis der verschiedenen Podstatus ist für eine effektive Problembehandlung entscheidend. Im Folgenden sind die häufigsten Podstatus aufgeführt:

  • Pending: Die Podplanung wird gerade von Kubernetes ausgeführt.
  • Running: Alle Container im Pod werden ausgeführt und sind fehlerfrei.
  • Failed: Mindestens ein Container im Pod wurde mit einem Exitcode ungleich Null beendet.
  • CrashLoopBackOff: Ein Container im Pod stürzt wiederholt ab und kann von Kubernetes nicht neu gestartet werden.
  • ContainerCreating: Die Containererstellung wird gerade von der Containerruntime ausgeführt.

Überprüfen des Podstatus und der Protokolle

Überprüfen Sie zunächst den Podstatus und die Protokolle mit einem kubectl-Befehl:

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

Der Befehl „get Pods“ listet alle Pods im aktuellen Namespace mit ihrem aktuellen Status auf. Der Befehl „logs“ ruft die Protokolle für einen bestimmten Pod ab, sodass Sie Fehler oder Ausnahmen überprüfen können. Verwenden Sie die folgenden Befehle, um Netzwerkprobleme zu beheben:

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

Der Befehl „get services“ zeigt alle Dienste im aktuellen Namespace an. Der Befehl liefert Details zu einem bestimmten Dienst, einschließlich der zugehörigen Endpunkte und relevanten Fehlermeldungen. Wenn Probleme mit persistenten Volumeansprüchen (Persistent Volume Claim, PVC) auftreten, können Sie diese mit den folgenden Befehlen debuggen:

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

Der Befehl „get persistentvolumeclaims“ listet alle PVCs im aktuellen Namespace auf. Der Befehl „describe“ liefert detaillierte Informationen zu einem bestimmten PVC, einschließlich des Status, der zugeordneten Speicherklasse und der relevanten Ereignisse oder Fehler.