[[422569]]

前言

我司的集群時刻處于崩潰的邊緣，通過近三個月的掌握，發(fā)現(xiàn)我司的集群不穩(wěn)定的原因有以下幾點：

1. 發(fā)版流程不穩(wěn)定
2. 缺少監(jiān)控平臺（最重要的原因）
3. 缺少日志系統(tǒng)
4. 極度缺少有關操作文檔
5. 請求路線不明朗

總的來看，問題的主要原因是缺少可預知的監(jiān)控平臺，總是等問題出現(xiàn)了才知道。次要的原因是服務器作用不明朗和發(fā)版流程的不穩(wěn)定。

解決方案

發(fā)版流程不穩(wěn)定

重構發(fā)版流程。業(yè)務全面Kubernetes化，構建以Kubernetes為核心的CI/CD流程。

發(fā)版流程

有關發(fā)版流程如下：

淺析：研發(fā)人員提交代碼到developer分支（時刻確保developer分支處于最新的代碼），developer分支合并到需要發(fā)版環(huán)境對應的分支，觸發(fā)企業(yè)微信告警，觸發(fā)部署在Kubernetes集群的gitlab-runner Pod，新啟runner Pod 執(zhí)行CI/CD操作。在這個過程中需要有三個步驟：測試用例、打包鏡像、更新Pod。第一次部署服務在Kubernetes集群環(huán)境的時候可能需要：創(chuàng)建Namespace、創(chuàng)建imagePullSecret、創(chuàng)建PV（StorageClass）、創(chuàng)建deployment（Pod controller）、創(chuàng)建SVC、創(chuàng)建Ingress等。其中鏡像打包推送阿里云倉庫和從阿里云倉庫下載鏡像使用VPC訪問，不走公網(wǎng)，無網(wǎng)速限制。流程完畢，runner Pod銷毀，GitLab返回結果。

需要強調的一點是，在這里的資源清單不包含ConfigMap或者Secret，牽扯到安全性的問題，不應該出現(xiàn)在代碼倉庫中，我司是使用Rancher充當Kubernetes多集群管理平臺，上述安全問題在Rancher的Dashboard中由運維來做的。

服務部署邏輯圖

有關服務部署邏輯圖如下：

根據(jù)發(fā)版流程的淺析，再根據(jù)邏輯圖可以明確發(fā)版流程。在這里看到我司使用的是Kong代替Nginx，做認證、鑒權、代理。而SLB的IP綁定在Kong上。0，1，2屬于test job；3屬于build job；4，5，6，7屬于change pod 階段。并非所有的服務都需要做存儲，需要根據(jù)實際情況來定，所以需要在kubernetes.sh里寫判斷。在這里我試圖使用一套CI應用與所有的環(huán)境，所以需要在kubernetes.sh中用到的判斷較多，且.gitlab-ci.yml顯得過多。建議是使用一個CI模版，應用于所有的環(huán)境，畢竟怎么省事怎么來。還要考慮自己的分支模式，具體參考： https://www.cnblogs.com/zisefeizhu/p/13621797.html

缺少監(jiān)控預警平臺

構建可信賴且符合我司集群環(huán)境的聯(lián)邦監(jiān)控平臺，實現(xiàn)對幾個集群環(huán)境的同時監(jiān)控和預故障告警，提前介入。

監(jiān)控預警邏輯圖

有關監(jiān)控預警邏輯圖如下：

淺析：總的來說，我這里使用到的監(jiān)控方案是Prometheus + Shell腳本或Go腳本+ Sentry。使用到的告警方式是企業(yè)微信或者企業(yè)郵箱。上圖三種顏色的線代表三種監(jiān)控方式需要注意。腳本主要是用來做備份告警、證書告警、抓賊等。Prometheus這里采用的是根據(jù)Prometheus-opertor修改的Prometheus資源清單，數(shù)據(jù)存儲在NAS上。Sentry嚴格的來講屬于日志收集類的平臺，在這里我將其歸為監(jiān)控類，是因為我看中了其收集應用底層代碼的崩潰信息的能力，屬于業(yè)務邏輯監(jiān)控，旨在對業(yè)務系統(tǒng)運行過程中產(chǎn)生的錯誤日志進行收集歸納和監(jiān)控告警。

