上汽集团帆一尚行业务发展部总经理 龚瀚申

在上汽集团帆一尚行业务发展部总经理龚瀚申看来，汽车行业对互联网转型的需求主要集中在两个方面，一方面是汽车行业对于互联网云原生的需求，如车联网共享出行等，这些互联网业务带动了整个汽车行业的转型，而这一类的生态大多源于云的系统架构，属于云原生的系统。另一方面则是来源于公司内部的运营需求，运营方式无法实现对互联网快速变革需求的及时响应，重复的基础建设、复杂的系统架构以及封闭的业务系统，将会造成巨大的资源浪费和高昂的企业运营成本。

当企业将业务部署到云端之后，这样的情况便会得到相应的改善，除了降低整体的IT投资成本之外，基于云计算互联互通的优势，也能增加业务之间的数据交互。“从上汽集团的战略规划层面出发，我们需要开发大量的具有行业特性的产品。”龚瀚申分析道：“在上云的过程当中，云平台不单是资源提供方的角色，最重要的是它将通用技术与通用业务功能产品化。这是上汽云平台长期的一个发展方向。”

帆一尚行云平台的总体框架

在明确上汽云平台未来的发展方向之后，他们制定了一个总体的云平台框架，将主要的任务集中放在两大平台进行处理。其一是基础服务平台，以虚拟化和数据中心作为技术核心，将标准化的硬件以虚拟资源的方式提供给用户，用户在资源池内按需计算。其二则是推出了平台服务，容器加上调度系统将构成平台服务的运行基础，当平台服务往业务层靠拢，将抽象出业务中台，当平台服务往技术层靠拢，将抽象出技术中台。不管是技术中台还是业务中台，运行基础都是由虚拟化和容器来提供的。所以在云数据中心，容器已经显然成为上汽集团帆一尚行的一个核心技术，它不仅是一个轻量级的PaaS，也是IaaS平台更小颗粒的虚拟化，为整个平台提供运行基础。

从时间线上来看，上汽集团在容器技术的探索和实践与容器技术的整体发展息息相关。

帆一尚行容器技术使用历程

2015年，上汽集团帆一尚行的开发团队使用Docker跑了一些简单的网站应用，开发人员在笔记本上运行一些简单的代码，通过容器打包推送到帆一尚行的虚拟环境里面，在秒级的响应时间内便可以启动打包的应用。“我们将Docker和OpenStack进行了对比，也在内部进行了容器是否会取代OpenStack的议题讨论。”龚瀚申回忆：“由于容器成熟度以及用户成熟度的问题，我们认为短期内容器还无法取代OpenStack，但基于这次尝试，我们感受到了容器在资源利用率和环境一致性上的优势。”

2016年，上汽集团帆一尚行在Docker以及编排系统上投入了更多的精力，开发团队调研了市面上Rancher、Mesos+Marathon、Kubernetes以及Docker+Swarm等系统，不同的系统在系统成熟度以及部署难易程度上存在一定的差别，最终选择了Docker+Swarm去搭建企业的集群，并开始了利用小规模集群支撑整体营销活动的实践及推广。

到了2017年，随着Kubernetes的呼声和热度越来越高，产品也日趋成熟。上汽集团帆一尚行开发团队在内部小范围构建了Kubernetes的小型集群，将其应用于整个GPU资源平台的调度。经过这一两年的尝试及探索，上汽集团帆一尚行正式将Kubernetes列为产品线的重要产品，用以支撑整个容器平台的运行。

“在建设Kubernetes平台的初期，我们从多个维度设定了容器平台的目标。”龚瀚申分享道：“从部署的维度出发，它必须支持多跨数据中心的部署，必须支持主流公有云和私有云平台的部署；从资源调度编排的角度出发，它必须支持主流的CPU调度，必须以开放标准的形式提供存储与网络的对接；从租户管理的角度出发，它必须可以提供多租户的资源配额，让租户在自己的配额里面可以调度资源以及镜像仓库；从整体运营管理的角度出发，它必须提供一个统一对接Kubernetes集群管理的平台，必须能对Kubernetes集群进行灵活增减，以及能实现简单的监控功能。”

帆一尚行技术方案选型

通过一系列的探索与实践，上汽集团最终落地了最符合自身需求的容器技术选型：基于物理服务器构建基础设施，利用自研基于Ansible的Kubernetes进行整个集群的自动化部署；通过Rancher来实现平台的统一管控，对接统一认证系统，实现应用部署管理、多租户、配额管理等高级功能；在网络的层面上，选择利用Calico BGP网络+外部L4L/7的负载均衡来实现多种应用的发布形式；存储则是沿用了Swarm里面的Nexenta以及PortWorx来打造分布式存储方案；最后，上汽集团还基于Prometheus进行平台监控和外部统一监控告警。

