今天進入 kubernetes 的運維部分（并不是運維 kubernetes，而是運維應(yīng)用），其實日常我們大部分使用 kubernetes 的功能就是以往運維的工作，現(xiàn)在云原生將運維和研發(fā)關(guān)系變得更緊密了。

今天主要講解 Probe 探針相關(guān)的功能，探針最實用的功能就是可以控制應(yīng)用優(yōu)雅上線。

就緒探針

舉個例子，當(dāng)我們的 service 關(guān)聯(lián)了多個 Pod 的時候，其中一個 Pod 正在重啟但還沒達到可以對外提供服務(wù)的狀態(tài)，這時候如果有流量進入。

那這個請求肯定就會出現(xiàn)異常，從而導(dǎo)致問題，所以我們需要一個和 kubernetes 溝通的渠道，告訴它什么時候可以將流量放進來。

圖片

比如如圖所示的情況，紅色 Pod 在未就緒的時候就不會有流量。

使用就緒探針就可以達到類似的效果：

livenessProbe:  
  failureThreshold: 3  
  httpGet:  
    path: /ping  
    port: 8081  
    scheme: HTTP  
  periodSeconds: 3  
  successThreshold: 1  
  timeoutSeconds: 1

這個配置也很直接：

• 配置一個 HTTP 的 ping 接口
• 每三秒檢測一次
• 失敗 3 次則認(rèn)為檢測失敗
• 成功一次就認(rèn)為檢測成功

但沒有配置就緒探針時，一旦 Pod 的 Endpoint 加入到 service 中(Pod 進入 Running 狀態(tài))，請求就有可能被轉(zhuǎn)發(fā)過來，所以配置就緒探針是非常有必要的。

啟動探針

而啟動探針往往是和就緒探針搭配干活的，如果我們一個 Pod 啟動時間過長，比如超過上面配置的失敗檢測次數(shù)，此時 Pod 就會被 kubernetes 重啟，這樣可能會進入無限重啟的循環(huán)。

所以啟動探針可以先檢測一次是否已經(jīng)啟動，直到啟動成功后才會做后續(xù)的檢測。

startupProbe:  
  failureThreshold: 30  
  httpGet:  
    path: /ping  
    port: 8081  
    scheme: HTTP  
  periodSeconds: 5  
  successThreshold: 1  
  timeoutSeconds: 1

我這里兩個檢測接口是同一個，具體得根據(jù)自己是實際業(yè)務(wù)進行配置；比如應(yīng)用端口啟動之后并不代表業(yè)務(wù)已經(jīng)就緒了，可能某些基礎(chǔ)數(shù)據(jù)還沒加載到內(nèi)存中，這個時候就需要自己寫其他的接口來配置就緒探針了。

圖片

所有關(guān)于探針相關(guān)的日志都可以在 Pod 的事件中查看，比如如果一個應(yīng)用在啟動的過程中頻繁重啟，那就可以看看是不是某個探針檢測失敗了。

存活探針

存活探針往往是用于保證應(yīng)用高可用的，雖然 kubernetes 可以在 Pod 退出后自動重啟，比如 Pod OOM；但應(yīng)用假死他是檢測不出來的。

為了保證這種情況下 Pod 也能被自動重啟，就可以配合存活探針使用：

livenessProbe:  
  failureThreshold: 3  
  httpGet:  
    path: /ping  
    port: 8081  
    scheme: HTTP  
  periodSeconds: 3  
  successThreshold: 1  
  timeoutSeconds: 1

一旦接口響應(yīng)失敗，kubernetes 就會嘗試重啟。

圖片

總結(jié)

圖片

以上探針配置最好是可以在研效平臺可視化配置，這樣維護起來也比較簡單。

探針是維護應(yīng)用健康的必要手段，強烈推薦大家都進行配置。