前言
我司的集群时刻处于崩溃的边缘，通过近三个月的掌握，发现我司的集群不稳定的原因有以下几点：
发版流程不稳定
缺少监控平台（重要的原因）
缺少日志系统
极度缺少有关操作文档
请求路线不明朗
总的来看，问题的主要原因是缺少可预知的监控平台，总是等问题出现了才知道。次要的原因是服务器作用不明朗和发版流程的不稳定。
解决方案
发版流程不稳定
重构发版流程。业务全面 Kubernetes 化，构建以Kubernetes为核心的CI/CD流程。
发版流程
有关发版流程如下：
浅析：研发人员提交代码到developer分支（时刻确保developer分支处于新的代码），developer分支合并到需要发版环境对应的分支，触发企业微信告警，触发部署在Kubernetes集群的gitlab-runner Pod，新启runner Pod 执行CI/CD操作。在这个过程中需要有三个步骤：测试用例、打包镜像、更新Pod。次部署服务在Kubernetes集群环境的时候可能需要：创建Namespace、创建imagePullSecret、创建PV（StorageClass）、创建deployment（Pod controller）、创建SVC、创建Ingress等。其中镜像打包推送阿里云仓库和从阿里云仓库下载镜像使用VPC访问，不走公网，无网速限制。流程完毕，runner Pod销毁，GitLab返回结果。
需要强调的一点是，在这里的资源资源清单不包含ConfigMap或者Secret，牵扯到安全性的问题，不应该出现在代码仓库中，我司是使用Rancher充当Kubernetes多集群管理平台，上述安全问题在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模版，应用于所有的环境，毕竟怎么省事怎么来。还要考虑自己的分支模式，具体参考：https://www.cnblogs.com/zisefeizhu/p/13621797.html
缺少监控预警平台
构建可信赖且符合我司集群环境的联邦监控平台，实现对几个集群环境的同时监控和预故障告警，提前介入。
监控预警逻辑图
有关监控预警逻辑图如下：
联邦监控预警平台逻辑图
多集群联邦监控预警平台逻辑图如下：
因为我司有几个Kubernetes集群，如果在每个集群上都部署一套监控预警平台的话，管理起来太过不便，所以这里我采取的策略是使用将各监控预警平台实行一个联邦的策略，使用统一的可视化界面管理。这里我将实现三个级别饿监控：操作系统级、应用程序级、业务级。对于流量的监控可以直接针对Kong进行监控，模版7424。
缺少日志系统
随着业务全面Kubernetes化进程的推进，对于日志系统的需求将更加渴望，Kubernetes的特性是服务的故障日志难以获取。建立可观测的能过滤的日志系统可以降低对故障的分析难度。
有关日志系统逻辑图如下：
浅析：在业务全面上Kubernetes化后，方便了管理维护，但对于日志的管理难度就适当上升了。我们知道Pod的重启是有多因素且不可控的，而每次Pod重启都会重新记录日志，即新Pod之前的日志是不可见的。当然了有多种方法可以实现日志长存：远端存储日志、本机挂载日志等。出于对可视化、可分析等的考虑，选择使用Elasticsearch构建日志收集系统。
极度缺少有关操作文档
建立以语雀→ 运维相关资料为中心的文档中心，将有关操作、问题、脚本等详细记录在案，以备随时查看。
浅析因安全性原因，不便于过多同事查阅。运维的工作比较特殊，安全化、文档化是必须要保障的。我认为不论是运维还是运维开发，书写文档都是必须要掌握的，为己也好，为他也罢。文档可以简写，但必须要含苞核心的步骤。我还是认为运维的每一步操作都应该记录下来。
请求路线不明朗
根据集群重构的新思路，重新梳理集群级流量请求路线，构建具备：认证、鉴权、代理、连接、保护、控制、观察等一体的流量管理，有效控制故障爆炸范围。
浅析：客户经过Kong网关鉴权后进入特定名称空间（通过名称空间区分项目），因为服务已经拆分为微服务，服务间通信经过Istio认证、授权，需要和数据库交互的去找数据库，需要写或者读存储的去找PV，需要转换服务的去找转换服务……然后返回响应。
总结
附总体架构逻辑图：
