Esercizio - Dimostrare la resilienza dei microservizi in Kubernetes

  • 3 minuti

Uno dei vantaggi di Kubernetes è il supporto per la gestione della configurazione dichiarativa. I servizi definiti nei file di configurazione verranno mantenuti in ogni caso.

Ciò significa che se si verifica un errore, Kubernetes riavvia automaticamente i servizi in esecuzione prima dell'errore.

Si vedrà ora questa resilienza in azione eliminando il storefrontend pod e quindi verificando che Kubernetes lo abbia riavviato.

  1. In primo luogo, nel terminale nello spazio di codice eseguire kubectl get pods e annotare il nome, inclusa la stringa casuale, del storefrontend pod. Ecco un output di esempio:

    @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. Eliminare ora il pod storefrontend usando il comando kubectl delete. È necessario specificare il nome completo del pod, inclusa la stringa casuale.

    kubectl delete pod storefrontend-5b6cc765c4-hjpx4

    Verrà immediatamente visualizzato un messaggio che informa che il pod è stato eliminato.

  3. Dal momento che Kubernetes mantiene lo stato del sistema dichiarato nei file di configurazione, verrà immediatamente avviata un'altra istanza del pod. È possibile verificarlo eseguendo 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

    Si noti che la stringa casuale che segue il nome storefrontend è cambiata, a indicare che il pod è una nuova istanza. Anche il valore AGE è molto più basso.

In questo esercizio si è visto in che modo Kubernetes mantiene automaticamente lo stato del sistema dichiarato, anche in caso di errore.

Verificare le conoscenze

1.

Qual è il motivo per cui Kubernetes riavvia i pod quando hanno esito negativo?