Ćwiczenie — potwierdzanie odporności mikrousług na platformie Kubernetes

  • 3 min

Jedną z zalet platformy Kubernetes jest obsługa deklaratywnego zarządzania konfiguracją. Usługi zdefiniowane w plikach konfiguracji są zachowywane na wszystkich kosztach.

Oznacza to, że jeśli wystąpi awaria, platforma Kubernetes automatycznie uruchamia ponownie usługi, które były uruchomione przed awarią.

Zobaczmy tę odporność, usuwając storefrontend zasobnik, a następnie sprawdzając, czy platforma Kubernetes ją ponownie uruchomiła.

  1. Najpierw w terminalu w przestrzeni kodu uruchom kubectl get podspolecenie i zanotuj nazwę, w tym losowy ciąg storefrontend zasobnika. Oto przykładowe dane wyjściowe:

    @user-name /workspaces/eShopLite % kubectl get pods

NAME                             READY   STATUS    RESTARTS   AGE
productsbackend-7445bdb5c9-pnpk6 1/1     Running   0          31m
storefrontend-5b6cc765c4-hjpx4   1/1     Running   0          63m

  2. Teraz usuń zasobnik storefrontend przy użyciu kubectl delete polecenia . Musisz określić pełną nazwę zasobnika, w tym losowy ciąg.

    kubectl delete pod storefrontend-5b6cc765c4-hjpx4

    Natychmiast zostanie wyświetlony komunikat informujący o tym, że zasobnik został usunięty.

  3. Ponieważ platforma Kubernetes utrzymuje stan systemu zgodnie z deklaracją w plikach konfiguracji, natychmiast uruchamia kolejne wystąpienie zasobnika. Możesz to sprawdzić, uruchamiając polecenie kubectl get pods.

    @user-name /workspaces/eShopLite % kubectl get pods

NAME                             READY   STATUS    RESTARTS   AGE
productsbackend-7445bdb5c9-pnpk6 1/1     Running   0          31m
storefrontend-5b6cc765c4-vwmv8   1/1     Running   0          7s

    Zwróć uwagę, że losowy ciąg po storefrontend nazwie został zmieniony, co oznacza, że zasobnik jest nowym wystąpieniem. Również wartość AGE jest znacznie mniejsza, jak również.

W tym ćwiczeniu pokazano, jak platforma Kubernetes automatycznie utrzymuje zadeklarowany stan systemu, nawet jeśli wystąpi awaria.

Sprawdź swoją wiedzę

1.

Jaki jest powód, dla którego platforma Kubernetes uruchamia ponownie zasobniki po awarii?