作者：紫色飛豬
我司的集群時刻處於崩潰的邊緣，通過近三個月的掌握，發現我司的集群不穩定的原因有以下幾點：
1、發版流程不穩定
2、缺少監控平台【最重要的原因】
3、缺少日誌系統
4、極度缺少有關操作文件
5、請求路線不明朗
總的來看，問題的主要原因是缺少可預知的監控平台，總是等問題出現了才知道。次要的原因是伺服器作用不明朗和發版流程的不穩定。
重構發版流程。業務全面k8s化，構建以kubernetes為核心的ci/cd流程。
發版流程
有關發版流程如下：
需要強調的一點是，在這裡的資源資源清單不包含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模版，應用於所有的環境，畢竟怎麼省事怎麼來。還要考慮自己的分支模式。
具體參考：
構建可信賴且符合我司集群環境的聯邦監控平台，實現對幾個集群環境的同時監控和預故障告警，提前介入。
監控預警邏輯圖
有關監控預警邏輯圖如下：
上圖三種顏色的線代表三種監控方式需要注意。指令碼主要是用來做備份告警、證書告警、抓賊等。prometheus這裡採用的是根據prometheus-opertor修改的prometheus資源清單，資料儲存在nas上。
sentry嚴格的來講屬於日誌收集類的平台，在這裡我將其歸為監控類，是因為我看中了其收集應用底層**的崩潰資訊的能力，屬於業務邏輯監控, 旨在對業務系統執行過程中產生的錯誤日誌進行收集歸納和監控告警。
注意這裡使用的是聯邦監控平台，而部署普通的監控平台。
聯邦監控預警平台邏輯圖
多集群聯邦監控預警平台邏輯圖如下：
因為我司有幾個k8s集群，如果在每個集群上都部署一套監控預警平台的話，管理起來太過不便，所以這裡我採取的策略是使用將各監控預警平台實行乙個聯邦的策略，使用統一的視覺化介面管理。
這裡我將實現三個級別餓監控：作業系統級、應用程式級、業務級。對於流量的監控可以直接針對kong進行監控，模版7424。
隨著業務全面k8s化程序的推進，對於日誌系統的需求將更加渴望，k8s的特性是服務的故障日誌難以獲取。建立可觀測的能過濾的日誌系統可以降低對故障的分析難度。
有關日誌系統邏輯圖如下：
**：在業務全面上k8s化後，方便了管理維護，但對於日誌的管理難度就適當上公升了。我們知道pod的重啟是有多因素且不可控的，而每次pod重啟都會重新記錄日誌，即新pod之前的日誌是不可見的。
當然了有多種方法可以實現日誌長存：遠端儲存日誌、本機掛載日誌等。出於對視覺化、可分析等的考慮，選擇使用elasticsearch構建日誌收集系統。
建立以語雀--> 運維相關資料為中心的文件中心，將有關操作、問題、指令碼等詳細記錄在案，以備隨時檢視。
**因安全性原因，不便於過多同事查閱。運維的工作比較特殊，安全化、文件化是必須要保障的。我認為不論是運維還是運維開發，書寫文件都是必須要掌握的，為己也好，為他也罷。文件可以簡寫，但必須要含苞核心的步驟。我還是認為運維的每一步操作都應該記錄下來。
根據集群重構的新思路，重新梳理集群級流量請求路線，構建具備：認證、鑑權、**、連線、保護、控制、觀察等一體的流量管理，有效控制故障**範圍。
請求路線邏輯圖如下：
**：客戶訪問經過kong閘道器鑑權後進入特定命名空間(通過命名空間區分專案)，因為服務已經拆分為微服務，服務間通訊經過istio認證、授權，需要和資料庫互動的去找資料庫，需要寫或者讀儲存的去找pv，需要轉換服務的去找轉換服務...... 然後返回響應。
綜上所述，構建以：以kubernetes為核心的ci/cd發版流程、以prometheus為核心的聯邦監控預警平台、以elasticsearch為核心的日誌收集系統、以語雀為核心的文件管理中心、以kong及istio為核心的南北東西流量一體化服務，可以在高平發，高可靠性上做到很好保障。
附：總體架構邏輯圖
注：請根據箭頭和顏色來分析。
**：上圖看著似乎過於混亂，靜下心來，根據上面的拆分模組一層層分析還是可以看清晰的。這裡我用不同顏色的連線代表不同模組的系統，根據箭頭走還是蠻清晰的。
根據我司目前的業務流量，上述功能模組，理論上可以實現集群的維穩。私認為此套方案可以確保業務在k8s集群上穩定的執行一段時間，再有問題就屬於**層面的問題了。
這裡沒有使用到中介軟體，倒是使用到了快取redis不過沒畫出來。我規劃在上圖搞定後再在日誌系統**和轉換服務**增加個中介軟體kafka或者rq 看情況吧。
推薦好文
強大，10k+點讚的 springboot 後台管理系統竟然出了詳細教程！
分享一套基於springboot和vue的企業級中後台開源專案，**很規範！
能掙錢的，開源 springboot **系統，功能超全，超漂亮！
k8s與CICD 乙個完整的drone demo
先上配置檔案，有乙個大概的認識，再逐一解讀。工作空間，就是乙個可以被pipeline各個階段共享volume和工作路徑的東東，好處就是避免了各種cd和拷貝。由於該demo專案使用golang。所以設定路徑是 go src gogs.com baa cicd。git plugin 是乙個預設的外掛程式...
k8s集群中的儲存持久化概述
儲存分類 直連式儲存，集中式共享儲存，分布式儲存 檔案儲存，塊儲存，物件儲存 das，nas，san das屬於直連式儲存，將儲存裝置通過scsi介面或者光纖通道直接和主機板連線，不能實現資料共享 nas和san屬於集中式共享儲存 nas使用nfs和cifs 原來叫smb,微軟的 協議 san分為f...
K8S修改乙個節點的名字
部署了乙個k8s一主兩從，不幸的是忘記了初始化從節點的host name,node那一欄一長串的字串非常不友好，必須要解決這個問題。root izhp31kuvshz2kea5g99lpz kubectl get pods a o wide namespace name ready status r...