雲平臺將故障Pod流量下線通用思路與OpenShift操作實戰

東北小狐狸發表於2022-03-17

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，不就是可以流量下線了嗎？理論可行，開始實踐。