实录分享 | Alluxio Operator 一体化部署方案

作者：Alluxio

2023-06-25
北京
本文字数：6950 字
阅读完需：约 23 分钟

今天给大家分享的内容是 Alluxio Operator 的一体化部署方案。我会将内容分成 4 个部分来给大家讲解。

首先，介绍 Kubernetes 容器化部署和当前所面临的挑战。

然后，引入 operator 的概念，介绍当前业界关于 Kubernetes 容器化部署问题的主流解决方案。

接着，讲解如何针对应用服务去实现对应的 operator。

最后用 Alluxio 作为实际案例展示 operator 是如何实现的。

一、Kubernetes 容器化部署所面临的挑战

目前 Kubernetes 已经是业界比较主流的容器化部署方案，主要因为它对现在的容器化支持非常好，但是同时它也存在一些问题。

我们详细看一下 Kubernetes 容器化部署的过程，以 Presto 为例，部署 Presto、将 Presto 上云，需要做哪些事情？

第一步：梳理组件上云之后需要部署哪些 Kubernetes 资源。我们把应用打包成容器镜像，传到云仓库里面。

第二步：设计部署组件所需要的 Kubernetes 资源。如上图就展示了 Presto 在 Kubernetes 上的部署架构。因为 Presto 组件包含了 coordinator 和 worker 两个不同的角色，所以我们针对这两个不同角色的配置需要有对应的 ConfigMap 资源，而且对 coordinator 和 worker 分别都需要有 Deployment 支撑部署。此外，为了打通 worker 与 coordinator 的网络通讯，我们还需要一个 Service 资源。有了这样一个部署架构图之后，我们还要去思考到底要按什么样的顺序提交资源。比如对 Presto 来说，我们需要提交 Service、Deployment，还有 ConfigMap，这些资源都是通过 yaml 文件描述的，它们之间有先后顺序，有一定的依赖关系。比如在这个例子里，我们要先提交 ConfigMap，再基于 ConfigMap 创建 Deployment，有了 Deployment 之后，我们再去部署 Service。至此，我们发现需要有先后顺序做部署组件，这样就带来了一些问题：

首先它带来的第一个问题就是所涉及到的 Kubernetes 资源可能有多个，维护起来很不方便。尤其是对于很多大数据存储和计算领域里面的中间件，可能涉及到非常多的依赖，甚至包括一些上游下游的支撑组件。

在 Kubernetes 上要跑起来，需要多个 yaml 文件。比如以 Presto 为例，它需要的 yaml 文件有 5 个，我们如果要去实现 Presto 上云，就要维护多个 yaml 文件，这就导致了第二个问题，当我们需要修改某一个配置的时候，其实我们不仅要修改某一个 yaml 文件，可能还要修改所涉及到的跟它相关联的 yaml 文件。假设我们要修改容器的镜像版本，我们应该只需要修改某一个文件的镜像版本即可，但事实上，由于整个架构里面涉及到多个 yaml 文件、多个 Kubernetes 资源，所以这就导致了至少修改两个文件，修改起来非常复杂。又假设我们要修改服务的端口，从 8080 改成 8081，会导致维护的复杂度变高，要改多个文件。诸如此类的修改操作，就导致增加了运维复杂度。

第三个问题是一个组件其实是由多个资源共同支撑而实现，但是这些资源的状态又是相互独立的。我们无法从更抽象更高维度的层级去监控所有资源的信息。比如刚刚提到的这些 Kubernetes 资源，共同组成了一个集群。但我们无法自动收集集群的使用情况，因为不同资源之间相互独立，而它们各自的日志只局限于自己本身。假设我们想根据集群的情况进行自动扩缩容，这个时候需要手动根据集群的情况去做扩缩容。我们只能知道某一个资源在某个时刻发生了变更，但无法知道集群到底什么时候发生了变更，要获取到这些信息，需要在更抽象的层级下才能实现。再比如，我们无法在集群的层面做自动备份容灾，如果突然遇到了一个需求，要下线一批机器，需要对机器上的数据进行迁移，那么这个时候只能手动做这些事情，通过手动调整 Kubernetes 的配置来实现。一方面需要很大的人力维护成本，另一方面即使能够通过手动实现，也很难跟踪到集群在何时做了哪些变更，只能看 Kubernetes 的内置日志，因此，我们也无法很好地做到弹性扩缩容。

