公司简介
某国家级智能网联汽车研究中心成立于 2018 年，是担当产业发展咨询与建议、共性技术研发中心、创新成果转化的国家级创新平台，旨在提高我国在智能网联汽车及相关产业在全球价值链中的地位。
目前着力建设基于大数据与云计算的智能汽车云端运营控制中心平台。推进云端运营控制中心建设的过程中，运控中心平台的集成、部署、运维方案经历了 3 代的升级迭代过程。
第一代部署方案是直接将平台的前后端各个模块手动部署在自有物理机中，并将物理机托管在 ICT 的机房中。
第二代方案是将物理机集群用 Vmware ESXi 做了虚拟化，平台前后端各模块部署在虚拟机，提升了资源利用率，降低了资源使用量。
第三代，目前以容器化的方式部署在公有云的 KubeSphere 集群中。购买公有云的服务器资源，使用 KubeKey 安装 KubeSphere 集群，应用级服务采用 DevOps 流水线一键以容器化方式发布到 KubeSphere 集群中，真正实现了持续集成持续发布。应用研发工程师只需要在自己本地实现 feature 或者 fix bug，然后 commit 代码到 GitLab，之后通过 KubeSphere 的 DevOps 流水线一键发布到测试环境或者生产环境。通过使用 KubeSphere 以容器化的方式部署服务，减轻了各位研发工程师的发布工作负担，释放了研发资源。
目前团队组成：1 名架构师负责架构设计、项目管理等全局工作，4 名研发工程师负责研发工作，1 名 DevOps 工程师负责 DevOps 建设和运维工作，这样的一个小团队就可以高效顺利完成大系统的建设工作。
背景介绍
云计算的发展已经逐渐成熟，基于云计算的大数据、人工智能行业发展的越来越成熟，汽车领域与云计算、大数据、人工智能的融合创新发展势不可挡，自动驾驶已经在全球范围内陆续落地。我国汽车科学家基于我国国情和汽车行业发展趋势，提出了自动驾驶汽车的中国方案，也即车路协同方案，以弥补国际上单车智能方案的不足。
在这种行业发展背景下，推进建设车路协同的自动驾驶云端运营控制中心是亟待突破的行业共性关键技术。
在建设自动驾驶云端运营控制中心的过程中，面临许多的实际困难，比如软硬件资源比较紧张，研发人员非常少，建设任务特别繁重，运控中心平台对车辆侧、道路侧物理基础设施的依赖比较种等方面的因素，为了提高有限的存储、计算、网络等硬件资源的利用率和减轻有限研发人员工作负担、高质高效完成运控中心平台的建设任务，建设团队的集成和部署经历了物理机部署、虚拟机部署直到当前的基于 KubeSphere 的容器化部署方案的迭代和升级过程。
选型说明
在研究上云过程中，想过直接购买阿里云的 K8s 集群，但是由于公司本身有一些物理服务器要利用起来，所以就继续调研，最终选择 KubeSphere 作为容器化的解决方案。
我们选择 KubeSphere 的原因有以下几点：
- 得益于 KubeKey 这个安装工具，安装起来更加方便，比以前单纯安装 K8s 要简便、容易的多。
- KubeSphere 相当于给 K8s 做了图形界面，从 web 界面打开查看集群状态，对集群进行运维非常方便，比在命令行下敲命令简单明了的多。
- KubeSphere 支持流水线功能，在不安装额外的软件的情况下就可以实现持续发布功能，持续发布和 K8s 结合在一起，工作起来减轻很多繁琐的操作。
实践过程
由于使用 KubeSphere 和 K8s 以容器化方式部署应用对项目组成员来说都是第一次，无论是比较资深的专家架构师，还是各位研发和运维人员来说，都是在做了基本调研和学习后首次使用，所以，我们的应用容器化之路是学习中使用、使用中提高的一个过程。
为了保障最后生产环境的服务容器化后能更加稳定可控，所以我们采取了 2 步走的战略：
- 第一步，私有云测试环境部署运行以积累经验。先在测试环境搭建 Harbor、KubeSphere、K8s、Docker，建设测试环境的发布流水线将测试环境的各个服务以容器化的方式部署，让前后端的六十多个服务在测试环境先以容器化的方式稳定运行，这样通过测试环境的运行积累经验，等测试环境的容器云运行比较稳定，各种坑都趟过以后，再开始做生产环境的容器化。
- 第二步，私有云生产环境服务部署。首先在物理机上部署了所有服务，让物理机上的运控中心平台稳定运行，以便领导随时检查线上平台运行情况，其次，再做了一份 KubeSphere、K8s、Docker，以容器化方式部署运控中心平台。这样双份的生产环境运控中心平台，当生产环境容器化的运控中心平台运行稳定以后，再将运控平台对外的域名绑定到容器化的运控中心平台上，逐步停用物理机中部署的运控中心平台。
基础设施与部署架构
测试环境和生产环境的 KubeSphere 部署架构基本是一样的。
集群规划：
| 节点 IP | 节点角色 | 组件 |
|---|---|---|
| 192.168.16.70 | kp-master01 | kube-apiserver kube-Scheduler kube-controller-manager Etcd |
| 192.168.16.80 | kp-master02 | api-server Scheduler controller-manager Etcd |
| 192.168.16.100 | kp-node01 | Kubelet kube-proxy Docker |
| 192.168.16.110 | kp-node02 | Kubelet kube-proxy Docker |
| 192.168.16.120 | kp-node03 | Kubelet kube-proxy Docker |
| 192.168.16.140 | kp-node05 | Kubelet kube-proxy Docker |
具体部署架构图如下图所示：
线上环境参考：
- 有状态服务主要是一些基础设施服务，比如 MySQL、Redis、ClickHouse 等这种，对于这些有状态服务还是采用虚拟机部署。
- 无状态服务在 KubeSphere 中的服务如下图所示，包括应用层的前端模块、后端模块，都是采用容器化部署的方式部署。
存储与网络
运控中心平台的一些常规的业务数据采用 MySQL 存储，为了做数据的聚合 OLAP 分析采用 ClickHouse 存储分析性的历史数据，采用 Hadoop 和 Flink 对数据仓库中的数据做分布式的分析处理。采用 ELK 采集了容器集群中的服务日志。
DevOps 方案
测试环境和生产环境都在私有云中搭建，两套环境基本是完全一致。
项目代码统一使用 GitLab 进行配置管理，Docker 镜像采用 Harbor 进行存储，KubeSphere 中建立 DevOps 项目，在 DevOps 项目中为每一个模块建立发布流水线。流水线中的每一个环境都由一台发布服务器上的 shell 脚本具体执行。
使用效果
通过使用 KubeSphere 明显地减轻了工程师们的发布部署工作负担，提升了人员生产力和研发效能。研发工程师只需要在本地实现 feature 或者修复 bug，之后 commit 代码到 GitLab，然后在 KubeSphere 的 DevOps 流水线上点击运行，发布到测试环境或者生产环境的部署工作就彻底完成了，非常轻松简单。
通过使用 KubeSphere 以容器化的方式部署服务，最明显的收益如下：
- 研发工程师在软件的部署上唯一需要做就是登陆 KubeSphere，点击运行流水线，极大地减轻了部署工作量，再也不用记忆各种奇怪的命令，省心省力。
- 使用 KubeSphere 和 K8s 的进行应用容器化部署后，优化了硬件的资源利用率，降低了成本。
未来规划
通过 KubeSphere 的应用实践，发现 K8s 确实解决分布式微服务系统的很多问题，比如负载均衡、自动扩展等，DevOps 流水线功能尤其实用。
在未来，我们计划进一步改进运控中心平台的容器化，将有状态服务也尽量容器化，并将自动化测试加入到发布流水线中。
本文由博客一文多发平台 OpenWrite 发布！
