EMQX Operator 如何快速创建弹性伸缩的 MQTT 集群

引言：拥抱云原生的 EMQX 5.0

云原生理念逐渐深入到各企业关键业务的应用开发中。对于一个云原生应用来说，水平扩展和弹性集群是其应具备的重要特性。

作为积极拥抱云原生的大规模分布式开源物联网 MQTT 消息服务器，EMQX 最新发布的 5.0 版本采用了新的后端存储架构 Mria 数据库，并重构了数据复制逻辑，增加了 Replicant 节点角色，使用户可以摆脱有状态节点的限制，对 EMQX 集群进行更加弹性的水平扩展，打造更加符合云原生理念的物联网应用。

详情请查看：《Mria + RLOG 新架构下的 EMQX 5.0 如何实现 1 亿 MQTT 连接》

用户可以通过 EMQ 发布的管理工具 EMQX Kubernetes Operator，利用 EMQX 5.0 的 Replicant 节点特性，在 Kubernetes 上通过 Deployment 资源实现无状态节点的部署，快速创建并管理可以承载大规模 MQTT 连接和消息吞吐的 EMQX 集群。

本文将通过对 EMQX Kubernetes Operator 核心特性及应用实操的详细讲解，帮助读者进一步掌握如何快速创建部署及自动化管理可弹性伸缩的 EMQX 集群，充分利用 EMQX 5.0 对云原生的支持特性，拥抱云原生。

什么是 EMQX Kubernetes Operator

相信大家对于 Kubernetes（K8s）已并不陌生。它是一个用于自动化部署、扩展和管理容器化应用程序的广泛使用的开源平台。

在 Kubernetes 上，Operator 是对 Kubernetes API 的软件扩展，它使用自定义资源定义（CRD）来提供一个特定于应用程序的 API。Operator 遵循基本的 Kubernetes 原则，如使用 Controllers（ Controller loops ）来调节系统的状态。

Operator 模式结合了自定义资源（CRD）和自定义控制器，将应用程序的领域知识编码为 Kubernetes API 的扩展，可以自动完成常见的协调任务。

EMQX Kubernetes Operator 则是一个特定于 EMQX 的控制器，它允许 DevOps 在 Kubernetes 中管理 EMQX 集群部署的生命周期。EMQX Kubernetes Operator 作为 Kubernetes 上的自定义控制器运行，并与 Kubernetes API 服务器（kube-apiserver）进行通信，将高层描述转换为正常的 Kubernetes 资源，以保持所需的应用程序状态。

简单来讲，EMQX Kubernetes Operator 可以帮助用户在 Kubernetes 环境上快速创建和管理 EMQX 集群，不仅极大简化部署和管理流程，也降低了管理和配置的专业技能要求。

EMQX 历经多年迭代，我们也积累了丰富的 EMQX 部署、调优和运维的经验。EMQX Kubernetes Operator 便是我们将这些经验转换为代码的一种成果体现。它使部署和管理工作变成一种低成本、标准化、可重复性的能力，帮助用户高效实现集群扩容、无缝升级、故障处理和统一监控。

EMQX Kubernetes Operator VS EMQX Helm Chart

对大多数人来说，手工编写 YAML 文件并不有趣，而且每次需要在 Kubernetes 集群中部署应用或修改配置设置时都要手工编写自定义 YAML，这是一项复杂而且容易出错的工作。

Kubernetes 中的 Helm Chart 和 Operator 则解决了这一难题。这两种用于自动化任务的便捷工具为管理员提供了一种简单的方法，将应用程序或配置部署到 Kubernetes 集群中。这样一来，他们就可以更好地利用 Kubernetes。不过，尽管它们做类似的事情，并不意味着它们是完全可以互换的。

除了 Operator，EMQX 在 Kubernetes 上也提供了 Helm Chart 部署方式，用户可以根据自己的需求选择更合适的部署方式：

• EMQX Helm Chart

  Helm 是 Kubernetes 的包管理系统。使用称为 Helm Chart 的打包格式，某人可以将应用程序（例如 Apache HTTP）打包成任何其他人都可以通过几条命令部署到 Kubernetes 集群上的格式，同时只需很少或无需手动更改 YAML 文件。

  如果您熟悉 Linux 环境中的包管理，