随着国家对智能制造的大力推进，传统工业领域也在加快信息化转型。中铝视拓致力于有色金属领域的工业互联网平台的研发。本文和大家一起讨论在传统工业领域中，基于Kubernetes的容器云如何帮助企业提高信息化效率。现状
中铝是一家从事有色金属领域相关的企业，主要从事矿产资源开发、有色金属冶炼加工、相关贸易及工程技术服务等。除了本身工业领域的相关技术以外，也需要信息化系统的辅助。典型的场景就是工厂的生产管控系统和计量系统。
不同的工厂规模不一样，导致在信息化投入的力度上也不一样，所以现场的IT 资产的情况也不一样。有的工厂盈利不错，信息化水平会相对高一些，有独立的机房，有IaaS相关的基础设施，有较为完善的IT系统，有的工厂盈利不行，信息化水平就低一些，可能就只有老旧的几台低配服务器来运行所有的IT系统，系统也是比较传统的C/S的.NET 应用。
一般工厂基于安全考虑，机房不会直接和互联网通信，因此主流的在线安装的形式不适合现场的情况。针对这种情况，我们基于Ansible开发了一整套的全容器化离线安装工具，并以此为基础，提供了版本的概念，规范部署和升级。Kubernetes的基础概念之前的很多分享都已经提到了，我就不再赘述。我更多的是分享一下，我们在易用性上所作的一些工作。
Ansible 部署
基于Ansible的部署这个本身没有太多别的东西，就是按照Ansible的规范，把Kubernetes相应的组件分门别类的放好。在技术选型上，我们也基本是跟着主流走，这个看Ansible的role就能看出来。网络组件采用的是Calico，日志体系采用的是典型的ELK，监控体系采用的是Prometheus，分布式存储采用的是Gluster。
在Kubernetes的版本上，我们经历了1.8、1.10、1.14三个大版本，目前是使用的1.14.0版本。主要看中CSI 1.0和Windows节点的能力。
在整体的部署上，采用全容器化的离线部署方式，这样能极大的降低部署过程中的复杂度，也方便日后的升级。对于一个典型的组网结构来说，我们采用3个管理节点和3个存储节点，计算节点则根据实际需求去进行分配。当然也有一些极端场景下，只提供3台甚至是只有1台虚拟机，脚本本身也是适配的，不需要做额外的改动。
面向业务人员的开发运维平台
这里主要介绍一下gpass这个模块。
- cs-cloud，开发运维平台
- ELK，日志体系，采集平台所有的日志，包括业务容器、平台容器、节点产生的日志
- Monitor，监控体系，根据Prometheus采集的度量数据，进行监控和告警
cs-cloud是我们封装的面向开发人员和工厂信息科工作人员的开发运维平台，主要分三个模块：
- auth，用户体系模块
- ccapi，后端服务模块
- dashboard，前端服务模块
我们主要做了这些工作：
- 封装了Kubernetes的Java SDK，方便开发
- 整合了平台所使用的各种组件，提供统一的访问UI
- 屏蔽了部分Kubernetes的底层概念，方便开发人员理解
通过使用我们提供的平台，开发人员可以很方便的部署出自己开发的服务，不需要了解底层的技术细节。
左上方是环境选择菜单，用户登录之后，只会看到和自己相关的环境，这个就是对标的namespace。
右上方是当前环境下的一些公共内容，这里比Kubernetes多出来的就是应用商店。
对于用户来说，他主要关心自己部署的服务。平台中的服务是Kubernetes中多个概念的综合体，包含了deployment、service等概念。我们增加了一个服务组的逻辑概念，来方便用于对关联度较高的服务进行分组，方便展示和查看。
在部署一个新的服务的时候，我们提供了一个综合性的标签页，在大部分情况下，能够满足部署一个新服务所需的功能。这样用户不需要去关心Kubernetes底层的那些概念，更多的是关心服务本身，降低了上手难度。
对于之前提到的应用商店，是我们对一些使用频率较高的公共服务做的一些封装，尤其是一些配置项较多，或者有相互关联的服务，方便部署。主要涉及的是Spring Cloud相关的服务。
因为一些遗留原因，部分服务会使用到Spring Cloud作为微服务框架进行开发。所以我们提供了一个全套的Spring Cloud应用，包括Config、Zuul、Oauth2、Eureka、Hystrix Dashboard，一键部署出整套环境。
DevOps 实践
为了方便管理代码到部署的整个生命周期，我们基于Jenkins构建了整个DevOps流水线。
在构建方式上，没有采用传统的每个项目单独构建的形式，而是根据项目类型的不同，通过一个公共项目进行构建。
以Java 类型为例：
项目根据实际情况填写参数就可以了，当然为了简化，也可以直接克隆一份，把参数固化。
质量分析目前是采用的SonarQube，除了对每次的构建进行分析，我们还专门对每次代码提交进行了自动触发质量分析，只要项目提交了代码，GitLab就会通过webhook通知Jenkins，对项目进行代码质量分析，并将分析结果通知给项目开发人员。
截止到目前是已经分析了8108次，质量部门会根据这个分析结果，对项目质量提出一些要求，从一定程度上提高项目代码质量。
最后，看一下我们最新上线的一个智能工厂案例，采用的是3个管理节点，3个存储节点，10个计算节点的配置。
这是节点的情况。
这是其中部分服务的部署情况。
Q&A
Q：
您认为未来工业PaaS云平台的发展前景和发展模式有哪些？A：工业场景本身是千差万别的，石油、金属、制造业等等，都有自己各自的需求，目前来看的话，主要还是要先完成信息化改造，然后才能以此为基础去做后续的比如工艺优化等等。后续应该会公有云、私有云并存，大集团型公司走私有云模式，中小型公司走公有云模式。
Q：
Kubernetes的在线热升级容易做吗，请问是不是踩过很多坑呢？A：目前对于Kubernetes的热升级，主要是大版本变动会带来一些配置上的改动，因为全部容器化，所以升级本身不复杂。
Q：
现在生产服务的规模多大，服务数量，流水线是每个项目类型一个公共构建项目吗？
针对多分支构建如何快速持续集成？
针对服务的特殊化需求比如Pipeline的某个stage要跳过怎么办，每个项目一个标准的Jenkinsfile吗？A：服务数量根据不同的项目规模，各有不同，智能工厂项目本身是一个很庞大的项目，下面会分很多的子项目，目前来看，一般的子项目服务数量是在50个以内。目前我们还没考虑多分支情况，因为项目不像自己运维的产品，不会存在频繁的更新，我们是按版本形式去走，所有的提交最后都要汇总到主干分支后，再打包发到现场。目前还没有跳过stage的需求。
Q：
请问Jenkins webhook那些构建参数如何传入GitLab触发？A：webhook的触发和界面参数会有一些区别，我们在脚本里面做了处理。
Q：
离线部署，是不是通过打出镜像压缩包，然后带着镜像包到现场部署的容器云平台上，上传部署的方式？A：是在家里打出镜像压缩包，然后到现场解压出来，根据镜像类型进行处理，比如一些基础镜像，会直接上传到节点，业务的镜像会在部署完成后上传到Harbor，然后节点从Harbor去拉取。
