基于k8s的集群稳定架构

前言

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

一、发版流程不稳定

二、缺乏监控平台【最重要的缘由】

三、缺乏日志系统

四、极度缺乏有关操做文档

五、请求路线不明朗

总的来看，问题的主要缘由是缺乏可预知的监控平台，老是等问题出现了才知道。次要的缘由是服务器做用不明朗和发版流程的不稳定。

解决方案

发版流程不稳定

重构发版流程。业务全面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模版，应用于全部的环境，毕竟怎么省事怎么来。

缺乏监控预警平台

构建可信赖且符合我司集群环境的联邦监控平台，实现对几个集群环境的同时监控和预故障告警，提早介入。

监控预警逻辑图

有关监控预警逻辑图以下：

浅析：总的来讲，我这里使用到的监控方案是prometheus+shell脚本或go脚本+sentry。使用到的告警方式是企业微信或者企业邮箱。上图三种颜色的线表明三种监控方式须要注意。脚本主要是用来作备份告警、证书告警、抓贼等。prometheus这里采用的是根据prometheus-opertor修改的prometheus资源清单，数据存储在nas上。sentry严格的来说属于日志收集类的平台，在这里我将其归为监控类，是由于我看中了其收集应用底层代码的崩溃信息的能力，属于业务逻辑监控, 旨在对业务系统运行过程当中产生的错误日志进行收集概括和监控告警。

注意这里使用的是联邦监控平台，而部署普通的监控平台。

联邦监控预警平台逻辑图

多集群联邦监控预警平台逻辑图以下：

由于我司有几个k8s集群，若是在每一个集群上都部署一套监控预警平台的话，管理起来太过不便，因此这里我采起的策略是使用将各监控预警平台实行一个联邦的策略，使用统一的可视化界面管理。这里我将实现三个级别饿监控：操做系统级、应用程序级、业务级。对于流量的监控能够直接针对kong进行监控，模版7424。

缺乏日志系统

随着业务全面k8s化进程的推动，对于日志系统的需求将更加渴望，k8s的特性是服务的故障日志难以获取。创建可观测的能过滤的日志系统能够下降对故障的分析难度。

有关日志系统逻辑图以下：

浅析：在业务全面上k8s化后，方便了管理维护，但对于日志的管理难度就适当上升了。咱们知道pod的重启是有多因素且不可控的，而每次pod重启都会从新记录日志，即新pod以前的日志是不可见的。固然了有多种方法能够实现日志长存：远端存储日志、本机挂载日志等。出于对可视化、可分析等的考虑，选择使用elasticsearch构建日志收集系统。

极度缺乏有关操做文档

创建以语雀–> 运维相关资料为中心的文档中心，将有关操做、问题、脚本等详细记录在案，以备随时查看。

浅析因安全性缘由，不便于过多同事查阅。运维的工做比较特殊，安全化、文档化是必需要保障的。我认为不管是运维仍是运维开发，书写文档都是必需要掌握的，为己也好，为他也罢。文档能够简写，但必需要含苞核心的步骤。我仍是认为运维的每一步操做都应该记录下来。

请求路线不明朗

根据集群重构的新思路，从新梳理集群级流量请求路线，构建具有：认证、鉴权、代理、链接、保护、控制、观察等一体的流量管理，有效控制故障爆炸范围。

请求路线逻辑图以下：

浅析：通过kong网关鉴权后进入特定名称空间(经过名称空间区分项目)，由于服务已经拆分为微服务，服务间通讯通过istio认证、受权，须要和数据库交互的去找数据库，须要写或者读存储的去找pv，须要转换服务的去找转换服务… 而后返回响应。

总结

综上所述，构建以：以kubernetes为核心的ci/cd发版流程、以prometheus为核心的联邦监控预警平台、以elasticsearch为核心的日志收集系统、以语雀为核心的文档管理中心、以kong及istio为核心的南北东西流量一体化服务，能够在高平发，高可靠性上作到很好保障。

附：整体架构逻辑图

注：请根据箭头和颜色来分析。

浅析：上图看着彷佛过于混乱，静下心来，根据上面的拆分模块一层层分析仍是能够看清晰的。这里我用不一样颜色的连线表明不一样模块的系统，根据箭头走仍是蛮清晰的。

根据我司目前的业务流量，上述功能模块，理论上能够实现集群的维稳。私认为此套方案能够确保业务在k8s集群上稳定的运行一段时间，再有问题就属于代码层面的问题了。这里没有使用到中间件，却是使用到了缓存redis不过没画出来。我规划在上图搞定后再在日志系统哪里和转换服务哪里增长个中间件kafka或者rq 看状况吧。

最后

感谢你们看到这里，文章有不足，欢迎你们指出；若是你以为写得不错，那就给我一个赞吧。