Sdílet prostřednictvím

Řízení chování při selhání upgradu

  • Článek

Přehled

Tato příručka popisuje funkce chování při selhání upgradu Azure Operator Service Manageru (AOSM) pro síťové funkce kontejneru (CNF). Tyto funkce, které jsou součástí iniciativy postupů bezpečného upgradu AOSM, nabízejí možnost mezi rychlejšími opakováními s pozastavením při selhání a návratem do výchozího bodu a vrácením zpět při selhání.

Pozastavení při selhání

Všechny upgrady využívající AOSM začínají pověstí služby SNS (Site Network Service). Důvěryhodná operace zpracovává aplikace síťových funkcí (NfApps) nalezené ve verzi návrhu síťové funkce (NFDV). Operace reputace implementuje následující výchozí logiku:

  • NfApps se zpracovávají buď podle pořadí updateDependsOn, nebo v sekvenčním pořadí, v jakém se zobrazují.
  • NfApps s parametrem applicationEnabled nastaveným na zakázání se přeskočí.
  • Aplikace NFApps, na které nový NFDV neodkazuje, se odstraní.
  • Pořadí provádění se pozastaví, pokud některý z upgradů NfApp selže a považuje se za vrácení zpět.
  • Selhání ponechá prostředek NF ve stavu selhání.

S pozastavením při selhání vrátí AOSM zpět pouze neúspěšnou aplikaci NfApp prostřednictvím parametrů testOptions, installOptions nebo upgradeOptions. U žádné aplikace NfApps není provedena žádná akce, která by pokračovala v neúspěšné aplikaci NfApp. Tato metoda umožňuje koncovému uživateli řešit potíže s chybou NfApp a poté restartovat upgrade z tohoto bodu dopředu. Jako výchozí chování je tato metoda nejúčinnější metodou, ale může způsobit nekonzistence síťových funkcí (NF) ve smíšeném stavu verze.

Vrácení zpět při selhání

Pro řešení rizika neshodovaných verzí NfApp teď AOSM podporuje vrácení zpět na úrovni NF při selhání. Pokud je tato možnost povolená, pokud operace NfApp selže, NfApp i všechny předchozí dokončené aplikace NfApps se dají vrátit zpět do počátečního stavu verze. Tato metoda minimalizuje nebo eliminuje dobu, po kterou je NF vystavena neshodám verzí NfApp. Volitelná funkce vrácení zpět při selhání funguje takto:

  • Uživatel zahájí operaci sSNS s reputací a povolí vrácení zpět při selhání.
  • Snímek aktuálních verzí NfApp je zachycen a uložen.
  • Snímek se používá k určení jednotlivých akcí NfApp provedených k obrácení akcí, které byly úspěšně dokončeny.
    • Akce "helm install" u odstraněných komponent,
    • Akce "helm rollback" u upgradovaných komponent,
    • Akce helm delete u nově nainstalovaných komponent
  • K selhání NfApp dojde, AOSM obnoví NfApps do stavu verze snímku před upgradem, přičemž poslední akce se nejprve vrátí.

Poznámka:

  • AOSM nevytvoří snímek, pokud uživatel nepovolí vrácení zpět při selhání.
  • Vrácení zpět při selhání se vztahuje pouze na úspěšně dokončené aplikace NFApps.
    • Pomocí parametrů testOptions, installOptions nebo upgradeOptions můžete řídit vrácení zpět neúspěšné aplikace NfApp.

AOSM vrátí následující provozní stav a zprávy s ohledem na příslušné výsledky:

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

Postup konfigurace vrácení zpět při selhání

Nejflexibilnější metodou řízení chování při selhání je rozšíření nového parametru schématu skupiny konfigurace (CGS), vrácení zpětEnabled, aby bylo možné řídit hodnotu skupiny konfigurace (CGV) prostřednictvím roleOverrideValues v datové části NF. Nejprve definujte parametr CGS:

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

Poznámka:

  • Pokud nfConfiguration není k dispozici prostřednictvím parametru roleOverrideValues, ve výchozím nastavení je vrácení zpět zakázáno.

S novým parametrem rollbackEnable definovaným operátorem teď může poskytovat hodnotu doby běhu v rámci roleOverrideValues jako součást datové části s reputací NF.

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

Poznámka:

  • Každá položka roleOverrideValues přepíše výchozí chování NfAapps.
  • Pokud se v roleOverrideValues najde více položek nfConfiguration, vrátí se reputace NF jako chybný požadavek.

Řešení potíží se vrácením zpět při selhání

Principy stavů podů

Pochopení různých stavů podů je zásadní pro efektivní řešení potíží. Mezi nejběžnější stavy podů patří:

  • Čekající: Plánování podů probíhá v Kubernetes.
  • Spuštěno: Všechny kontejnery v podu jsou spuštěné a v pořádku.
  • Selhání: Jeden nebo více kontejnerů v podu se ukončí s nenulovým ukončovacím kódem.
  • CrashLoopBackOff: Kontejner v podu se opakovaně chybově ukončí a Kubernetes ho nemůže restartovat.
  • ContainerCreating: Vytváření kontejnerů probíhá modulem runtime kontejneru.

Kontrola stavu podu a protokolů

Nejprve začněte kontrolou stavu podu a protokolů pomocí příkazu kubectl:

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

Příkaz get pods zobrazí seznam všech podů v aktuálním oboru názvů spolu s jejich aktuálním stavem. Příkaz logs načte protokoly pro konkrétní pod a umožňuje zkontrolovat případné chyby nebo výjimky. Při řešení potíží se sítí použijte následující příkazy:

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

Příkaz get services zobrazí všechny služby v aktuálním oboru názvů. Příkaz poskytuje podrobnosti o konkrétní službě, včetně přidružených koncových bodů a všech relevantních chybových zpráv. Pokud narazíte na problémy s pvcs, můžete je ladit pomocí následujících příkazů:

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

Příkaz get persistentvolumeclaims zobrazí seznam všech pvcs v aktuálním oboru názvů. Příkaz describe poskytuje podrobné informace o konkrétním PVC, včetně stavu, přidružené třídy úložiště a všech relevantních událostí nebo chyb.