Bases du cloud et des conteneurs
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5Une application web ne peut pas traiter de requêtes pendant environ 60 secondes après son démarrage, le temps de charger son cache, et renvoie 503 sur /ready pendant ce temps. Quelle description de l'effet de l'ajout des réglages ci-dessus au conteneur du Pod est correcte ?
- ATant que /ready échoue, le Pod est retiré des destinations du Service et ne reçoit aucune requête, et le conteneur n'est pas redémarré
- BLe conteneur est redémarré chaque fois que /ready échoue : il redémarre donc sans cesse avant la fin du chargement du cache
- CTant que /ready n'a pas réussi, le Pod n'est affecté à aucun nœud, et le conteneur n'est pas démarré
Afficher la réponse et l'explication
Réponse : A. Tant que /ready échoue, le Pod est retiré des destinations du Service et ne reçoit aucune requête, et le conteneur n'est pas redémarré
Une sonde readiness vérifie si un conteneur est prêt à accepter des requêtes et, tant qu'elle échoue, retire le Pod des destinations du Service. Une sonde HTTP considère comme un succès une réponse d'au moins 200 et inférieure à 400 : aucune requête n'est donc envoyée tant que 503 est renvoyé, et les requêtes arrivent dès que l'application est prête. Redémarrer le conteneur en cas d'échec est le rôle d'une sonde liveness ; ne donner à une application lente à démarrer qu'une sonde liveness à intervalle court peut provoquer des redémarrages répétés. Le nœud sur lequel s'exécute un Pod est choisi par l'ordonnanceur (scheduler), pas par les sondes.
Continuer : 9 autres questions sur Bases du cloud et des conteneurs