[[423839]]

 一、前言

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

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

2、缺少監(jiān)控平臺(tái)【最重要的原因】

3、缺少日志系統(tǒng)

4、極度缺少有關(guān)操作文檔

5、請(qǐng)求路線不明朗

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

二、解決方案

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

重構(gòu)發(fā)版流程。業(yè)務(wù)全面k8s化，構(gòu)建以kubernetes為核心的ci/cd流程。

1）發(fā)版流程

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

淺析：研發(fā)人員提交代碼到developer分支(時(shí)刻確保developer分支處于最新的代碼)，developer分支合并到需要發(fā)版環(huán)境對(duì)應(yīng)的分支，觸發(fā)企業(yè)微信告警，觸發(fā)部署在k8s集群的gitlab-runner pod，新啟runner pod 執(zhí)行ci/cd操作。在這個(gè)過程中需要有三個(gè)步驟：測(cè)試用例、打包鏡像、更新pod。

第一次部署服務(wù)在k8s集群環(huán)境的時(shí)候可能需要：創(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 返回結(jié)果。

需要強(qiáng)調(diào)的一點(diǎn)是，在這里的資源資源清單不包含configmap或者secret，牽扯到安全性的問題，不應(yīng)該出 現(xiàn)在代碼倉庫中，我司是使用rancher充當(dāng)k8s多集群管理平臺(tái)，上述安全問題在rancher的dashboard中由運(yùn)維來做的。

2）服務(wù)部署邏輯圖

有關(guān)服務(wù)部署邏輯圖如下：

根據(jù)發(fā)版流程的淺析，再根據(jù)邏輯圖可以明確發(fā)版流程。在這里看到我司使用的是kong代替nginx，做認(rèn)證、鑒權(quán)、代理。而slb的ip綁定在kong上。0，1，2屬于test job；3屬于build job；4，5，6，7屬于change pod 階段。并非所有的服務(wù)都需要做存儲(chǔ)，需要根據(jù)實(shí)際情況來定，所以需要在kubernetes.sh里寫判斷。

在這里我試圖使用一套CI應(yīng)用與所有的環(huán)境，所以需要在kubernetes.sh中用到的判斷較多，且.gitlab-ci.yml顯得過多。建議是使用一個(gè)ci模版，應(yīng)用于所有的環(huán)境，畢竟怎么省事怎么來。還要考慮自己的分支模式。

2、缺少監(jiān)控預(yù)警平臺(tái)

3、缺少日志系統(tǒng)

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

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

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

4、極度缺少有關(guān)操作文檔

建立以語雀--> 運(yùn)維相關(guān)資料為中心的文檔中心，將有關(guān)操作、問題、腳本等詳細(xì)記錄在案，以備隨時(shí)查看。

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

5、請(qǐng)求路線不明朗

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

請(qǐng)求路線邏輯圖如下：

淺析：客戶訪問https://www.cnblogs.com/zisefeizhu 經(jīng)過kong網(wǎng)關(guān)鑒權(quán)后進(jìn)入特定名稱空間(通過名稱空間區(qū)分項(xiàng)目)，因?yàn)榉?wù)已經(jīng)拆分為微服務(wù)，服務(wù)間通信經(jīng)過istio認(rèn)證、授權(quán)，需要和數(shù)據(jù)庫交互的去找數(shù)據(jù)庫，需要寫或者讀存儲(chǔ)的去找pv，需要轉(zhuǎn)換服務(wù)的去找轉(zhuǎn)換服務(wù)...... 然后返回響應(yīng)。

三、總結(jié)

綜上所述，構(gòu)建以：以kubernetes為核心的ci/cd發(fā)版流程、以prometheus為核心的聯(lián)邦監(jiān)控預(yù)警平臺(tái)、以elasticsearch為核心的日志收集系統(tǒng)、以語雀為核心的文檔管理中心、以kong及istio為核心的南北東西流量一體化服務(wù)，可以在高平發(fā)，高可靠性上做到很好保障。

附：總體架構(gòu)邏輯圖

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

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

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