Exercice : Prouver la résilience du microservice dans Kubernetes

  • 3 minutes

L’un des avantages de Kubernetes est la prise en charge de la gestion de la configuration déclarative. Les services que vous définissez dans les fichiers de configuration sont conservés à tout prix.

Cela signifie qu’en cas de défaillance, Kubernetes redémarre automatiquement les services qui étaient en cours d’exécution avant la défaillance.

Voyons cette résilience en action en supprimant le pod storefrontend, puis en vérifiant que Kubernetes l’a redémarré.

  1. Tout d’abord, dans le TERMINAL du codespace, exécutez kubectl get pods et notez le nom, y compris la chaîne aléatoire, du pod storefrontend. Voici un exemple de sortie :

    @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. Maintenant, supprimez le pod storefrontend en utilisant la commande kubectl delete. Vous devez spécifier le nom complet du pod, y compris la chaîne aléatoire.

    kubectl delete pod storefrontend-5b6cc765c4-hjpx4

    Vous recevez immédiatement un message indiquant que le pod a été supprimé.

  3. Comme Kubernetes conserve l’état du système tel que déclaré dans les fichiers de configuration, il démarre immédiatement une autre instance du pod. Vous pouvez vérifier cela en exécutant 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

    Notez que la chaîne aléatoire qui suit le nom storefrontend a changé, ce qui indique que le pod est une nouvelle instance. De même, la valeur AGE est considérablement réduite.

Dans cet exercice, vous découvert comment Kubernetes maintient automatiquement l’état du système déclaré, même en cas de défaillance.

Contrôle des connaissances

1.

Quelle est la raison pour laquelle Kubernetes redémarre les pods lorsqu’ils échouent ?