Delen via

Gedrag van upgradefouten beheren

  • Artikel

Overzicht

In deze handleiding worden de AOSM-functies (Azure Operator Service Manager) voor het gedrag van upgradefouten voor containernetwerkfuncties (CNF's) beschreven. Deze functies bieden, als onderdeel van het initiatief voor veilige upgradeprocedures van AOSM, een keuze tussen snellere nieuwe pogingen, met onderbreking bij mislukte pogingen, versus terugkeer naar het beginpunt, met terugdraaien op fouten.

Onderbreken bij fout

Elke upgrade met behulp van AOSM begint met een SNS-reputatie (Site Network Service). De reput-bewerking verwerkt de netwerkfunctietoepassingen (NfApps) in de ontwerpversie van de netwerkfunctie (NFDV). Met de reput-bewerking wordt de volgende standaardlogica geïmplementeerd:

  • NfApps worden verwerkt volgens updateDependsOn-volgorde of in de volgorde waarin ze worden weergegeven.
  • NfApps met parameter ApplicationEnabled die is ingesteld om uit te schakelen, worden overgeslagen.
  • NFApps aanwezig, maar niet waarnaar wordt verwezen door de nieuwe NFDV worden verwijderd.
  • De uitvoeringsvolgorde wordt onderbroken als een van de NfApp-upgrades mislukt en een terugdraaiactie wordt overwogen.
  • De fout laat de NF-resource in een mislukte status.

Als de onderbreking is mislukt, wordt alleen de mislukte NfApp teruggedraaid via de parameters testOptions, installOptions of upgradeOptions. Er wordt geen actie ondernomen voor NfApps die de mislukte NfApp voortzetten. Met deze methode kan de eindgebruiker problemen met de mislukte NfApp oplossen en vervolgens de upgrade vanaf dat moment opnieuw starten. Als standaardgedrag is deze methode de meest efficiënte methode, maar kan dit leiden tot inconsistenties van de netwerkfunctie (NF) in een gemengde versiestatus.

Terugdraaien op fout

Om het risico op niet-overeenkomende NfApp-versies te verhelpen, biedt AOSM nu ondersteuning voor terugdraaien op NF-niveau bij fouten. Als deze optie is ingeschakeld, kunnen zowel de mislukte NfApp als alle eerdere voltooide NfApps worden teruggedraaid naar de status van de eerste versie als een NfApp-bewerking mislukt. Deze methode minimaliseert of elimineert de hoeveelheid tijd die de NF blootstelt aan niet-overeenkomende NfApp-versies. De optionele terugdraaiactie voor de foutfunctie werkt als volgt:

  • Een gebruiker initieert een sSNS-reput-bewerking en schakelt terugdraaien in op fouten.
  • Een momentopname van de huidige NfApp-versies wordt vastgelegd en opgeslagen.
  • De momentopname wordt gebruikt om de afzonderlijke NfApp-acties te bepalen die zijn uitgevoerd om acties om te keren die zijn voltooid.
    • "Helm install" actie op verwijderde onderdelen,
    • Actie 'helm terugdraaien' op bijgewerkte onderdelen,
    • Actie 'Helm verwijderen' op nieuw geïnstalleerde onderdelen
  • NfApp-fout treedt op, AOSM herstelt de NfApps naar de status van de momentopnameversie vóór de upgrade, waarbij de meest recente acties eerst zijn teruggezet.

Notitie

  • AOSM maakt geen momentopname als een gebruiker het terugdraaien van fouten niet inschakelt.
  • Een fout bij terugdraaien is alleen van toepassing op de voltooide NFApps.
    • Gebruik de parameters testOptions, installOptions of upgradeOptions om het terugdraaien van de mislukte NfApp te beheren.

AOSM retourneert de volgende operationele status en berichten, op basis van de respectieve resultaten:

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

Terugdraaien configureren bij fout

De meest flexibele methode voor het beheren van foutgedrag is het uitbreiden van een nieuwe CGS-parameter (Configuration Group Schema), rollbackEnabled, om CGV-beheer (Configuration Group Value) toe te staan via roleOverrideValues in de NF-nettolading. Definieer eerst de CGS-parameter:

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

Notitie

  • Als de nfConfiguration niet is opgegeven via de parameter roleOverrideValues, is het terugdraaien standaard uitgeschakeld.

Nu de nieuwe parameter rollbackEnable is gedefinieerd, kan de operator nu een runtimewaarde opgeven, onder roleOverrideValues, als onderdeel van de nettolading van de NF-opslagplaats.

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

Notitie

  • Elke roleOverrideValues-vermelding overschrijft het standaardgedrag van de NfAapps.
  • Als er meerdere vermeldingen van nfConfiguration worden gevonden in de roleOverrideValues, wordt de NF-reput geretourneerd als een ongeldige aanvraag.

Problemen met terugdraaien bij fouten oplossen

Podstatussen begrijpen

Inzicht in de verschillende podstatussen is van cruciaal belang voor effectieve probleemoplossing. Hier volgen de meest voorkomende podstatussen:

  • In behandeling: Podplanning wordt uitgevoerd door Kubernetes.
  • Wordt uitgevoerd: Alle containers in de pod worden uitgevoerd en in orde.
  • Mislukt: een of meer containers in de pod worden beëindigd met een niet-nul-afsluitcode.
  • CrashLoopBackOff: een container binnen de pod loopt herhaaldelijk vast en Kubernetes kan deze niet opnieuw opstarten.
  • ContainerCreating: het maken van een container wordt uitgevoerd door de containerruntime.

Status en logboeken van pods controleren

Begin eerst met het controleren van de podstatus en logboeken met behulp van een kubectl-opdracht:

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

Met de opdracht pods ophalen worden alle pods in de huidige naamruimte weergegeven, samen met hun huidige status. Met de logboekopdracht worden de logboeken voor een specifieke pod opgehaald, zodat u eventuele fouten of uitzonderingen kunt inspecteren. Gebruik de volgende opdrachten om netwerkproblemen op te lossen:

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

Met de opdracht Get Services worden alle services in de huidige naamruimte weergegeven. De opdracht bevat details over een specifieke service, inclusief de bijbehorende eindpunten en eventuele relevante foutberichten. Als u problemen ondervindt met PVC's, kunt u de volgende opdrachten gebruiken om fouten op te sporen:

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

Met de opdracht 'get persistentvolumeclaims' worden alle HPC's in de huidige naamruimte weergegeven. De beschrijvende opdracht bevat gedetailleerde informatie over een specifiek PVC, inclusief de status, de bijbehorende opslagklasse en eventuele relevante gebeurtenissen of fouten.