诸如 Presto 这样的计算引擎，白天可能用的人较多，请求量很大，这时候需要的资源就比较多，可以适当地给它扩充一些资源，但是到了晚上，或者是一个业务比较闲置的情况下，其实大部分的资源就可以回收起来，去做一些别的事情。比如留给 spark 或者 Flink 做 ETL ，节省资源减少消耗，也相当于是在省钱。

二、关于 Kubernetes 容器化部署问题的主流解决方案

我们看到了诸多 Kubernetes 容器化部署所遇到的挑战，相应地，业界为了解决这些问题，提出了 Operator 的概念。我们先来回顾一下，Kubernetes 的资源包括哪些东西？我们要把一个应用部署到 Kubernetes 集群里，经常会用到的资源包括：PV、PVC、StatefulSet、CronJob、DaemonSet、 ConfigMap、Secret 等。

这些资源在 Kubernetes 中属于内置资源，也许我们会有疑问，Kubernetes 为什么能够监听到我们提交的这些资源？

上图展示了三个资源文件，分别是 Service、Deployment 和 ConfigMap，其中 Deployment 引用了 ConfigMap 中的属性内容，而 Service 则给 Deployment 提供了一个网络访问的支持。Service、Deployment 和 ConfigMap 这三种资源类型都是 Kubernetes 内置的。

当用户通过 kubectl 创建一个 Deployment 资源时， kubectl 内部会通过 Kubernetes API Service 将请求提交到 Kubernetes 集群。此时，Kubernetes 内置的 Deployment Controller 监听到了用户提交创建 Deployment 资源的请求事件，并负责处理请求。所谓 Controller，可以理解为一个一直挂在集群中运行的守护进程。具体来说，用户提交的请求实际上会插入到一个被 Deployment Controller 监听的队列里，当队列中有新的请求进来时，Deployment Controller 就会负责处理。当 Deployment Controller 从队列中获取到请求事件之后，它会进一步解析资源中的属性，然后对比集群中的资源和用户提交的 Deployment 资源，判断状态、属性是否一致，当出现不一致的时候， Deployment Controller 就会执行一些措施来改变目前的状态，让它能够变成用户所期望的状态。

比如，假设用户提交了一个 Deployment 资源，Deployment Controller 发现当前集群里不存在这样的一个资源，那么它就会创建新的 Deployment，按照声明里的副本数创建相应数量的 POD，并且按照所指定的镜像版本从镜像仓库里拉取镜像。当用户更新了 Deployment 时，在队列里相应地也会出现一个 update 事件。

Deployment Controller 会对比现有 Department 的状态，如果它发现镜像的版本发生了变更，就会把原来的容器删掉，重新拉取新的镜像，用新的镜像创建新的容器。

上述就是内置 Kubernetes 资源 Controller 的原理，Kubernetes 里的每一种资源都有一种对应的 Controller，比如 Deployment 对应有 Deployment Controller，StatefulSet 对应有 StatefulSet Controller。

一般来说，部署一个服务应用会涉及到很多不同的 Kubernetes 内置资源，正如刚才介绍的部署 Presto 的例子，需要将 Kubernetes 提供的这些内置资源组合起来，借助这种组合的方式才能实现部署集群的目的。此时我们不妨可以想一想，是否可以有一个自定义的定制资源来替代那些资源的组合呢？比如假设要部署 Presto，如果存在一个叫做 Presto 的资源，同时让 Kubernetes 具备一个 Presto Controller 来监控 Presto 资源，并且自动创建 ConfigMap、Deployment 和 Service，这样就省去手动创建、校验等步骤。此外，当我们修改某一个配置时，也不需要同时修改相关的资源。

