做海报找素材的网站,网站优化 检测响应速度,中堂仿做网站,wordpress文章修改失败公司简介
某国家级智能网联汽车研究中心成立于 2018 年#xff0c;是担当产业发展咨询与建议、共性技术研发中心、创新成果转化的国家级创新平台#xff0c;旨在提高我国在智能网联汽车及相关产业在全球价值链中的地位。
目前着力建设基于大数据与云计算的智能汽车云端运营…公司简介
某国家级智能网联汽车研究中心成立于 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.70kp-master01kube-apiserverkube-Schedulerkube-controller-managerEtcd192.168.16.80kp-master02api-serverSchedulercontroller-managerEtcd192.168.16.100kp-node01Kubeletkube-proxyDocker192.168.16.110kp-node02Kubeletkube-proxyDocker192.168.16.120kp-node03Kubeletkube-proxyDocker192.168.16.140kp-node05Kubeletkube-proxyDocker
具体部署架构图如下图所示 线上环境参考 有状态服务主要是一些基础设施服务比如 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 发布
