基於k8s的集羣穩定架構-轉載

基於k8s的集羣穩定架構-轉載

前言

我司的集羣時刻處於崩潰的邊緣，經過近三個月的掌握，發現我司的集羣不穩定的緣由有如下幾點：

一、發版流程不穩定

二、缺乏監控平臺【最重要的緣由】

三、缺乏日誌系統

四、極度缺乏有關操做文檔

五、請求路線不明朗

總的來看，問題的主要緣由是缺乏可預知的監控平臺，老是等問題出現了才知道。次要的緣由是服務器做用不明朗和發版流程的不穩定。

解決方案

發版流程不穩定

重構發版流程。業務全面k8s化，構建以kubernetes爲核心的ci/cd流程。

發版流程

有關發版流程以下：

淺析：研發人員提交代碼到developer分支(時刻確保developer分支處於最新的代碼)，developer分支合併到須要發版環境對應的分支，觸發企業微信告警，觸發部署在k8s集羣的gitlab-runner pod，新啓runner pod 執行ci/cd操做。在這個過程當中須要有三個步驟：測試用例、打包鏡像、更新pod。第一次部署服務在k8s集羣環境的時候可能須要：建立namespace、建立imagepullsecret、建立pv(storageclass)、建立deployment（pod controller）、建立svc、建立ingress、等。其中鏡像打包推送阿里雲倉庫和從阿里雲倉庫下載鏡像使用vpc訪問，不走公網，無網速限制。流程完畢，runner pod 銷燬，gitlab 返回結果。

須要強調的一點是，在這裏的資源資源清單不包含configmap或者secret，牽扯到安全性的問題，不該該出

如今代碼倉庫中，我司是使用rancher充當k8s多集羣管理平臺，上述安全問題在rancher的dashboard中由運維來作的。

服務部署邏輯圖

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

根據發版流程的淺析，再根據邏輯圖能夠明確發版流程。在這裏看到我司使用的是kong代替nginx，作認證、鑑權、代理。而slb的ip綁定在kong上。0，1，2屬於test job；3屬於build job；4，5，6，7屬於change pod 階段。並不是全部的服務都須要作存儲，須要根據實際狀況來定，因此須要在kubernetes.sh裏寫判斷。在這裏我試圖使用一套CI應用與全部的環境，因此須要在kubernetes.sh中用到的判斷較多，且.gitlab-ci.yml顯得過多。建議是使用一個ci模版，應用於全部的環境，畢竟怎麼省事怎麼來。還要考慮本身的分支模式，具體參考：http://www.javashuo.com/article/p-qsepzqop-nn.html

缺乏監控預警平臺

構建可信賴且符合我司集羣環境的聯邦監控平臺，實現對幾個集羣環境的同時監控和預故障告警，提早介入。

監控預警邏輯圖

有關監控預警邏輯圖以下：

淺析：總的來講，我這裏使用到的監控方案是prometheus➕shell腳本或go腳本➕sentry。使用到的告警方式是企業微信或者企業郵箱。上圖三種顏色的線表明三種監控方式須要注意。腳本主要是用來作備份告警、證書告警、抓賊等。prometheus這裏採用的是根據prometheus-opertor修改的prometheus資源清單，數據存儲在nas上。sentry嚴格的來說屬於日誌收集類的平臺，在這裏我將其歸爲監控類，是由於我看中了其收集應用底層代碼的崩潰信息的能力，屬於業務邏輯監控, 旨在對業務系統運行過程當中產生的錯誤日誌進行收集概括和監控告警。

注意這裏使用的是聯邦監控平臺，而部署普通的監控平臺。

聯邦監控預警平臺邏輯圖

多集羣聯邦監控預警平臺邏輯圖以下：

由於我司有幾個k8s集羣，若是在每一個集羣上都部署一套監控預警平臺的話，管理起來太過不便，因此這裏我採起的策略是使用將各監控預警平臺實行一個聯邦的策略，使用統一的可視化界面管理。這裏我將實現三個級別餓監控：操做系統級、應用程序級、業務級。對於流量的監控能夠直接針對kong進行監控，模版7424。

缺乏日誌系統

隨着業務全面k8s化進程的推動，對於日誌系統的需求將更加渴望，k8s的特性是服務的故障日誌難以獲取。創建可觀測的能過濾的日誌系統能夠下降對故障的分析難度。

有關日誌系統邏輯圖以下：

淺析：在業務全面上k8s化後，方便了管理維護，但對於日誌的管理難度就適當上升了。咱們知道pod的重啓是有多因素且不可控的，而每次pod重啓都會從新記錄日誌，即新pod以前的日誌是不可見的。固然了有多種方法能夠實現日誌長存：遠端存儲日誌、本機掛載日誌等。出於對可視化、可分析等的考慮，選擇使用elasticsearch構建日誌收集系統。

極度缺乏有關操做文檔

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

淺析因安全性緣由，不便於過多同事查閱。運維的工做比較特殊，安全化、文檔化是必需要保障的。我認爲不管是運維仍是運維開發，書寫文檔都是必需要掌握的，爲己也好，爲他也罷。文檔能夠簡寫，但必需要含苞核心的步驟。我仍是認爲運維的每一步操做都應該記錄下來。

請求路線不明朗

根據集羣重構的新思路，從新梳理集羣級流量請求路線，構建具有：認證、鑑權、代理、鏈接、保護、控制、觀察等一體的流量管理，有效控制故障爆炸範圍。

請求路線邏輯圖以下：

淺析：客戶訪問https://www.cnblogs.com/zisefeizhu 通過kong網關鑑權後進入特定名稱空間(經過名稱空間區分項目)，由於服務已經拆分爲微服務，服務間通訊通過istio認證、受權，須要和數據庫交互的去找數據庫，須要寫或者讀存儲的去找pv，須要轉換服務的去找轉換服務...... 而後返回響應。

總結

綜上所述，構建以：以kubernetes爲核心的ci/cd發版流程、以prometheus爲核心的聯邦監控預警平臺、以elasticsearch爲核心的日誌收集系統、以語雀爲核心的文檔管理中心、以kong及istio爲核心的南北東西流量一體化服務，能夠在高平發，高可靠性上作到很好保障。

附：整體架構邏輯圖

注：請根據箭頭和顏色來分析。

淺析：上圖看着彷佛過於混亂，靜下心來，根據上面的拆分模塊一層層分析仍是能夠看清晰的。這裏我用不一樣顏色的連線表明不一樣模塊的系統，根據箭頭走仍是蠻清晰的。

根據我司目前的業務流量，上述功能模塊，理論上能夠實現集羣的維穩。私認爲此套方案能夠確保業務在k8s集羣上穩定的運行一段時間，再有問題就屬於代碼層面的問題了。這裏沒有使用到中間件，卻是使用到了緩存redis不過沒畫出來。我規劃在上圖搞定後再在日誌系統哪裏和轉換服務哪裏增長箇中間件kafka或者rq 看狀況吧。

參考：http://www.javashuo.com/article/p-fgwvrlwb-no.html

參考2: 個人容器之旅：https://www.cnblogs.com/zisefeizhu/category/1513596.html
羽雀參考：https://www.yuque.com/wangfangping