建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
前言
我司的集群時(shí)刻處于崩潰的邊緣，通過(guò)近三個(gè)月的掌握，發(fā)現(xiàn)我司的集群不穩(wěn)定的原因有以下幾點(diǎn)：
成都創(chuàng)新互聯(lián)始終堅(jiān)持【策劃先行，效果至上】的經(jīng)營(yíng)理念，通過(guò)多達(dá)十多年累計(jì)超上千家客戶(hù)的網(wǎng)站建設(shè)總結(jié)了一套系統(tǒng)有效的全網(wǎng)推廣解決方案，現(xiàn)已廣泛運(yùn)用于各行各業(yè)的客戶(hù)，其中包括：成都服務(wù)器托管等企業(yè)，備受客戶(hù)贊揚(yáng)。
- 發(fā)版流程不穩(wěn)定
- 缺少監(jiān)控平臺(tái)（最重要的原因）
- 缺少日志系統(tǒng)
- 極度缺少有關(guān)操作文檔
- 請(qǐng)求路線(xiàn)不明朗
總的來(lái)看，問(wèn)題的主要原因是缺少可預(yù)知的監(jiān)控平臺(tái)，總是等問(wèn)題出現(xiàn)了才知道。次要的原因是服務(wù)器作用不明朗和發(fā)版流程的不穩(wěn)定。
解決方案
發(fā)版流程不穩(wěn)定
重構(gòu)發(fā)版流程。業(yè)務(wù)全面Kubernetes化，構(gòu)建以Kubernetes為核心的CI/CD流程。
發(fā)版流程
有關(guān)發(fā)版流程如下：
淺析：研發(fā)人員提交代碼到developer分支（時(shí)刻確保developer分支處于最新的代碼），developer分支合并到需要發(fā)版環(huán)境對(duì)應(yīng)的分支，觸發(fā)企業(yè)微信告警，觸發(fā)部署在Kubernetes集群的gitlab-runner Pod，新啟runner Pod 執(zhí)行CI/CD操作。在這個(gè)過(guò)程中需要有三個(gè)步驟：測(cè)試用例、打包鏡像、更新Pod。第一次部署服務(wù)在Kubernetes集群環(huán)境的時(shí)候可能需要：創(chuàng)建Namespace、創(chuàng)建imagePullSecret、創(chuàng)建PV（StorageClass）、創(chuàng)建deployment（Pod controller）、創(chuàng)建SVC、創(chuàng)建Ingress等。其中鏡像打包推送阿里云倉(cāng)庫(kù)和從阿里云倉(cāng)庫(kù)下載鏡像使用VPC訪(fǎng)問(wèn)，不走公網(wǎng)，無(wú)網(wǎng)速限制。流程完畢，runner Pod銷(xiāo)毀，GitLab返回結(jié)果。
需要強(qiáng)調(diào)的一點(diǎn)是，在這里的資源清單不包含ConfigMap或者Secret，牽扯到安全性的問(wèn)題，不應(yīng)該出現(xiàn)在代碼倉(cāng)庫(kù)中，我司是使用Rancher充當(dāng)Kubernetes多集群管理平臺(tái)，上述安全問(wèn)題在Rancher的Dashboard中由運(yùn)維來(lái)做的。
服務(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í)際情況來(lái)定，所以需要在kubernetes.sh里寫(xiě)判斷。在這里我試圖使用一套CI應(yīng)用與所有的環(huán)境，所以需要在kubernetes.sh中用到的判斷較多，且.gitlab-ci.yml顯得過(guò)多。建議是使用一個(gè)CI模版，應(yīng)用于所有的環(huán)境，畢竟怎么省事怎么來(lái)。還要考慮自己的分支模式，具體參考： https://www.cnblogs.com/zisefeizhu/p/13621797.html
缺少監(jiān)控預(yù)警平臺(tái)
構(gòu)建可信賴(lài)且符合我司集群環(huán)境的聯(lián)邦監(jiān)控平臺(tái)，實(shí)現(xiàn)對(duì)幾個(gè)集群環(huán)境的同時(shí)監(jiān)控和預(yù)故障告警，提前介入。
監(jiān)控預(yù)警邏輯圖
有關(guān)監(jiān)控預(yù)警邏輯圖如下：
淺析：總的來(lái)說(shuō)，我這里使用到的監(jiān)控方案是Prometheus + Shell腳本或Go腳本+ Sentry。使用到的告警方式是企業(yè)微信或者企業(yè)郵箱。上圖三種顏色的線(xiàn)代表三種監(jiān)控方式需要注意。腳本主要是用來(lái)做備份告警、證書(shū)告警、抓賊等。Prometheus這里采用的是根據(jù)Prometheus-opertor修改的Prometheus資源清單，數(shù)據(jù)存儲(chǔ)在NAS上。Sentry嚴(yán)格的來(lái)講屬于日志收集類(lèi)的平臺(tái)，在這里我將其歸為監(jiān)控類(lèi)，是因?yàn)槲铱粗辛似涫占瘧?yīng)用底層代碼的崩潰信息的能力，屬于業(yè)務(wù)邏輯監(jiān)控，旨在對(duì)業(yè)務(wù)系統(tǒng)運(yùn)行過(guò)程中產(chǎn)生的錯(cuò)誤日志進(jìn)行收集歸納和監(jiān)控告警。
注意這里使用的是聯(lián)邦監(jiān)控平臺(tái)，而部署普通的監(jiān)控平臺(tái)。
聯(lián)邦監(jiān)控預(yù)警平臺(tái)邏輯圖
多集群聯(lián)邦監(jiān)控預(yù)警平臺(tái)邏輯圖如下：
因?yàn)槲宜居袔讉€(gè)Kubernetes集群，如果在每個(gè)集群上都部署一套監(jiān)控預(yù)警平臺(tái)的話(huà)，管理起來(lái)太過(guò)不便，所以這里我采取的策略是使用將各監(jiān)控預(yù)警平臺(tái)實(shí)行一個(gè)聯(lián)邦的策略，使用統(tǒng)一的可視化界面管理。這里我將實(shí)現(xiàn)三個(gè)級(jí)別餓監(jiān)控：操作系統(tǒng)級(jí)、應(yīng)用程序級(jí)、業(yè)務(wù)級(jí)。對(duì)于流量的監(jiān)控可以直接針對(duì)Kong進(jìn)行監(jiān)控，模版7424。
缺少日志系統(tǒng)
隨著業(yè)務(wù)全面Kubernetes化進(jìn)程的推進(jìn)，對(duì)于日志系統(tǒng)的需求將更加渴望，Kubernetes的特性是服務(wù)的故障日志難以獲取。建立可觀測(cè)的能過(guò)濾的日志系統(tǒng)可以降低對(duì)故障的分析難度。
有關(guān)日志系統(tǒng)邏輯圖如下：
淺析：在業(yè)務(wù)全面上Kubernetes化后，方便了管理維護(hù)，但對(duì)于日志的管理難度就適當(dāng)上升了。我們知道Pod的重啟是有多因素且不可控的，而每次Pod重啟都會(huì)重新記錄日志，即新Pod之前的日志是不可見(jiàn)的。當(dāng)然了有多種方法可以實(shí)現(xiàn)日志長(zhǎng)存：遠(yuǎn)端存儲(chǔ)日志、本機(jī)掛載日志等。出于對(duì)可視化、可分析等的考慮，選擇使用Elasticsearch構(gòu)建日志收集系統(tǒng)。
極度缺少有關(guān)操作文檔
建立以語(yǔ)雀--> 運(yùn)維相關(guān)資料為中心的文檔中心，將有關(guān)操作、問(wèn)題、腳本等詳細(xì)記錄在案，以備隨時(shí)查看。
淺析因安全性原因，不便于過(guò)多同事查閱。運(yùn)維的工作比較特殊，安全化、文檔化是必須要保障的。我認(rèn)為不論是運(yùn)維還是運(yùn)維開(kāi)發(fā)，書(shū)寫(xiě)文檔都是必須要掌握的，為己也好，為他也罷。文檔可以簡(jiǎn)寫(xiě)，但必須要含苞核心的步驟。我還是認(rèn)為運(yùn)維的每一步操作都應(yīng)該記錄下來(lái)。
請(qǐng)求路線(xiàn)不明朗
根據(jù)集群重構(gòu)的新思路，重新梳理集群級(jí)流量請(qǐng)求路線(xiàn)，構(gòu)建具備：認(rèn)證、鑒權(quán)、代理、連接、保護(hù)、控制、觀察等一體的流量管理，有效控制故障爆炸范圍。
請(qǐng)求路線(xiàn)邏輯圖如下：
淺析：客戶(hù)經(jīng)過(guò)Kong網(wǎng)關(guān)鑒權(quán)后進(jìn)入特定名稱(chēng)空間（通過(guò)名稱(chēng)空間區(qū)分項(xiàng)目），因?yàn)榉?wù)已經(jīng)拆分為微服務(wù)，服務(wù)間通信經(jīng)過(guò)Istio認(rèn)證、授權(quán)，需要和數(shù)據(jù)庫(kù)交互的去找數(shù)據(jù)庫(kù)，需要寫(xiě)或者讀存儲(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)、以語(yǔ)雀為核心的文檔管理中心、以Kong及Istio為核心的南北東西流量一體化服務(wù)，可以在高平發(fā)，高可靠性上做到很好保障。
附總體架構(gòu)邏輯圖：
注：請(qǐng)根據(jù)箭頭和顏色來(lái)分析。
淺析：上圖看著似乎過(guò)于混亂，靜下心來(lái)，根據(jù)上面的拆分模塊一層層分析還是可以看清晰的。這里我用不同顏色的連線(xiàn)代表不同模塊的系統(tǒng)，根據(jù)箭頭走還是蠻清晰的。
根據(jù)我司目前的業(yè)務(wù)流量，上述功能模塊，理論上可以實(shí)現(xiàn)集群的維穩(wěn)。私認(rèn)為此套方案可以確保業(yè)務(wù)在Kubernetes集群上穩(wěn)定的運(yùn)行一段時(shí)間，再有問(wèn)題就屬于代碼層面的問(wèn)題了。這里沒(méi)有使用到中間件，倒是使用到了緩存Redis不過(guò)沒(méi)畫(huà)出來(lái)。我規(guī)劃在上圖搞定后再在日志系統(tǒng)哪里和轉(zhuǎn)換服務(wù)哪里增加個(gè)中間件Kafka或者RQ看情況吧。
網(wǎng)站欄目：一個(gè)完整的全面Kubernetes化的集群穩(wěn)定架構(gòu)
鏈接URL：http://m.5511xx.com/article/cddsdoi.html
