雲端與容器基礎
在 Kubernetes 上的 Web 應用程式中，讓 liveness 探測的檢查處理連相依的資料庫能否連線都一併檢查。這個設定可能發生的問題，下列何者最適當？
- A資料庫停止時，Pod 會被自動移到資料庫所在的節點，使該節點上其他應用程式的效能下降
- B資料庫只是暫時停止，所有 Pod 的容器就會反覆重新啟動，即使資料庫恢復，復原也會延遲
- Cliveness 探測失敗時，Pod 只會從 Service 的分配對象中移除，因此不會發生特別的問題
查看答案與解析
正確答案：B. 資料庫只是暫時停止，所有 Pod 的容器就會反覆重新啟動，即使資料庫恢復，復原也會延遲
liveness 探測是在容器本身停止回應（死結等）時，透過重新啟動使其恢復的機制。若連相依對象都檢查，資料庫停止時所有 Pod 的 liveness 探測都會失敗，即使重新啟動也無法解決，容器仍被反覆重新啟動。重新啟動期間無法處理要求，反覆之後到下次重新啟動的等待時間也可能變長，因此資料庫恢復後的復原也會延遲。liveness 探測只檢查行程本身能否回應，相依對象的狀態則視需要以 readiness 探測或應用程式的錯誤處理來應對。
- A. 探測失敗不會把 Pod 移到其他節點。liveness 探測失敗時，容器會被重新啟動。
- B. 正確。相依對象的故障會使所有 Pod 反覆重新啟動。
- C. 從分配對象中移除是 readiness 探測的作用。liveness 探測失敗時，容器會被重新啟動。