Kubernetes平台逻辑框架

Kubernetes集群与上汽集团帆一尚行的用户界面是集成的，用户可以通过登录Saicmotor的门户网站直接使用上汽集团帆一尚行的Kubernetes集群，或者是通过上汽集团帆一尚行周边的云平台产品如应用开发日志、日志管理等来进行对Kubernetes集群进行管控。而上汽集团帆一尚行的运维人员则是通过Rancher的管理界面来管理底层的Kubernetes集群。

“关于Kubernetes应该怎样以产品的方式提供给用户，我们也进行了一些场景化的思考。有人会将Kubernetes当作是数据中心的管控系统，有人会将它作为是任务调度的管理系统，还会有人将Kubernetes当作是微服务的一个治理框架，在不同的而场景下，大家对Kubernetes的定义是不一样的。”龚瀚申分析：“这一切就是源于Kubernetes它开放的多维度框架设计理念以及简单易用的产品特性，所以我们将它理解为一个可扩展、可组合的调度系统框架。”

针对Kubernetes的产品特性和用户对Kubernetes的熟悉程度，上汽集团帆一尚行设计了两类产品形态。一类产品形态针对初级用户，将Kubernetes封装起来，以另外一种形式为用户提供服务，用户更多体验到的是以容器技术为主的应用部署和发布能力。另一类则针对高级用户开放，用户可以独享一个Kubernetes集群，并且通过一键部署来快速实现，可以充分体验Kubernetes的特性。

在内部的项目落地之后，上汽集团为了实现对L4自动驾驶产业化软件的开发以及复杂场景下自动驾驶功能的建设需求，他们对容器平台提出了更高的要求。

 “平台必须提供完整的AI软件开发流程管理体系，包括数据管理、模型管理、仿真测试、模型压缩等系统功能，和车端行程从训练到推理的AI软件开发闭环。”龚瀚申将这一目标归结为两大需求，一是AI训练服务，将专注于数据标注、数据存储、CPU训练以及分布式训练；二是AI模型，包含训练服务、托管发布和模型的版本管理。

同时，这一平台将定义为集团层面的公共训练服务平台，不仅服务于上汽集团智能驾驶的部门，还将为集团下属的整车物流零部件等企业提供AI训练服务。那么，对于这一平台来说，任务调度功能以及租户隔离功能都是不可或缺的。

上汽集团帆一尚行开发团队在进行技术选型的时候，发现Kubernetes能完美地实现资源层的调度和服务层的任务调度功能，也能对租户的GPU资源和网络存储资源进行很好的隔离。最终在AI平台应用的层面，上汽集团也选择了Kubernetes进行应用于落地。

AI平台业务架构

那么，整个AI平台是怎么进行业务实现的呢？从横向的角度来看，上汽集团的AI平台客户分为三个层面，一是人力层面，二是算力层面，三是数据层面。数据层面将产生大量的数据，如行车交通标志、雨天产生的大量视频和图像，以及一些信号数据，这些数据将被收集起来，送到算力平台上，最终由上汽集团帆一尚行的人力分工对这些数据进行处理和训练，最终产出一个算法。从纵向的角度来看，平台的人力团队被划分为三类，一是标注团队，主要负责模型服务；二是算法团队，三是运营团队，起到协调的作用。

AI训练平台逻辑框架

当帆一尚行的开发团队和业务进行沟通之后，抽象出了AI平台的系统逻辑框架，第一层为基础层面，由Kubernetes和存储构成；第二层为Service层面，包括需要调度的算法和需要进行的数据处理；还有一个层面就是前台的服务层，包括数据管控的流程、任务发布等。当Kubernetes接到调度之后，将去Service的层面去调度Service模块，然后Kubernetes再把GPU资源、存储资源分配给Service模块，Service模块进行统一的训练和计算，最终把结果返回到前台的用户。

“所有这些调度的服务层的任务全部都是以镜像的形式存储在Kubernetes的镜像仓库里面，Kubernetes在整套系统里面起到的是多任务控制的调度以及资源调度的作用。所以这个核心实际上是有底层的Kubernetes实现的。”龚瀚申补充道：“我们团队会根据算法团队打包他们的算力，把它存储在镜像仓库里面，由他们自主地通过前端的前台来自主地发起任务训练。这就是Kubernetes在上汽集团AI平台的应用。”