還有一件關於 Service 跟 Ingress 的事情要考慮，如果pod的標籤與服務的pod選擇器相匹配，那麼pod就將作為服務的endpoint。只要建立了具有適當標籤的新pod，它就成為服務的一部分，並且連線請求將開始被轉發到此pod。 但是該pod可能需要時間來載入設定或資料，或者可能需要執行預熱程序以防止第一個用戶請求時間太長影響了用戶體驗。這請情況下，不希望該pod立刻開始接收請求，尤其是在運行的實例可以正確快速的處理請求的情況下。不要將請求轉發到正在啟動的pod中，直到完全準備就緒。
就緒探針跟之前介紹的存活探針類似，就緒探針會定期執行，並確保特定的pod是否接收客戶端請求。當容器的準備就緒探針返回成功時，表示容器已經準備好接收請求。 這個準備就緒的概念顯然是每個容器特有的東西。k8s能檢查在容器中執行的應用程式是否回應一個簡單的GET /請求，或者它可以回應特定的URL路徑 (該URL確認應用程式執行一列檢查以確定它是否準備就緒)。這種準備就緒的判定是應用程序開發人員的責任。
就緒探針有三種類型(跟存活探針一樣)：
啟動容器時，可以為k8s設定一個等待時間，經過等待時間後才可以執行第一次準備就緒檢查。之後，它會週期性執行探針，並根據就緒探針的結果採取行動。 如果某個pod回報未準備就緒，則會從服務中移除該pod。如果pod再次準備就緒，則重新加入pod。
與存活探針不同，如果容器未通過就緒檢查，容器並不會被終止或重新啟動。這是存活探針跟就緒探針之間的重要區別。 存活探針透過刪除異常的容器並用新的正常容器替代它們來保持pod正常運作，而就緒探針確保只有準備好處理請求的pod才可以接收請求。這是容器起動時最為必要，當然在容器運行一段時間後也是有用的。
圖5.11 就緒探針失敗的pod從服務的endpoint中移除
如上圖如果一個容器的就緒探針失敗，則將該容器從endpoint物件中移除，連接到該服務的客戶端不會被分派到這個pod，這和pod與服務的標籤選擇器完全不匹配的效果相同。
設想一組pod(例如：運行應用程式服務的pod)依賴另一個pod(例如：後端資料庫)提供的服務，如果任何一個前端連接點出現連線問題並且無法在訪問資料庫，那麼就緒探針可能會告訴k8s該pod沒有準備好處理任何請求，如果其它pod實例沒有遇到類似的資料庫連線問題，則它們可以正常處理請求。就緒探針確保客戶端只與正常的pod連線，並且永遠不會注意到系統有問題。
透過修改 Replication Controller 的pod樣板來為現有的pod加入就緒探針。
透過 kubectl edit 指令來修改已經存在的 Replication Controller 中的pod樣板加入探針。