1.前言我们公司的集群一直处于崩溃的边缘。经过将近三个月的掌握，发现我们集群不稳定的原因有以下几点：1.发布过程不稳定2.缺少监控平台[最重要的原因]3.缺少日志系统4.极度缺少相关操作文档5.请求路径不明确一般情况下，问题的主要原因是缺乏一个可预测的监控平台，总是等到问题出现。主要原因是服务器功能不明确，发布过程不稳定。二、解决方案1、发布流程不稳定重构发布流程。业务完全基于k8s，构建了以kubernetes为核心的ci/cd流程。1）发布流程发布流程如下：简要分析：研发人员向developer分支提交代码（确保developer分支始终是最新的代码），developer分支合并到对应的分支中发布环境，触发企业微信告警并触发在k8s集群中部署gitlab-runnerpod，并启动新的runnerpod进行ci/cd操作。这个过程分为三个步骤：测试用例、打包镜像和更新Pod。在k8s集群环境下首次部署服务时，可能需要：创建namespace、创建imagepullsecret、创建pv(storageclass)、创建deployment(podcontroller)、创建svc、创建ingress等，其中image打包推送到阿里云仓库，从阿里云仓库下载的镜像使用VPC访问，不走公网，无网速限制。流程完成后，runnerpod被销毁，gitlab返回结果。需要强调的是这里的resource资源列表不包括configmap或者secret，涉及到安全问题，不应该出现在代码仓库中。我们公司使用rancher作为k8s多集群管理平台。以上安全问题都是在rancherdashboard中通过运维来完成的。2）服务部署逻辑图相关服务部署逻辑图如下：根据发布流程的分析，可以根据逻辑图理清发布流程。这里可以看到我们公司使用的是kong而不是nginx来进行鉴权、鉴权、代理。而slb的ip是绑定kong的。0、1、2属于测试作业；3属于buildjob；4、5、6、7属于变化荚阶段。并不是所有的服务都需要存储，需要根据实际情况来确定，所以需要把判断写在kubernetes.sh中。这里我是尝试使用一套CI应用和所有环境，所以需要在kubernetes.sh中进行更多的判断，而.gitlab-ci.yml似乎太多了。建议是用一个ci模板，适用于所有环境，毕竟怎么省事。还要考虑您自己的分支模式。2、缺乏监测预警平台。搭建一个符合我们集群环境的可靠的联邦监控平台，实现对多个集群环境的同步监控和故障预警，提前干预。1）监控预警逻辑图相关监控预警逻辑图如下：分析：一般情况下，我这里使用的监控方案是prometheus+shellscript或者goscript+sentry。使用的报警方式为企业微信或企业邮箱。上图中的三色线代表需要注意的三种监控方式。该脚本主要用于备份告警、证书告警、抓小偷等，这里的prometheus使用的是根据prometheus-opertor修改的prometheus资源列表，数据存放在nas上。严格来说，Sentry属于日志采集平台。这里我把它归为监控类，因为我喜欢它能够收集应用程序底层代码的崩溃信息。属于业务逻辑监控，旨在运行业务系统。对过程中产生的错误日志进行收集、汇总和监控告警。注意这里使用的是联邦监控平台，部署的是普通监控平台。2）联邦监控预警平台逻辑图多集群联邦监控预警平台逻辑图如下：因为我们公司有好几个k8s集群，如果一个监控预警管理起来太不方便了每个集群上都部署了预警平台，所以这里我采用的策略是对每个监控预警平台实施联邦策略，使用统一的可视化界面进行管理。这里我将实现三个层次的监控：操作系统级、应用程序级、业务级。流量监控可以直接监控kong，模板7424。3.日志系统缺失随着基于k8s的业务全面推进，对日志系统的需求会更加迫切。k8s的特点是服务故障日志获取困难。建立一个可观察、可过滤的日志系统，可以降低分析故障的难度。日志系统逻辑图如下：分析：业务完全在k8s上实现后，方便了管理和维护，但是日志管理的难度适当增加了。我们知道pod的重启是多因素的、不可控的，每次pod重启都会重新记录日志，即新pod之前的日志是不可见的。当然，实现日志长期存储的方式有很多：远程存储日志、本地挂载日志等。出于可视化、分析等方面的考虑，我选择使用elasticsearch搭建日志收集系统。4、相关操作文件极度缺乏。建立以语雀为中心的文档中心-->运维相关资料，详细记录相关操作、问题、脚本等，方便随时查看。分析：出于安全考虑，同事太多不方便查看。运维工作比较特殊，必须保证安全和文档。我觉得无论是运维还是运维开发，写文档都是必须要掌握的，不管是为自己还是为他。文档可以精简，但一定要包含核心步骤。我还是觉得运维的每一步都应该记录下来。5、请求路径不明确。根据集群重构新思路，重组集群级流量请求路由，构建鉴权、鉴权、代理、连接、保护、控制、观察等一体化流量管理，有效控制范围故障爆炸。.请求路由逻辑图如下：分析：客户访问https://www.cnblogs.com/zisefeizhu，通过kong网关认证后进入特定命名空间（通过命名空间区分项目），因为服务已经拆分成微服务，服务互通由istio认证授权。需要和数据库交互的去数据库；3.总结综上所述，建设基于：以kubernetes为核心的ci/cd发布流程，以prometheus为核心的联邦监控预警平台，以elasticsearch为核心的日志采集系统，以语雀为核心的文档管理核心中心，以及以kong和istio为中心的北-南-东-东流量一体化服务，在高层分布和高可靠方面都可以得到很好的保障。附：整体架构逻辑图注：请根据箭头和颜色进行分析。分析：上图好像太乱了，静下心来，根据上面拆分模块逐层分析还是可以看清楚的。这里我用不同颜色的线来表示不同模块的系统，顺着箭头走就很清楚了。根据我公司目前的业务流程，以上功能模块理论上可以维持集群的稳定性。个人认为这套方案可以保证业务在k8s集群上稳定运行一段时间，如果有问题，就是代码层面的问题。这里没有使用中间件，只是使用了缓存redis但没有绘制。上图完成后我打算在日志系统和转换服务中添加一个中间件kafka或者rq，视情况而定。
