拥抱云原生的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环境中的包管理，Helm图表应该很容易理解。它们类似于Debian或RPM软件包，而Helm本身类似于apt或dnf。就像你可以在Ubuntu上apt-get install[some package]一样，你可以在Kubernetes上helm install[some package]来让应用程序快速启动并运行。

EMQX从4.0版本开始就提供了EMQX Helm Chart，通过EMQX Helm Chart，用户可以快速在Kubernetes上部署一套EMQX集群，并完成初始化操作。Helm Chart的使用足够简单，适合第一次接触EMQX的用户部署和尝鲜。

不过，Helm Chart虽然容易上手，但是它只能提供最基本的部署能力。对于EMQX这种有状态集群的运维，Kubernetes Operator是个更好的选择。

EMQX Kubernetes Operator

如上文所述，通过Kubernetes自定义资源（CRD），用户可以使用声明式API描述EMQX集群，EMQX Kubernetes Operator会不停调度Kubernetes的资源，使EMQX集群最终与用户所声明的保持一致。其中大量的运维和更新操作是由EMQX Kubernetes Operator自动完成的，用户并不需要关心。

EMQX Kubernetes Operator可以让我们更灵活地管理和运维EMQX集群，摆脱掉复杂而且容易出错的配置修改工作，从而节约大量成本。

EMQX Helm Chart与EMQX Kubernetes Operator并不是互相竞争，而是互补的关系。EMQX同时提供这两种部署方式，就是为了让用户可以在不同的场景下选择最适合自己的那一种。

随EMQX 5.0一同升级的EMQX Kubernetes Operator

随着EMQX 5.0在全新HOCON格式配置、Replicant角色节点等方面的更新，我们也为用户在Kubernetes的复杂环境中轻松部署和运维EMQX提供了捷径——即将发布的EMQX Kubernetes Operator 2.0可以完美支持EMQX 5.0的部署管理，在集群策略、配置格式等方面进行了优化升级：

全新的集群策略

EMQX Kubernetes Operator2.0依然使用了Statefulset资源部署EMQX Core节点，这与之前的特性是保持一致的。用户依然可以通过StoreClass等Kubernetes资源持久化EMQX的业务数据，并保证节点的有序性。

与之前有所不同的是，EMQX Kubernetes Operator 2.0利用了Deployment资源来部署EMQX Replicant节点。相比于Core节点，Replicant节点彼此独立，只向Core节点发起请求并组成集群，Replicant节点没有绑定任何持久化的资源，这意味着他们可以随时被销毁和重建。用户可以通过修改EMQX自定义资源快速的伸缩Replicant节点的数量，更灵活地处理自己的业务。

EMQX Kubernetes Operator 2.0会将所有的管理请求（如Dashboard、API）路由到Core节点，同时将所有的业务请求路由到Replicant节点，提高集群的稳定性。

全新的配置格式

在之前的版本中，EMQX Kubernetes Operator是通过环境变量将配置传递给EMQX的，这意味着如果修改配置就会导致Pod的重启，而且需要用户熟练掌握EMQX的配置与环境变量的转换规则，并不十分友好。

EMQX Kubernetes Operator 2.0将利用EMQX全新的HOCON配置和Dashboard的热配置功能，允许用户将原生的EMQX配置写入EMQX自定义资源中，并鼓励用户在EMQX运行时通过EMQX Dashboard的热配置功能来修改EMQX的配置。这些配置都会在整个集群中生效，并且会在新的节点加入集群时将配置同步过去，保证所有节点的一致性。

全新的升级管理

在EMQX 5.0中，因为引入了不同的集群角色，所以集群升级/降级变得更加复杂。用户需要先升级EMQX Core节点，等待所有的Core节点升级完毕并且恢复集群后，再升级Replicant节点。

为了简化这一流程，EMQX Kubernetes Operator 2.0提供了升级管理的能力，当用户想升级/降级EMQX时，只需要直接修改EMQX自定义资源中的Image，EMQX Kubernetes Operator就会自动完成所有的工作。

使用 EMQX Kubernetes Operator快速部署EMQX 5.0

通过EMQX Kubernetes Operator，只需要简单的数行YAML就可以部署一个EMQX集群。

$ cat << "EOF" | kubectl apply -f -                
  apiVersion: apps.emqx.io/v2alpha1
  kind: EMQX
  metadata:
    name: emqx 
  spec:                      
    emqxTemplate:   
      image: emqx/emqx:5.0.6
EOF
emqx.apps.emqx.io/emqx applied

EMQX Kubernetes Operator默认部署3个Core节点以及3个Replicant节点，用户可以通过修改EMQX自定义资源来伸缩节点的数量。

$ kubectl get pods 
NAME                              READY   STATUS    RESTARTS        AGE
emqx-core-0                       1/1     Running   0               75s
emqx-core-1                       1/1     Running   0               75s
emqx-core-2                       1/1     Running   0               75s
emqx-replicant-6c8b4fccfb-bkk4s   1/1     Running   0               75s
emqx-replicant-6c8b4fccfb-kmg9j   1/1     Running   0               75s
emqx-replicant-6c8b4fccfb-zc929   1/1     Running   0               75s

$ kubectl get emqx emqx -o json | jq ".status.emqxNodes"
[
  {
    "node": "emqx@172.17.0.11",
    "node_status": "running",
    "otp_release": "24.2.1-1/12.2.1",
    "role": "replicant",
    "version": "5.0.6"
  },
  {
    "node": "emqx@172.17.0.12",
    "node_status": "running",
    "otp_release": "24.2.1-1/12.2.1",
    "role": "replicant",
    "version": "5.0.6"
  },
  {
    "node": "emqx@172.17.0.13",
    "node_status": "running",
    "otp_release": "24.2.1-1/12.2.1",
    "role": "replicant",
    "version": "5.0.6"
  },
  {
    "node": "emqx@emqx-core-0.emqx-headless.default.svc.cluster.local",
    "node_status": "running",
    "otp_release": "24.2.1-1/12.2.1",
    "role": "core",
    "version": "5.0.6"
  },
  {
    "node": "emqx@emqx-core-1.emqx-headless.default.svc.cluster.local",
    "node_status": "running",
    "otp_release": "24.2.1-1/12.2.1",
    "role": "core",
    "version": "5.0.6"
  },
  {
    "node": "emqx@emqx-core-2.emqx-headless.default.svc.cluster.local",
    "node_status": "running",
    "otp_release": "24.2.1-1/12.2.1",
    "role": "core",
    "version": "5.0.6"
  }
]

结语

除了更强大的水平扩展能力，EMQX 5.0还通过全新改版的Dashboard提供了更清晰全面的数据监控与管理能力，提升了可观测性。此外，对MQTT over QUIC支持的实现，将使得基于QUIC协议的MQTT连接在Pod被调度时可以做到无感知切换到另一个Pod上，从而进一步提高集群的可用性。这些都将使用户可以借助EMQX 5.0构建更加云原生的应用。

EMQX Kubernetes Operator则为用户创建和管理EMQX集群提供了更加便捷的途径，帮助用户更轻松地体验到EMQX 5.0的云原生特性。而EMQ将持续在云原生方向发力，将EMQX进化为一个弹性的、无状态的MQTT Broker，同时配合eKuiper、Neuron等边缘计算产品，进一步探索分布式云原生的落地。