注意這里使用的是聯(lián)邦監(jiān)控平臺，而部署普通的監(jiān)控平臺。

聯(lián)邦監(jiān)控預警平臺邏輯圖

多集群聯(lián)邦監(jiān)控預警平臺邏輯圖如下：

因為我司有幾個Kubernetes集群，如果在每個集群上都部署一套監(jiān)控預警平臺的話，管理起來太過不便，所以這里我采取的策略是使用將各監(jiān)控預警平臺實行一個聯(lián)邦的策略，使用統(tǒng)一的可視化界面管理。這里我將實現(xiàn)三個級別餓監(jiān)控：操作系統(tǒng)級、應用程序級、業(yè)務級。對于流量的監(jiān)控可以直接針對Kong進行監(jiān)控，模版7424。

缺少日志系統(tǒng)

隨著業(yè)務全面Kubernetes化進程的推進，對于日志系統(tǒng)的需求將更加渴望，Kubernetes的特性是服務的故障日志難以獲取。建立可觀測的能過濾的日志系統(tǒng)可以降低對故障的分析難度。

有關日志系統(tǒng)邏輯圖如下：

淺析：在業(yè)務全面上Kubernetes化后，方便了管理維護，但對于日志的管理難度就適當上升了。我們知道Pod的重啟是有多因素且不可控的，而每次Pod重啟都會重新記錄日志，即新Pod之前的日志是不可見的。當然了有多種方法可以實現(xiàn)日志長存：遠端存儲日志、本機掛載日志等。出于對可視化、可分析等的考慮，選擇使用Elasticsearch構建日志收集系統(tǒng)。

極度缺少有關操作文檔

建立以語雀--> 運維相關資料為中心的文檔中心，將有關操作、問題、腳本等詳細記錄在案，以備隨時查看。

淺析因安全性原因，不便于過多同事查閱。運維的工作比較特殊，安全化、文檔化是必須要保障的。我認為不論是運維還是運維開發(fā)，書寫文檔都是必須要掌握的，為己也好，為他也罷。文檔可以簡寫，但必須要含苞核心的步驟。我還是認為運維的每一步操作都應該記錄下來。

請求路線不明朗

根據(jù)集群重構的新思路，重新梳理集群級流量請求路線，構建具備：認證、鑒權、代理、連接、保護、控制、觀察等一體的流量管理，有效控制故障爆炸范圍。

請求路線邏輯圖如下：

淺析：客戶經(jīng)過Kong網(wǎng)關鑒權后進入特定名稱空間（通過名稱空間區(qū)分項目），因為服務已經(jīng)拆分為微服務，服務間通信經(jīng)過Istio認證、授權，需要和數(shù)據(jù)庫交互的去找數(shù)據(jù)庫，需要寫或者讀存儲的去找PV，需要轉換服務的去找轉換服務......然后返回響應。

總結

綜上所述，構建以：以Kubernetes為核心的CI/CD發(fā)版流程、以Prometheus為核心的聯(lián)邦監(jiān)控預警平臺、以Elasticsearch為核心的日志收集系統(tǒng)、以語雀為核心的文檔管理中心、以Kong及Istio為核心的南北東西流量一體化服務，可以在高平發(fā)，高可靠性上做到很好保障。

附總體架構邏輯圖：

注：請根據(jù)箭頭和顏色來分析。

淺析：上圖看著似乎過于混亂，靜下心來，根據(jù)上面的拆分模塊一層層分析還是可以看清晰的。這里我用不同顏色的連線代表不同模塊的系統(tǒng)，根據(jù)箭頭走還是蠻清晰的。

根據(jù)我司目前的業(yè)務流量，上述功能模塊，理論上可以實現(xiàn)集群的維穩(wěn)。私認為此套方案可以確保業(yè)務在Kubernetes集群上穩(wěn)定的運行一段時間，再有問題就屬于代碼層面的問題了。這里沒有使用到中間件，倒是使用到了緩存Redis不過沒畫出來。我規(guī)劃在上圖搞定后再在日志系統(tǒng)哪里和轉換服務哪里增加個中間件Kafka或者RQ看情況吧。