Dela via

Kontrollera beteende för uppgraderingsfel

  • Artikel

Översikt

Den här guiden beskriver funktionerna för uppgraderingsfel i Azure Operator Service Manager (AOSM) för containernätverksfunktioner (CNFs). Dessa funktioner, som en del av initiativet för säker uppgradering av AOSM, erbjuder ett val mellan snabbare återförsök, med paus vid fel, jämfört med att återgå till startpunkten, med återställning vid fel.

Pausa vid fel

Alla uppgraderingar med hjälp av AOSM börjar med en SNS-beräkningsåtgärd (site network service). Reput-åtgärden bearbetar nätverksfunktionsprogram (NfApps) som finns i NFDV (Network Function Design Version). Reput-åtgärden implementerar följande standardlogik:

  • NfApps bearbetas efter antingen updateDependsOn-ordning eller i den sekventiella ordning de visas.
  • NfApps med parametern "applicationEnabled" inställd på att inaktivera hoppas över.
  • NFApps som finns men som inte refereras till av den nya NFDV tas bort.
  • Körningssekvensen pausas om någon av NfApp-uppgraderingarna misslyckas och en återställning beaktas.
  • Felet lämnar NF-resursen i ett feltillstånd.

Vid paus vid fel återställer AOSM endast den misslyckade NfApp via parametrarna testOptions, installOptions eller upgradeOptions. Ingen åtgärd vidtas på NfApps som fortsätter med den misslyckade NfApp. Med den här metoden kan slutanvändaren felsöka den misslyckade NfApp och sedan starta om uppgraderingen från och med då. Som standardbeteende är den här metoden den mest effektiva metoden, men kan orsaka inkonsekvenser i nätverksfunktionen (NF) när den är i ett blandat versionstillstånd.

Återställning vid fel

För att åtgärda risken för felmatchade NfApp-versioner stöder AOSM nu återställning på NF-nivå vid fel. Om en NfApp-åtgärd misslyckas med det här alternativet kan både den misslyckade NfApp och alla tidigare slutförda NfApps återställas till det ursprungliga versionstillståndet. Den här metoden minimerar eller eliminerar den tid som NF exponeras för felmatchningar i NfApp-versionen. Den valfria återställningen av felfunktionen fungerar på följande sätt:

  • En användare initierar en sSNS-beräkningsåtgärd och aktiverar återställning vid fel.
  • En ögonblicksbild av de aktuella NfApp-versionerna samlas in och lagras.
  • Ögonblicksbilden används för att fastställa de enskilda NfApp-åtgärder som vidtas för omvända åtgärder som har slutförts.
    • Åtgärden "helm install" på borttagna komponenter,
    • "helm rollback"-åtgärd på uppgraderade komponenter,
    • Åtgärden "helm delete" på nyligen installerade komponenter
  • NfApp-fel inträffar, AOSM återställer NfApps till tillståndet för ögonblicksbildversionen före uppgraderingen, med de senaste åtgärderna återställda först.

Kommentar

  • AOSM skapar ingen ögonblicksbild om en användare inte aktiverar återställning vid fel.
  • En återställning vid fel gäller endast för NFApps som har slutförts.
    • Använd parametrarna testOptions, installOptions eller upgradeOptions för att styra återställningen av den misslyckade NfApp.

AOSM returnerar följande driftstatus och meddelanden, baserat på respektive resultat:

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

Så här konfigurerar du återställning vid fel

Den mest flexibla metoden för att kontrollera felbeteendet är att utöka en ny cgs-parameter (configuration group schema), rollbackEnabled, för att tillåta kontroll av konfigurationsgruppsvärde (CGV) via roleOverrideValues i NF-nyttolasten. Definiera först CGS-parametern:

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

Kommentar

  • Om nfConfiguration inte tillhandahålls via parametern roleOverrideValues inaktiveras återställningen som standard.

Med den nya rollbackEnable-parametern definierad kan operatorn nu ange ett körningstidsvärde under roleOverrideValues som en del av nyttolasten för NF-reput.

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

Kommentar

  • Varje roleOverrideValues-post åsidosätter standardbeteendet för NfAapps.
  • Om flera poster i nfConfiguration hittas i roleOverrideValues returneras NF-reput som en felaktig begäran.

Felsöka återställning vid fel

Förstå poddtillstånd

Att förstå de olika poddtillstånden är avgörande för effektiv felsökning. Följande är de vanligaste poddtillstånden:

  • Väntar: Poddschemaläggning pågår av Kubernetes.
  • Körs: Alla containrar i podden körs och är felfria.
  • Misslyckades: En eller flera containrar i podden avslutas med en icke-zero-slutkod.
  • CrashLoopBackOff: En container i podden kraschar upprepade gånger och Kubernetes kan inte starta om den.
  • ContainerSkapa: Containerskapandet pågår av containerkörningen.

Kontrollera poddstatus och loggar

Börja med att kontrollera poddstatus och loggar med hjälp av ett kubectl-kommando:

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

Kommandot hämta poddar visar alla poddar i det aktuella namnområdet, tillsammans med deras aktuella status. Loggkommandot hämtar loggarna för en specifik podd, så att du kan inspektera eventuella fel eller undantag. Om du vill felsöka nätverksproblem använder du följande kommandon:

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

Kommandot hämta tjänster visar alla tjänster i det aktuella namnområdet. Kommandot innehåller information om en specifik tjänst, inklusive associerade slutpunkter och eventuella relevanta felmeddelanden. Om du stöter på problem med datorer kan du använda följande kommandon för att felsöka dem:

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

Kommandot "get persistentvolumeclaims" visar en lista över alla datorer i det aktuella namnområdet. Kommandot describe innehåller detaljerad information om en specifik PVC, inklusive status, tillhörande lagringsklass och eventuella relevanta händelser eller fel.