集群时刻处于崩溃的边缘，通过近三个月的掌握，发现我司的集群不稳定的原因有以下几点：

• 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为核心的南北东西流量一体化服务，可以在高平发，高可靠性上做到很好保障。