平安证券Kubernetes容器集群的DevOps实践

本文主要内容：

    1. 生产环境的高可用Master部署方案

    2. 分层的Docker镜像管理

    3. Dashboard，Prometheus，Grafana的安全实践

    4. 一个能生成所有软件包的Jenkins Job

    5. 计算资源在线配置及应用持续部署

前言：

    5月16日，美国《福布斯》杂志发布了2019年“全球上市公司2000强”排行榜（Forbes Global 2000）。2019年榜单前十分别为：工商银行、摩根大通、建设银行、农业银行、美国银行、苹果、中国平安、中国银行、荷兰皇家壳牌、富国银行。得益于营业收入、利润、资产规模、市值等各项指标的稳健增长，中国平安跻身全球第7位，较去年提升3位。

    在前面众多微信的分享系列中，对k8s的体系构成，各个概念的定义，各组件的作用等都已介绍多次，此处就不再重复这些内容。在这篇文章中，主要和大家分享一些我们平安证券在容器云时代的一些CI/CD(持续集成/交付)的积累和经验。

    平安证券成立于1991年，在近30年的时间内，积累了很多不同的IT应用，公司上下一直在紧跟IT前沿应用，践行科技赋能。

    弹指挥间，白驹过隙。

    最近两三年，Docker和k8s结合的容器云技术，席卷全球。各大公司争相使用，用以更快的交付速度，更好的软件质量，更低的硬件成本来保持企业技术竞争力。平安证券在这一技术浪潮影响之下，也投了人力物力，进行容器编排调度方面的技术积累和项目改造。目前，这一改造目前正在稳步推进之中，欢迎各位建言献策！

--------------------------------------------

    一，生产环境的高可用master部署方案    

    K8s的高可用master部署，现在网络上成熟的方案不少。大多数是基于haproxy和Keepalived实现vip的自动漂移部署。至于haproxy和Keepalived,可独立出来，也可寄生于k8s master节点。

    我司在IT设备的管理上有固定的流程，VIP这种ip地址不在标准交付范围之内。于是，我们设计了基于DNS解析的高可用方案。这种方案，是基于load bal--ancer变形而来。图示如下：

    这种构架方案，平衡了公司的组织结构和技术实现。如果真发生master挂掉，系统应用不受影响，DNS的解析切换可在十分钟内指向新的master IP，评估在可接受范围之内。

    公司内部安装master节点时，使用了基本工具是Kubeadm，但是作了脚本化改造及替换成了自己的证书生成机制。经过这样的改进之后，使用kubeadm进行集群安装时，就更有条理性，步骤更清晰，更易于在公司进行推广。

    当以dns域名的形式进行部署后，各个证书配置认证文件，就不会再以IP形式连接，而是以dns域名形式连接api-server了。如下图所示：

------------------------------

二， 分层的docker镜像管理

    接下来，我们分享一下对docker镜像的管理。Docker的企业仓库，选用的是业界流行的harbor仓库。根据公司研发语言及框架的广泛性，采用了三层镜像管理，分为公共镜像，业务基础镜像，业务镜像(tag为部署发布单)，层层叠加而成，即形成标准，又照顾了一定的灵活性。

    公共镜像：一般以alpine基础镜像，加上时区调整，简单工具。

    业务基础镜像：在公共镜像之上，加入jdk,tomcat,node,python等中间件环境。

    业务镜像：在业务基础镜像之上，再加入业务软件包。

-----------------------------------------------------

三， Dashboard,Prometheus,grafana的安全实践

    尽管在k8s本身技术栈之外，我司存在体系化的日志收集，指标监控及报警平台，为了运维工具的丰富，我们还是在k8s内集成了常用的dashboard,Prometheus,grafana组件，实现一些即时性运维操作。

    这些组件部署，我们都纳入一个统一的nginx一级url下，二级url才是各个组件的管理地址。这样的设计，主要是为了给dashborad及prometheus增加一层安全性(grafana自带登陆验证)。

    这时，可能有人有疑问，dashboard,kubectl都是可以通过cert证书及rbac机制来实现安全性的，那为什么要自己来引入nginx作安全控制呢？

    在我们的实践过程中，cert证书及rbac方式，结合ssh登陆帐号，会形成一系列复杂操作，且推广难度高，我们早期实现了这种模式，但目前公司并不具备应用条件，所以废弃了。公司的k8s集群，有专门团队负责运维，我们就针对团队设计了这个安全方案。 

   关于使用nginx统一代理dashboard,grafana,Prometheus二级目录访问

可参考：

https://blog.csdn.net/weixin_34137799/article/details/86135026

-------------------------------------------

四， 一个能生成所有软件包的jenkins job  

    在CI流水线实践，我们选用的gitlab作为源代码管理组件，jenkins作为编译组件。但为了能实现更高效标准的部署交付，公司内部实现一个项目名为prism(棱镜)的自动编译分发部署平台。在容器化时代，衍生出一个prism4k项目，专门针对k8s环境作CI/CD流程。Prism4k版的构架图如下所示：

    在这种体系下，jenkins就作为我们的一个纯编译工具和中转平台，高效的完成从源代码到镜像的生成。

    由于每个IT应用相关的变量，脚本都已组织好，放到prism4k上。故而，jenkins只需要一个job，就可以完成各样各样的镜像生成功能。其主要pipeline脚本如下(由于信息敏感，只列举主要流程，有删节)：

    在jenkins中，我们使用了一个Yet Another Docker Plugin，来进行jenkins编译集群进行docker生成时的可扩展性。作到了编译节点的容器即生即死，有编译任务时，指定节点才生成相关容器进行打包等操作。

----------------------------------------

五， 计算资源在线配置及应用持续部署

    在prism4k平台中，针对jenkins的job变量是通过网页配置的。在发布单的编译镜像过程中，会将各个变量通过api发送到jenkins，启动jenkins任务，完成指定task任务。

    Pod的实例数，cpu和内存的配置，同样通过web方式配置。

    在配置好组件所有要素之后，日常的流程就可以基于不同部门用户的权限把握，实现流水线化的软件持续交付。

    研发：新建发布单，编译软件包，形成镜像，上传harbor库。

    测试：环境流转，避免部署操作污染正在进行中的测试。

    运维：运维人员进行发布操作。

    在FAT这样的测试环境中，为加快测试进度，可灵活的为研发人员赋予运***限。但在更正式的测试环境和线上生产环境，作为金融行业的IT建设标准，则必须由运维团队成员操作。

    下面配合截图，了解一下更具体的三大步骤：

    1，发布单

    在prism4k与jenkins的api交互，我们使用了jenkins的python库。

    2，环境流转

    3，部署

    在部署操作过程中，会将这次发布的信息全面展示给运维同事，让运维同事可以进行再次审查，减少发布过程中的异常情况。

    总结：由于k8s版本的快速更新和发布，我们对于其稳定性的功能更为青睐，而对于实验性的功能，或是需要复杂运维技能的功能，则保持理智的观望态度。

    所以，我们对k8s功能只达到了中度使用。当然，就算是中度使用，k8s的运维和使用技巧，还是有很多面向在此没有涉及到，希望以后有机会，能和各位有更多的沟通和交流。愿容器技术越来越普及，运维的工作越来越有效率和质量。

----------------------------------------------------------------------

    特别鸣谢：平安证券容器运维团队 | 陈*，平安证券运维研发工程师

----------------------------------------------------------------------

    下篇博文我会把大家的问题用FAQ格式呈现，谢谢