传统车联网的消息处理框架在构建底层资源和运行平台端的整体框架时，往往采用本地数据中心虚拟机/物理机或云服务商虚拟机进行部署。此种模式在联网车辆快速增多、车端上传数据愈加复杂的场景下，通常会面临如下的痛点和挑战：
CNCF（CloudNativeComputingFoundation）旗下项目中以容器编排系统Kubernetes最为核心和基础。Kubernetes通过将应用程序的容器组合成逻辑单元，以便于管理与服务发现，其为开源系统，可以自由地部署在企业内部、私有云、混合云或公有云，方便用户做出自由选择。
越来越多的主机厂在业务平台的生产交付场景中，采用云原生技术打造以下能力，助力智能网联汽车的应用演进和发展。
早期EMQ产品云原生部署采用的是Helm部署方式，Operator模式的出现为实现自定义资源提供了标准的解决方案，解决了通用Kubernetes基础模型元素无法支撑不同业务领域下复杂自动化场景的痛点，为实现更加简单、高效的EMQX部署提供了全新的方式。
Operator的管理不仅限于Pod，也可以是多个资源（比如SVC域名等）。从这个角度上来说，Operator跟Helm一样，也是具有编排能力的。从编排角度来看，Helm与Operator有非常多的共性，很难对两者的作用进行区分。Helm也可以完成分布式系统的部署。
那么Operator跟Helm又有什么样的区别呢？
Operator使用自定义资源（CR）管理应用及其组件的自定义Kubernetes控制器，自定义资源Kubernetes中API扩展，自定义资源配置CRD会明确CR并列出Operator用户可用的所有配置，Operator监视CR类型并且采取特定于应用的操作，确保当前状态与该资源的理想状态相符。
Operator中主要有以下几种对象：
EMQXOperator是一个用来帮助用户在Kubernetes的环境上快速创建和管理EMQX集群的工具。它可以大大简化部署和管理EMQX集群的流程，将其变成一种低成本的、标准化的、可重复性的能力。
作为车联网的核心底层支撑组件，EMQX可以通过KubernetesOperator进行部署、管理和运维。通过基于云原生的消息处理平台，为车联网场景中的客户开发和运维部署带来了诸多好处：
随着云原生理念在各行业的深入，我们相信云原生也将为车联网领域的平台构建与应用开发模式注入新的动力。未来EMQ将围绕对EMQX新版本特性的支持，不断完善迭代EMQXOperator，致力于在云原生模式下提供更加丰富可靠的数据基础设施能力，服务于车联网行业。