叢集時刻處于崩潰的邊緣，通過近三個月的掌握，發現我司的叢集不穩定的原因有以下幾點：
- 1、發版流程不穩定
- 2、缺少監控平台【最重要的原因】
- 3、缺少日志系統
- 4、極度缺少有關操作文檔
- 5、請求路線不明朗
總的來看，問題的主要原因是缺少可預知的監控平台，總是等問題出現了才知道。次要的原因是伺服器作用不明朗和發版流程的不穩定。
重構發版流程。業務全面k8s化，建構以kubernetes為核心的ci/cd流程。
發版流程
有關發版流程如下：
在這個過程中需要有三個步驟：測試用例、打包鏡像、更新pod。
第一次部署服務在k8s叢集環境的時候可能需要：建立namespace、建立imagepullsecret、建立pv(storageclass)、建立deployment（pod controller）、建立svc、建立ingress、等。其中鏡像打包推送阿裡雲倉庫和從阿裡雲倉庫下載下傳鏡像使用vpc通路，不走公網，無網速限制。流程完畢，runner pod 銷毀，gitlab 傳回結果。
有關服務部署邏輯圖如下：
随着業務全面k8s化程序的推進，對于日志系統的需求将更加渴望，k8s的特性是服務的故障日志難以擷取。建立可觀測的能過濾的日志系統可以降低對故障的分析難度。
建構以：以kubernetes為核心的ci/cd發版流程、以prometheus為核心的聯邦監控預警平台、以elasticsearch為核心的日志收集系統、以語雀為核心的文檔管理中心、以kong及istio為核心的南北東西流量一體化服務，可以在高平發，高可靠性上做到很好保障。