共计 3140 个字符，预计需要花费 8 分钟才能阅读完成。
公司简介
某国家级智能网联汽车钻研核心成立于 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 公布！
