共计 2977 个字符，预计需要花费 8 分钟才能阅读完成。
起源：https://www.cnblogs.com/zisefeizhu/p/13692782.html
前言
我司的集群时刻处于解体的边缘，通过近三个月的把握，发现我司的集群不稳固的起因有以下几点：
1、发版流程不稳固
2、短少监控平台【最重要的起因】
3、短少日志零碎
4、极度短少无关操作文档
5、申请路线不明朗
总的来看，问题的次要起因是短少可预知的监控平台，总是等问题呈现了才晓得。主要的起因是服务器作用不明朗和发版流程的不稳固。
举荐一个开源收费的 Spring Boot 实战我的项目：
https://github.com/javastacks/spring-boot-best-practice
解决方案
发版流程不稳固
重构发版流程。业务全面 k8s 化，构建以 kubernetes 为外围的 ci/cd 流程。
发版流程
无关发版流程如下：
浅析：研发人员提交代码到 developer 分支 (时刻确保 developer 分支处于最新的代码)，developer 分支合并到须要发版环境对应的分支，触发企业微信告警，触发部署在 k8s 集群的 gitlab-runner pod，新启 runner pod 执行 ci/cd 操作。在这个过程中须要有三个步骤：测试用例、打包镜像、更新 pod。
第一次部署服务在 k8s 集群环境的时候可能须要：创立 namespace、创立 imagepullsecret、创立 pv(storageclass)、创立 deployment（pod controller）、创立 svc、创立 ingress、等。其中镜像打包推送阿里云仓库和从阿里云仓库下载镜像应用 vpc 拜访，不走公网，无网速限度。流程结束，runner pod 销毁，gitlab 返回后果。
须要强调的一点是，在这里的资源资源清单不蕴含 configmap 或者 secret，牵扯到安全性的问题，不应该出
当初代码仓库中，我司是应用 rancher 充当 k8s 多集群治理平台，上述平安问题在 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
短少监控预警平台
构建可信赖且合乎我司集群环境的联邦监控平台，实现对几个集群环境的同时监控和预故障告警，提前染指。
监控预警逻辑图
无关监控预警逻辑图如下：
浅析：总的来说，我这里应用到的监控计划是 prometheus➕shell 脚本或 go 脚本➕sentry。应用到的告警形式是企业微信或者企业邮箱。上图三种色彩的线代表三种监控形式须要留神。
脚本次要是用来做备份告警、证书告警、抓贼等。prometheus 这里采纳的是依据 prometheus-opertor 批改的 prometheus 资源清单，数据存储在 nas 上。sentry 严格的来讲属于日志收集类的平台，在这里我将其归为监控类，是因为我看中了其收集利用底层代码的解体信息的能力，属于业务逻辑监控, 旨在对业务零碎运行过程中产生的谬误日志进行收集演绎和监控告警。
留神这里应用的是联邦监控平台，而部署一般的监控平台。
联邦监控预警平台逻辑图
多集群联邦监控预警平台逻辑图如下：
因为我司有几个 k8s 集群，如果在每个集群上都部署一套监控预警平台的话，治理起来太过不便，所以这里我采取的策略是应用将各监控预警平台履行一个联邦的策略，应用对立的可视化界面治理。这里我将实现三个级别饿监控：操作系统级、应用程序级、业务级。对于流量的监控能够间接针对 kong 进行监控，模版 7424。
短少日志零碎
随着业务全面 k8s 化过程的推动，对于日志零碎的需要将更加渴望，k8s 的个性是服务的故障日志难以获取。建设可观测的能过滤的日志零碎能够升高对故障的剖析难度。
无关日志零碎逻辑图如下：
浅析：在业务全面上 k8s 化后，不便了治理保护，但对于日志的治理难度就适当回升了。咱们晓得 pod 的重启是有多因素且不可控的，而每次 pod 重启都会从新记录日志，即新 pod 之前的日志是不可见的。当然了有多种办法能够实现日志长存：远端存储日志、本机挂载日志等。出于对可视化、可剖析等的思考，抉择应用 elasticsearch 构建日志收集零碎。
极度短少无关操作文档
建设以语雀 –> 运维相干材料为核心的文档核心，将无关操作、问题、脚本等具体记录在案，以备随时查看。
浅析因安全性起因，不便于过多共事查阅。运维的工作比拟非凡，平安化、文档化是必须要保障的。我认为不论是运维还是运维开发，书写文档都是必须要把握的，为己也好，为他也罢。文档能够简写，但必须要含苞外围的步骤。我还是认为运维的每一步操作都应该记录下来。
申请路线不明朗
依据集群重构的新思路，从新梳理集群级流量申请路线，构建具备：认证、鉴权、代理、连贯、爱护、管制、察看等一体的流量治理，无效管制故障爆炸范畴。
申请路线逻辑图如下：
浅析：客户拜访 https://www.cnblogs.com/zisefeizhu 通过 kong 网关鉴权后进入特定名称空间 (通过名称空间辨别我的项目)，因为服务曾经拆分为微服务，服务间通信通过 istio 认证、受权，须要和数据库交互的去找数据库，须要写或者读存储的去找 pv，须要转换服务的去找转换服务 …… 而后返回响应。
总结
综上所述，构建以：以 kubernetes 为外围的 ci/cd 发版流程、以 prometheus 为外围的联邦监控预警平台、以 elasticsearch 为外围的日志收集零碎、以语雀为外围的文档管理中心、以 kong 及 istio 为外围的南北货色流量一体化服务，能够在高平发，高可靠性上做到很好保障。
附：总体架构逻辑图
注：请依据箭头和色彩来剖析。
浅析：上图看着仿佛过于凌乱，静下心来，依据下面的拆分模块一层层剖析还是能够看清晰的。这里我用不同色彩的连线代表不同模块的零碎，依据箭头走还是蛮清晰的。
依据我司目前的业务流量，上述功能模块，实践上能够实现集群的维稳。私认为此套计划能够确保业务在 k8s 集群上稳固的运行一段时间，再有问题就属于代码层面的问题了。这里没有应用到中间件，倒是应用到了缓存 redis 不过没画进去。我布局在上图搞定后再在日志零碎哪里和转换服务哪里减少个中间件 kafka 或者 rq 看状况吧。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿 (2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
