今天進入 kubernetes 的運維部分（並不是運維 kubernetes，而是運維應用），其實日常我們大部分使用 kubernetes 的功能就是以往運維的工作，現在雲原生將運維和研發關係變得更緊密了。

今天主要講解 Probe 探針相關的功能，探針最實用的功能就是可以控制應用優雅上線。

就緒探針

舉個例子，當我們的 service 關聯了多個 Pod 的時候，其中一個 Pod 正在重啟但還沒達到可以對外提供服務的狀態，這時候如果有流量進入。

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

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

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

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

這個設定也很直接：

設定一個 HTTP 的 ping 介面
每三秒檢測一次
失敗 3 次則認為檢測失敗
成功一次就認為檢測成功

但沒有設定就緒探針時，一旦 Pod 的 Endpoint 加入到 service 中(Pod 進入 Running 狀態)，請求就有可能被轉發過來，所以設定就緒探針是非常有必要的。

啟動探針

而啟動探針往往是和就緒探針搭配幹活的，如果我們一個 Pod 啟動時間過長，比如超過上面設定的失敗檢測次數，此時 Pod 就會被 kubernetes 重啟，這樣可能會進入無限重啟的迴圈。

所以啟動探針可以先檢測一次是否已經啟動，直到啟動成功後才會做後續的檢測。

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

我這裡兩個檢測介面是同一個，具體得根據自己是實際業務進行設定；
比如應用埠啟動之後並不代表業務已經就緒了，可能某些基礎資料還沒載入到記憶體中，這個時候就需要自己寫其他的介面來設定就緒探針了。

所有關於探針相關的紀錄檔都可以在 Pod 的事件中檢視，比如如果一個應用在啟動的過程中頻繁重啟，那就可以看看是不是某個探針檢測失敗了。

存活探針

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

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

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

一旦介面響應失敗，kubernetes 就會嘗試重啟。

總結

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

探針是維護應用健康的必要手段，強烈推薦大家都進行設定。

本文的所有原始碼在這裡可以存取：
https://github.com/crossoverJie/k8s-combat

五分鐘 k8s 實戰-應用探針

就緒探針

啟動探針

存活探針

總結