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