Grundlagen von Cloud und Containern
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5Eine Webanwendung kann nach dem Start etwa 60 Sekunden lang, während sie ihren Cache lädt, keine Anfragen bearbeiten und liefert in dieser Zeit für /ready den Status 503. Welche Wirkung hat es, die obigen Einstellungen zum Container des Pods hinzuzufügen?
- ASolange /ready fehlschlägt, wird der Pod aus den Verteilungszielen des Service genommen und erhält keine Anfragen, und der Container wird nicht neu gestartet
- BDer Container wird bei jedem Fehlschlag von /ready neu gestartet, sodass er sich immer wieder neu startet, bevor der Cache fertig geladen ist
- CBis /ready erfolgreich ist, wird der Pod keinem Node zugewiesen, und auch der Container wird nicht gestartet
Antwort und Erläuterung anzeigen
Antwort: A. Solange /ready fehlschlägt, wird der Pod aus den Verteilungszielen des Service genommen und erhält keine Anfragen, und der Container wird nicht neu gestartet
Eine Readiness-Probe prüft, ob ein Container bereit ist, Anfragen anzunehmen, und nimmt den Pod, solange sie fehlschlägt, aus den Verteilungszielen des Service. Eine HTTP-Probe wertet eine Antwort ab 200 und unter 400 als Erfolg; solange 503 geliefert wird, werden also keine Anfragen zugeteilt, und sie treffen erst ein, wenn die Anwendung bereit ist. Den Container bei einem Fehlschlag neu zu starten, ist die Aufgabe einer Liveness-Probe; erhält eine langsam startende Anwendung nur eine Liveness-Probe mit kurzem Intervall, kann es zu wiederholten Neustarts kommen. Auf welchem Node ein Pod läuft, entscheidet der Scheduler, nicht die Probes.
Weiter: 9 weitere Fragen zu Grundlagen von Cloud und Containern