Kubernetes 为我们提供了 customer resource 定制资源。customer resource 允许我们创建一个自定义的资源，并且可以定义资源里面包含哪些属性（比如 image 属性）。单纯定义 customer resource 仍然是不够的，因为当我们将定义好的 customer resource commit 到 Kubernetes 之后，此时 Kubernetes 并不知道该如何去处理，它只能校验 customer resource 的定义是否合法。它并不知道如何根据 customer resource 的属性去创建 deployment ConfigMap 等内置资源。因此，我们仍然需要去实现这样一个自动化程序（即定制资源的 controller）。在此基础上，Operator 的概念就是一个定制资源加上相对应定制资源的 controller。

刚才我们以 Deployment 为例解释了 Kubernetes 的 controller，介绍了它是如何和用户提交的 deployment 资源产生作用进而完成 Kubernetes Deployment 部署的。

同样地，如果我们要定义一个名为 Presto 的 customer resource，首先需要提交一个 CRD 来定义这个名为 Presto 的 customer resource 包含哪些属性，CRD 也就是 custom resource 的 definition，它用于告诉 Kubernetes customer resource 里有一个名为 Presto 的资源类型，同时定义了这个 Presto 资源类型里面有哪些属性。提交了 CRD 之后， Kubernetes 便可以识别 Presto 这种 customer resource。此时如果用户提交了一个 Presto customer resource 到 Kubernetes，我们还需要一个类似于 deployment controller 进程的自定义 controller，以同样的方式发现并处理 customer resource。

自定义的 controller 会获取到资源的描述，当它发现有人提交了一个名为 Presto 的资源，它需要按照一定的顺序创建对应的这些 kubernetes 资源：

1、根据 Presto 资源中定义的属性，先去创建一个 ConfigMap 来描述 JVM 配置；

2、创建一个 deployment，包含 Presto 具体的镜像版本；

3、创建一个 service，连通 Presto coordinator 和 Presto worker。

上述的 3 个步骤需要在 controller 进程里实现。因此，自定义的 controller 其实跟内置的 Kubernetes controller 原理一样。只不过自定义的 controller 需要我们自己去实现自己的业务逻辑。当我们创建了一个 Presto 资源后，自定义的 controller 仍然要监控资源的状态，如果资源的状态被更新了（比如 Presto 的镜像被更新了），那么它也需要根据更新之后的状态和当前状态进行对比，之后 controller 要去做的事情就是自动更新它所创建的相关资源，而我们则无须关心要更新哪些内置的 deployment 和 service。至此，我们就理解了实际上 Operator 通过一套解决方案自动化地减少了我们手工维护资源的步骤。

对于 Operator 来说，它的职责是帮我们减少人工的维护成本。以刚才的 Presto 部署为例，如果我们实现了一个 Presto controller，这个 controller 实际上是一个进程，我们可以把它放在 Kubernetes 集群上的一个 pod 里运行。当它发现有一个 Presto 的 customer resource 提交到 Kubernetes 集群时，它就应该要按顺序地创建对应的内置资源。原来这个创建的步骤是由人工创建的，现在变成由 Presto controller 负责创建。它会先创建 config map，再创建 deployment，再创建 service。

我们可以看一下 Operator 的能力分级。首先，假设我们抛开 Operator，回到最原始的 Kubernetes 部署方式，则所有的这些资源都需要我们自己去创建和部署，并且按顺序手工提交。所以如果有一个进程能够帮助我们按照顺序创建这些资源，省去人工创建的步骤，那么这样就达到了 Level 1。相当于所有步骤都已经被编排好，不再需要人工维护。

在此基础上，当我们修改了 customer resource 中的某些属性，Operator 也应该负责更新相关的资源。比如如果镜像的版本发生了变更，此时理所当然地 Operator 也能帮我们同时去修改那些相关的资源，这样一来，我们也不需要维护里面这些资源之间的关系了。如果能做到这一点，就达到了 Level 2。

更进一步地，Operator 作为整个应用组件之上更抽象的进程，其实它还可以帮我们做一些应用集群之外的事情（比如存储的备份、容灾、自动迁移等）。如果具备这样的能力，我们就可以说 Operator 达到了 Level 3。

