Zachowanie niepowodzenia uaktualniania kontroli

Omówienie

W tym przewodniku opisano funkcje zachowania błędów uaktualniania programu Azure Operator Service Manager (AOSM) dla funkcji sieci kontenera (CNFs). Te funkcje, w ramach inicjatywy praktyk bezpiecznego uaktualniania systemu AOSM, oferują wybór między szybszymi ponownymi próbami, z wstrzymaniem w przypadku awarii, a powrót do punktu początkowego, z wycofywaniem po awarii.

Wstrzymywanie przy niepowodzeniu

Każde uaktualnienie przy użyciu programu AOSM rozpoczyna się od ponownego użycia usługi sieciowej lokacji (SNS). Operacja poput przetwarza aplikacje funkcji sieciowych (NfApps) znalezione w wersji projektowej funkcji sieciowej (NFDV). Operacjaputowania implementuje następującą logikę domyślną:

• Aplikacje NfApps są przetwarzane zgodnie z kolejnością updateDependsOn lub w kolejności sekwencyjnej.
• Funkcja NfApps z parametrem "applicationEnabled" ustawiona na wartość disable jest pomijana.
• Obecne aplikacje NFApps, ale nie odwołują się do nowego NFDV są usuwane.
• Sekwencja wykonywania jest wstrzymana, jeśli którykolwiek z uaktualnień aplikacji NfApp zakończy się niepowodzeniem i zostanie uznane za wycofanie.
• Błąd pozostawia zasób NF w stanie niepowodzenia.

W przypadku wstrzymania po awarii usługa AOSM przywraca tylko nieudaną aplikację NfApp za pośrednictwem parametrów testOptions, installOptions lub upgradeOptions. Żadna akcja nie jest wykonywana dla żadnych aplikacji NfApp, które kontynuują niepowodzenie aplikacji NfApp. Ta metoda umożliwia użytkownikowi końcowemu rozwiązywanie problemów z niepowodzeniem aplikacji NfApp, a następnie ponowne uruchomienie uaktualnienia z tego punktu do przodu. Jako domyślne zachowanie ta metoda jest najbardziej wydajną metodą, ale może powodować niespójności funkcji sieciowej (NF) w stanie mieszanej wersji.

Wycofywanie po awarii

Aby rozwiązać ryzyko niezgodności wersji aplikacji NfApp, usługa AOSM obsługuje teraz wycofywanie na poziomie NF po awarii. Po włączeniu tej opcji, jeśli operacja NfApp zakończy się niepowodzeniem, zarówno niepowodzenie NfApp, jak i wszystkie wcześniejsze ukończone aplikacje NfApps, można przywrócić do stanu początkowej wersji. Ta metoda minimalizuje lub eliminuje czas, przez jaki system plików NF jest narażony na niezgodność wersji aplikacji NfApp. Opcjonalna funkcja wycofywania po awarii działa w następujący sposób:

• Użytkownik inicjuje operacjęputowania sSNS i włącza wycofywanie po awarii.
• Migawka bieżących wersji aplikacji NfApp jest przechwytywana i przechowywana.
• Migawka służy do określania poszczególnych akcji NfApp podejmowanych w celu pomyślnego zwrotu akcji.
  • Akcja "instalacja narzędzia helm" dla usuniętych składników,
  • Akcja "wycofywania narzędzia helm" dla uaktualnionych składników,
  • Akcja "helm delete" dla nowo zainstalowanych składników
• Wystąpił błąd NfApp, AOSM przywraca stan wersji migawki NfApps przed uaktualnieniem, a najnowsze akcje zostały przywrócone jako pierwsze.

Usługa AOSM zwraca następujący stan operacyjny i komunikaty, biorąc pod uwagę odpowiednie wyniki:

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

Jak skonfigurować wycofywanie po niepowodzeniu

Najbardziej elastyczną metodą kontrolowania zachowania awarii jest rozszerzenie nowego parametru schematu grupy konfiguracji (CGS), rollbackEnabled, aby umożliwić kontrolę wartości grupy konfiguracji (CGV) za pośrednictwem roleOverrideValues w ładunku NF. Najpierw zdefiniuj parametr CGS:

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

Po zdefiniowaniu nowego parametru rollbackEnable operator może teraz podać wartość czasu wykonywania w obszarze roleOverrideValues jako część ładunku NF.

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

Jak rozwiązywać problemy z wycofywaniem po awarii

Informacje o stanach zasobników

Zrozumienie różnych stanów zasobników ma kluczowe znaczenie dla skutecznego rozwiązywania problemów. Poniżej przedstawiono najbardziej typowe stany zasobników:

• Oczekujące: Planowanie zasobników jest w toku przez platformę Kubernetes.
• Uruchomione: wszystkie kontenery w zasobniku są uruchomione i są w dobrej kondycji.
• Niepowodzenie: co najmniej jeden kontener w zasobniku jest zakończony kodem zakończenia niezerowym.
• CrashLoopBackOff: kontener w zasobniku wielokrotnie ulega awarii, a platforma Kubernetes nie może go ponownie uruchomić.
• ContainerCreating: tworzenie kontenera jest w toku przez środowisko uruchomieniowe kontenera.

Sprawdzanie stanu zasobnika i dzienników

Najpierw zacznij od sprawdzenia stanu zasobnika i dzienników przy użyciu polecenia kubectl:

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

Polecenie get zasobników wyświetla listę wszystkich zasobników w bieżącej przestrzeni nazw wraz z ich bieżącym stanem. Polecenie logs pobiera dzienniki dla określonego zasobnika, co umożliwia inspekcję błędów lub wyjątków. Aby rozwiązać problemy z siecią, użyj następujących poleceń:

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

Polecenie get services wyświetla wszystkie usługi w bieżącej przestrzeni nazw. Polecenie zawiera szczegółowe informacje na temat określonej usługi, w tym skojarzonych punktów końcowych i wszelkich odpowiednich komunikatów o błędach. Jeśli występują problemy z kontrolerami PVC, możesz użyć następujących poleceń, aby je debugować:

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

Polecenie "get persistentvolumeclaims" wyświetla listę wszystkich kontrolerów PVC w bieżącej przestrzeni nazw. Opis polecenia zawiera szczegółowe informacje o określonym PCV, w tym o stanie, skojarzonej klasie magazynu i wszelkich odpowiednich zdarzeniach lub błędach.