探針配置失誤，線上容器應用例外死鎖后，kubernetes集群未及時回應自愈重啟容器？
探針配置失誤，線上容器應用例外死鎖后，kubernetes集群未及時回應自愈重啟容器？
線上多個服務應用陷入了死回圈，大量服務訪問不通，陷入死回圈的應用長時間擱置，并沒有進行自愈，
k8s應用容器沒有檢測到應用陷入了故障，容器未及時重啟？
囧么肥事-胡說八道
弄清楚為什么要使用容器探針？
kubernetes 集群的好處是可以監測應用容器健康狀態，在必要時候進行故障自愈，Pod管家一旦調度到某個節點，該節點上的Kubelet就會運行Pod的容器，
如果應用程式中有一個導致它每隔一段時間就會崩潰的bug,Kubernetes會自動重啟應用程式，所以即使應用程式本身沒有做任何特殊的事，在Kubernetes中運行也能自動獲得自我修復的能力，
默認情況下，kubelet根據容器運行狀態作為健康依據，不能監控容器中應用程式狀態，例如程式假死，這就會導致無法提供服務，丟失流量，因此引入健康檢查機制確保容器健康存活，
Pod通過兩類探針來檢查容器的健康狀態，分別是LivenessProbe（存活探針）和 ReadinessProbe（就緒探針），
還有一種啟動探針監控應用啟動狀態：StartupProbe（啟動探針）
-
livenessProbe：指示容器是否正在運行，如果存活態探針失敗，則kubelet會殺死容器， 并且容器將根據其重啟策略決定未來，如果容器不提供存活探針， 則默認狀態為Success， -
readinessProbe：指示容器是否準備好為請求提供服務，如果就緒態探針失敗， 端點控制器將從與 Pod 匹配的所有服務的端點串列中洗掉該 Pod 的 IP 地址， 初始延遲之前的就緒態的狀態值默認為Failure， 如果容器不提供就緒態探針，則默認狀態為Success， -
startupProbe: 指示容器中的應用是否已經啟動，如果提供了啟動探針，則所有其他探針都會被 禁用，直到此探針成功為止，如果啟動探針失敗，kubelet 將殺死容器，而容器依其重啟策略進行重啟， 如果容器沒有提供啟動探針，則默認狀態為 Success，
特殊場景如何選擇正確的探針？
kubelet 使用存活探針來知道什么時候要重啟容器，
例如，存活探針可以捕捉到死鎖（應用程式在運行，但是無法繼續執行后面的步驟）， 這樣的情況下重啟容器有助于讓應用程式在有問題的情況下更可用，
kubelet 使用就緒探針判斷容器什么時候準備好了并可以開始接受請求流量，
當一個 Pod 內的所有容器都準備好了，才能把這個 Pod 看作就緒了， 這種信號的一個用途就是控制哪個 Pod 作為 Service 的后端， 在 Pod 還沒有準備好的時候，會從 Service 的負載均衡器中被剔除的，
kubelet 使用啟動探針監測應用程式容器什么時候啟動了，
如果配置了這類探針，就可以控制容器在啟動成功后再進行存活性和就緒檢查， 確保這些存活、就緒探針不會影回應用程式的啟動， 這可以用于對慢啟動容器進行存活性檢測，避免它們在啟動運行之前就被殺掉，
何時該使用存活態探針?
如果容器中的行程能夠在遇到問題或不健康的情況下自行崩潰，則不一定需要存活態探針; kubelet 將根據 Pod 的restartPolicy 自動執行修復操作，
如果你希望容器在探測失敗時被殺死并重新啟動，那么請指定一個存活態探針， 并指定restartPolicy 為 "Always" 或 "OnFailure"，
何時該使用就緒態探針?
如果要僅在探測成功時才開始向 Pod 發送請求流量，請指定就緒態探針，
在這種情況下，就緒態探針可能與存活態探針相同，但是規約中的就緒態探針的存在意味著 Pod 將在啟動階段不接收任何資料，并且只有在探針探測成功后才開始接收資料，
如果你希望容器能夠自行進入維護狀態，也可以指定一個就緒態探針
檢查某個特定于就緒態的不同于存活態探測的端點，
如果你的應用程式對后端服務有嚴格的依賴性，你可以同時實作存活態和就緒態探針，
當應用程式本身是健康的，存活態探針檢測通過后，就緒態探針會額外檢查每個所需的后端服務是否可用，
這可以幫助你避免將流量導向只能回傳錯誤資訊的 Pod，
如果你的容器需要在啟動期間加載大型資料、組態檔或執行遷移，你可以使用 啟動探針，
然而，如果你想區分已經失敗的應用和仍在處理其啟動資料的應用，你可能更傾向于使用就緒探針，
說明：
請注意，如果你只是想在 Pod 被洗掉時能夠排空請求，則不一定需要使用就緒態探針； 在洗掉 Pod 時，Pod 會自動將自身置于未就緒狀態，無論就緒態探針是否存在， 等待 Pod 中的容器停止期間，Pod 會一直處于未就緒狀態，
何時該使用啟動探針？
對于所包含的容器需要較長時間才能啟動就緒的 Pod 而言，啟動探針是有用的， 你不再需要配置一個較長的存活態探測時間間隔，只需要設定另一個獨立的配置選定， 對啟動期間的容器執行探測，從而允許使用遠遠超出存活態時間間隔所允許的時長，
如果你的容器啟動時間通常超出 initialDelaySeconds + failureThreshold × periodSeconds 總值，你應該設定一個啟動探測，對存活態探針所使用的同一端點執行檢查， periodSeconds 的默認值是 10 秒，你應該將其 failureThreshold 設定得足夠高， 以便容器有充足的時間完成啟動，并且避免更改存活態探針所使用的默認值， 這一設定有助于減少死鎖狀況的發生，
例如使用啟動探針保護慢啟動容器
有時候，會有一些現有的應用程式在啟動時需要較多的初始化時間，
要不影響對引起探針死鎖的快速回應，這種情況下，設定存活探針引數是要技巧的，
技巧就是使用一個命令來設定啟動探針，針對HTTP 或者 TCP 檢測，可以通過設定 failureThreshold * periodSeconds 引數來保證有足夠長的時間應對糟糕情況下的啟動時間，
探針執行的三種方式？
Probe 是由 kubelet對容器執行的定期診斷， 要執行診斷，kubelet 有三種型別的處理程式：
ExecAction： 在容器內執行指定命令，如果命令退出時回傳碼為 0 則認為診斷成功，TCPSocketAction： 對容器的 IP 地址上的指定埠執行 TCP 檢查，如果埠打開，則診斷被認為是成功的，HTTPGetAction： 對容器的 IP 地址上指定埠和路徑執行 HTTP Get 請求，如果回應的狀態碼大于等于 200 且小于 400，則診斷被認為是成功的，
每次探測都將獲得以下三種結果之一：
Success（成功）：容器通過了診斷，Failure（失敗）：容器未通過診斷，Unknown（未知）：診斷失敗，因此不會采取任何行動，
《Kubernetes-企業級容器應用托管》-持續胡說八道
第一段：推薦閱讀：【云原生新時代弄潮兒k8s憑什么在容器化方面獨樹一幟？】
第二段：推薦閱讀：【趁著同事玩游戲偷偷認識k8s一家子補補課】
第三段：推薦閱讀：【Kubernetes家族容器小管家Pod在線答疑?】
第四段：推薦閱讀：【同事提出個我從未想過的問題，為什么Kubernetes要"多此一舉"推出靜態Pod概念？】
第五段：推薦閱讀：【探針配置失誤，線上容器應用例外死鎖后，kubernetes集群未及時回應自愈重啟容器？】
第六段：待更新？推薦休閑閱讀：【囧么肥事】
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/428513.html
標籤：其他
上一篇：Kubeadm搭建K8s集群