再有，我们还可以在此之上收集一些关于应用组件或者集群的宏观信息，比如什么时候发生了扩缩容、什么时候做了配置变更等，再比如如果它进行了滚动升级，那我们可以收集到有关 CPU 和内存的使用情况，知道什么时候 CPU 的使用率高、内存资源使用得多，什么时候使用得少。这些信息在后期可以被进一步用来做优化，比如可以对资源进行调优，可以对整个集群的指标进行收集，甚至实现水位告警，发送一条短信或者是打电话或者用邮件来通知用户，此时的 Operator 达到了 Level 4。

最后，假设在集群部署的应用组件能够在 Operator 基础上做到自动扩缩容，我们就可以说它达到了 Level 5。比如，基于前面 Level 4 所收集的指标进行分析后，发现应用在白天的请求较多，而晚上较少，则 Operator 可以自动根据请求的数目去做扩缩容，自动地去修改 pod 的副本数。在这样的情况下，Operator 实现了参数的自动调优。

上述的这 5 个 Level 的分级标准实际上来自于 Operator SDK 的官网。

接下来我们就以 Alluxio 为例阐述如何实现 Alluxio Operator。我们首先要考虑的是，将 Alluxio 部署到 Kubernetes 需要哪些类型的资源做支撑。

三、如何针对应用服务实现对应的 Operator

一个 Alluxio 集群所需要的资源很多，其中还包括存储和网络相关的资源。我们第一步先设计出如图所示的架构图。如图所示，部署 Alluxio 所需的资源可以分成 3 层：

1）第一层是配置和存储相关的资源。我们需要一些 config map 专门配置 Alluxio 的基本配置信息，比如 jvm 配置、pv 存储配置。另外，由于 Alluxio 集群需要涉及到存储，所以还需要 PVC 资源。

2）第二层是 workload。目前业界大部分的大数据组件都采用了主从架构的设计，Alluxio 也一样，它存在 master 和 worker 两种角色，针对 master 和 worker 的部署，我们分别使用 DaemonSet 和 StatefulSet，而针对 logserver（用于日志的收集）的部署，则使用 deployment。

3）第三层是 service。为了让所有节点之间可以网络互通，还要部署 service。

第二步是梳理出具体要创建哪些资源，以及每一种资源包含哪些属性。如图所示给出了所有部署 Alluxio 所需资源的 YAML 文件。

无论我们是否采用 Operator 的部署方案，都需要梳理出要创建哪些资源（对应如图所示的 YAML 文件）。Operator 的作用是在此基础上帮助我们实现自动化部署，免除了手工按顺序提交这些 YAML 文件的操作。为了实现自己的 Operator，要先定义 customer resource，将涉及到的资源属性抽象出来，如图所示，在 Alluxio 的 customer resource 里把一些比较关键的属性抽象出来，比如 master 和 worker 的配置信息。

由于不同资源之间存在着先后依赖关系，所以我们需要按照一定顺序逐一创建这些资源。首先要部署的是 ConfigMap 和存储相关的资源，第二步才去部署 workerload，第三步部署 services。因为显然我们需要先创建出 deployment，才可能把 service 部署起来。即使我们采用手工部署的方式，也要遵循这样的顺序，只不过我们现在先把这个顺序梳理出来，以便在实现 Operator 的时候，通过程序来自动按照这个顺序创建资源。

实现 Operator 的逻辑其实就是通过 Operator 调用 kubernetes API 提供的接口，按照顺序部署和更新资源。Operator SDK 是当前比较流行的一个实现 Operator 的框架（https://sdk.operatorframework.io），它主体通过 golang 实现，框架内也提供了一些实用的例子。另一方面，目前在社区上也有相应的 Operator 仓库(https://operatorhub.io)，里面有相当丰富的各个组件的 Operator 实现。Operator 这一概念被提出之后，业界也陆陆续续地针对主流大数据组件实现了一些社区版的 Operator，提供了一些相对方便的容器化部署解决方案。