1 寫在前邊

自從公司專案前年上了 OpenShift 3.9 私有云平臺，更新部署程式的確變得更加容易了。但是帶來了很多複雜性，運維實施人員的學習曲線也陡然上升。

上雲之前：在專案沒上容器雲的早期，應用服務叢集往往是由一個Nginx作為負載均衡器，當有叢集中有一個節點出現故障時，只需要將 Nginx 上負載均衡塊 upstream 塊中的故障節點地址移除，重新整理 Nginx 即可達到快速響應，也能慢慢收集效能指標進行分析。

上雲之後：在雲上部署應用，應用容器生命週期由 Deployment 管理，多例項叢集由 Service 負載流量 （本文暫時不談服務網格）。當應用叢集中某個Pod出現故障，通過 Deployment 或 Service 並不能直接把某個 Pod 從流量負載中移出，使用存活探針的話基本沒辦法收集效能指標。（以下是k8s部署簡圖）

就緒探針：能從流量中移出無響應 Pod，但是會受到應用檢測健康的介面準確程度限制，比如，開發了一個請求立即返回介面供就緒探針檢測使用，那麼應用服務哪怕有一點點處理能力，就緒檢測就是通過的，此時表現在客戶面前，應用可能會非常卡頓。

存活探針：流量中移除無響應Pod，並重建或重啟 Pod。

注：合理地配置就緒探針與存活探針有助於自動解決服務的絕大部分問題。但是，就緒探針的介面是否有用完全取決於程式設計師（如果只是立即返回，可以說用處不算大，最佳實踐是探測服務的內部狀態給出合適的響應），存活探針僅適用於某些重啟就能解決的特殊情況（當由於應用程式的bug導致的無響應，而有 bug 的功能一直被呼叫，則 Pod 將一直重啟，存活探針的作用就不大了，不如保留現場收集效能指標供程式設計師解決問題）。

本文目標：給出雲平臺將故障Pod流量下線通用思路，以及 OpenShift 平臺將故障 Pod 流量下線，確保有收集效能指標的機會。相信本文對其他基於 k8s 的雲平臺也有一定參考價值。

2 梳理思路

一般來講，Pod 的多副本的流量直接來源是 Service。當應用不可用時，我們需要保留故障 Pod，最簡單的辦法是隻配置就緒探針，但是就緒檢測介面無法確保服務的確是就緒狀態，那就需要人工介入了。

流量從哪裡來？

對於 Pod 而言，流量來自於 Service。初學 K8s 時，都會看到類似下邊的圖，大意是 Service 是通過 Selector 配置的 Label 來匹配 Pod 的。

那麼，Service 直接連線到了 Pod 上麼？

這樣說並不準確，Service 與 Pod 中間還有一種資源 —— Endpoints，Service 通過 Selector 將匹配到的 IP 地址和埠列表存入 Endpoints。也就是說，當流量到達網路代理（KubeProxy）時，網路代理會從眾多 Endpoints 中找出目標 Endpoints 並取出其中一個地址進行轉發。

所以，流量能進入 Pod 是因為 Service 的 Selector 匹配到了相同 Label 的 Pod。

如果我修改了故障 Pod 的 Label，不就是可以流量下線了嗎？理論可行，開始實踐。

3 基於 OpenShift 實踐下線故障 Pod

我們的主要目標是將故障 Pod 從流量中移除，所以可以先看看 Service 以哪個 Label 匹配 Pod。

這裡以我測試環境的程式舉例，通過 Deployment 處的 Actions - Edit Yaml 開啟如下介面：

可以看到 selector 選擇的 Label 為 deloymentConfig: bi，這樣我們就能確認 Pod 必須也有這個標籤，那麼我們去修改故障節點。

退出編輯 yaml 介面，可以看到該 Service 對應的 Pod 列表，這裡以 bi-4-7dt6r 作為故障節點演示，點選 bi-4-7dt6r。

進入 bi-4-7dt6r Pod 介面，依次點選 Actions - Edit yaml，我們找到與 Service 中同樣的標籤（注意大小寫）

修改 deloymentConfig: bi 為 deloymentConfig: bi-debug，只要標籤不同即可，然後 Save

回到 Service 介面，如下圖，原來的 bi-4-7dt6r 已經不在負載列表中了

我們再去 Pods 介面檢視 bi-4-7dt6r 是否依然存在，如圖，原來的 Pod 依然存在。

主要目標——斷開流量已經達成，至於為什麼會建立了一個新的 Pod 呢？

開啟這個應用的 Deployment yaml，我們可以看到：好傢伙，原來 Deployment 匹配 Pod 的標籤也是 deloymentConfig: bi！

這也很好解釋自動建立新節點的原因了：由於 DeploymentConfig 查詢不到它期待的3個Pod副本數，就建立了一個新的！

以上，今天要分享的內容都在這裡了。如果本文對你有所啟發，請為我送上一個贊吧！如有錯漏處，還望評論告知一二！

我是 Hellxz，我們下次再見！

參考書目《Kubernetes in Action》