基于 Nebula Operator 的 K8s 自动化部署运维

原创

NebulaGraph

修改于 2020-11-19 11:49:57

8730

修改于 2020-11-19 11:49:57

文章被收录于专栏：NebulaGraph 技术文章

摘要：Nebula Operator 是 Nebula Graph 在 Kubernetes 系统上的自动化部署运维插件。在本文，你将了解到 Nebula Operator 的特性及它的工作原理。

从 Nebula Graph 的架构谈起

Nebula Graph 是一个高性能的分布式开源图数据库，从架构上可以看出，一个完整的 Nebula Graph 集群由三类服务组成，即 Meta Service, Query Service（Computation Layer）和 Storage Service（Storage Layer）。

每类服务都是一个由多副本组件组成的集群，在 Nebula Operator 中，我们分别称这三类组件为: Metad / Graphd / Storaged。

Metad：主要负责提供和存储图数据库的元数据，并承担集群中调度器的角色，指挥存储扩容和数据迁移，leader 变更等运维操作。
Graphd：主要负责处理 Nebula 查询语言语句（nGQL），每个 Graphd 都运行着一个无状态的查询计算引擎，且彼此间无任何通信关系。计算引擎仅从 Metad 集群中读取元信息，并和 Storaged 集群进行交互。同时，它也负责不同客户端的接入和交互。
Storaged：主要负责 Graph 数据存储。图数据被切分成很多的分片 Partition，相同 ID 的 Partition 组成一个 Raft Group，实现多副本一致性。Nebula Graph 默认的存储引擎是 RocksDB 的 Key-Value 存储。

在了解了 Nebula Graph 核心组件的功能后，我们可以得出一些结论：

Nebula Graph 在设计上采用了存储计算分离的架构，组件间分层清晰，职责明确，这意味着各个组件都可以根据自身的业务需求进行独立地弹性扩容、缩容，非常适合部署在 Kubernetes 这类容器编排系统上，充分发挥 Nebula Graph 集群的弹性扩缩能力。
Nebula Graph 是一个较为复杂的分布式系统，它的部署和运维操作需要比较深入的领域知识，这带来了颇高的学习成本和负担。即使是部署运行在 Kubernetes 系统之上，有状态应用的状态管理、异常处理等需求，原生的Kubernetes 控制器也不能很好的满足，导致 Nebula Graph 集群不能发挥出它最大的能力。

因此，为了充分发挥 Nebula Graph 原生具备的弹性扩缩、故障转移等能力，也为了降低对 Nebula Graph 集群的运维管理门槛，我们开发了 Nebula Operator。

Nebula Operator 是 Nebula Graph 在 Kubernetes 系统上的自动化部署运维插件，依托于 Kubernetes 自身优秀的扩展机制，我们把 Nebula Graph 运维领域的知识，以 CRD + Controller 的形式全面注入到 Kubernetes 系统中，让 Nebula Graph 成为真正的云原生图数据库。

为了能够更好的理解 Nebula Operator 的工作原理，让我们先回顾一下什么是 Operator

什么是 Nebula Operator

Operator 并不是什么很新的概念，早在 2017 年，就有 CoreOS 公司推出了 Etcd Operator。Operator 的初衷是为了扩展 Kubernetes 功能，以更好的管理有状态应用，这得益于 Kubernetes 的两大核心概念：声明式 API 和控制循环（Control Loop)。

我们可以用一段伪代码来描述这一过程。

在集群中声明对象X的期望状态并创建X

for {

 实际状态 := 获取集群中对象 X 的实际状态

 期望状态 := 获取集群中对象 X 的期望状态

 if 实际状态 == 期望状态 {

    什么都不做

  } else {

    执行事先规定好的编排动作，将实际状态调协为期望状态

  }

}

在 Kubernetes 系统内，每一种内置资源对象，都运行着一个特定的控制循环，将它的实际状态通过事先规定好的编排动作，逐步调整为最终的期望状态。

对于 Kubernetes 系统内不存在的资源类型，我们可以通过添加自定义 API 对象的方式注册。常见的方法是使用 CustomResourceDefinition（CRD）和 Aggregation ApiServer（AA）。Nebula Operator 就使用 CRD 注册了一个 "Nebula Cluster" 资源，和一个 "Advanced Statefulset" 资源。

在注册了上述自定义资源之后，我们就可以通过编写自定义控制器的方式来感知自定义资源的状态变化，并按照我们编写的策略和逻辑去自动地运维 Nebula Graph，让集群的实际状态朝着期望状态趋近。这也是 Nebula Operator 降低用户运维门槛的核心原理。

apiVersion: nebula.com/v1alpha1

kind: NebulaCluster

metadata:

 name: nebulaclusters

 namespace: default

spec:

 graphd:

 replicas: 1

 baseImage: vesoft/nebula-graphd

 imageVersion: v2-preview-nightly

 service:

 type: NodePort

 externalTrafficPolicy: Cluster

 storageClaim:

 storageClassName: fast-disks

 metad:

 replicas: 3

 baseImage: vesoft/nebula-metad

 imageVersion: v2-preview-nightly

 storageClaim:

 storageClassName: fast-disks

 storaged:

 replicas: 3

 baseImage: vesoft/nebula-storaged

 imageVersion: v2-preview-nightly

 storageClaim:

 storageClassName: fast-disks

 schedulerName: nebula-scheduler

 imagePullPolicy: Always

我们在这里展示了一个简单的 Nebula Cluster 实例，如果你想要扩展 Storaged 的副本数量至 10，你只需要简单修改 .spec.storaged.replicas 参数为 10，剩下的运维操作则由 Nebula Operator 通过控制循环来完成。

至此，想必你已经对 Nebula Graph 和 Operator 有了一个初步的认知，接下来，让我们来列举目前 Nebula Operator 已经具备了哪些能力，让你能更加深刻的体会到使用 Nebula Operator 带来的一些实际好处。

*部署、卸载：我们将一整个 Nebula Graph 集群描述成一个 CRD 注册进 ApiServer 中，用户只需提供对应的 CR 文件，Operator 就能快速拉起或者删除一个对应的 Nebula Graph 集群，简化了用户部署、卸载集群的过程。
扩容、缩容：通过在控制循环中调用 Nebula Graph 原生提供的扩缩容接口，我们为 Nebula Operator 封装实现了扩缩容的逻辑，可以通过 yaml 配置进行简单的扩容，缩容，且保证数据的稳定性。
原地升级：我们在 Kubernetes 原生提供的 StatefulSet 基础上为其扩展了镜像原地替换的能力，它节省了 Pod 调度的耗时，并且在升级时，Pod 的位置、资源都不发生变化，极大提高了升级时集群的稳定性和确定性。
故障迁移：Nebula Operator 会内部调用 Nebula Graph 集群提供的接口，动态的感知服务是否正常运行，一旦发现异常，会自动的去做故障迁移操作，并根据错误类型配有对应的容错机制。
WebHook：一个标准的 Nebula Graph 最少需要三个 Metad 副本，如果用户错误地修改了此参数，可能会导致集群不可用，我们会通过 WebHook 的准入控制来检查一些必要参数是否设置正确，并通过变更控制来强制修改一些错误的声明，使集群始终能够稳定运行。