Sterowanie zachowaniem w przypadku niepowodzenia aktualizacji

Omówienie

W tym przewodniku opisano zachowanie w przypadku błędów podczas uaktualniania programu Azure Operator Service Manager (AOSM) dla funkcji sieciowych kontenerów (CNF). Te funkcjonalności, w ramach inicjatywy praktyk bezpiecznego uaktualniania systemu AOSM, oferują wybór między szybszymi ponownymi próbami z wstrzymaniem w przypadku awarii a powrotem do punktu początkowego z przywracaniem stanu po awarii.

Wstrzymywanie przy niepowodzeniu

Każde uaktualnienie przy użyciu programu AOSM rozpoczyna się od operacji przywracania usługi sieciowej witryny. Operacja reput przetwarza aplikacje funkcji sieciowych (nfApps) znalezione w projekcie funkcji sieciowej (NFDV). Operacja reput implementuje następującą logikę domyślną:

• Aplikacje nfApps są przetwarzane zgodnie z określoną updateDependsOn kolejnością lub w kolejności, w jakiej się pojawiają.
• Pominięto aplikacje nfApps z parametrem applicationEnabled ustawionym na wyłączony.
• Jeśli nfApps są obecne, ale nie są wspomniane przez nowy NFDV, są usuwane.
• Sekwencja wykonywania jest wstrzymana, jeśli któraś z aktualizacji aplikacji nfApp zakończy się niepowodzeniem, a rozważa się atomowe cofnięcie.
• Błąd pozostawia zasób NF w stanie awarii.

W przypadku wstrzymania operacji w razie niepowodzenia AOSM cofa tylko nieudaną aplikację nfApp za pomocą parametrów testOptions, installOptions lub upgradeOptions. Żadna akcja nie jest wykonywana w przypadku żadnych aplikacji nfApp, które kontynuują niepowodzenie aplikacji nfApp. Ta metoda umożliwia użytkownikowi końcowemu rozwiązywanie problemów z niemożnością działania aplikacji nfApp, a następnie ponowne uruchomienie uaktualnienia od tego momentu. Jako domyślne zachowanie ta metoda jest najbardziej wydajną metodą, ale może powodować niespójności funkcji sieciowej (NF) w stanie mieszanej wersji.

Wycofanie w przypadku niepowodzenia

Aby rozwiązać problem z ryzykiem 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 się nie powiedzie, zarówno zawodzący nfApp, jak i wszystkie wcześniejsze ukończone nfApps, można przywrócić do stanu początkowych wersji. Ta metoda minimalizuje lub eliminuje czas, przez jaki system plików NF jest narażony na niezgodność wersji nfApp. Opcjonalna funkcja wycofywania po awarii działa w następujący sposób:

• Użytkownik inicjuje operację resetowania reputacji SNS i włącza przywracanie po awarii.
• Zrzut aktualnych wersji aplikacji nfApp jest przechwytywany i przechowywany.
• Migawka służy do określania poszczególnych akcji nfApp, które zostały podjęte w celu cofnięcia działań zakończonych sukcesem.
  • helm install akcja w przypadku usuniętych składników,
  • helm rollback działania dotyczące zaktualizowanych składników,
  • helm delete akcja dla nowo zainstalowanych składników
• Wystąpił błąd nfApp, AOSM przywraca nfApps do stanu wersji migawki sprzed aktualizacji, przy czym najnowsze działania są cofane 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ć przywracanie po niepowodzeniu

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

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

Po zdefiniowaniu nowego rollbackEnable parametru operator może teraz podać wartość czasu wykonywania w obszarze roleOverrideValues, w ramach ładunku NF reput.

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 wycofaniem zmian w przypadku niepowodzenia

Informacje o stanach zasobników

Zrozumienie różnych stanów podó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 w dobrym stanie.
• Niepowodzenie: co najmniej jeden kontener w zasobniku jest zakończony kodem zakończenia niezerowym.
• CrashLoopBackOff: kontener w podzie wielokrotnie ulega awarii, a platforma Kubernetes nie jest w stanie go ponownie uruchomić.
• ContainerCreating: tworzenie kontenera jest w toku przez środowisko uruchomieniowe kontenera.

Sprawdź stan podu i dzienniki

Najpierw sprawdź status podu i logi przy użyciu polecenia kubectl:

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

Polecenie get pods wyświetla listę wszystkich zasobników w bieżącej przestrzeni nazw wraz z ich aktualnym stanem. Polecenie logs pobiera dzienniki dla określonego poda, co umożliwia przeglądanie 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.