关于nebula:基于-Nebula-Operator-的-K8s-自动化部署运维

5次阅读

共计 3348 个字符，预计需要花费 9 分钟才能阅读完成。

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

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

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 的准入管制来查看一些必要参数是否设置正确，并通过变更管制来强制批改一些谬误的申明，使集群始终可能稳固运行。