共计 3321 个字符，预计需要花费 9 分钟才能阅读完成。
本文首发于 Nebula Graph 公众号：Nebula Operator 开源啦！一文详解这个云上自动化部署集群管理工具
在介绍 Nebula Operator 之前，让咱们先来理解下什么是 Operator。
Operator 是一种封装、部署和治理 Kubernetes 利用的办法，通过扩大 Kubernetes API 的性能，来治理用户创立、配置和治理简单利用的实例。它基于自定义资源 CRD 和控制器概念构建，涵盖了特定畛域或利用的常识，用于实现其所管理软件的整个生命周期的自动化。
在 Kubernetes 中，管制立体的控制器施行管制循环，重复比拟集群的冀望状态和理论状态。如果集群的理论状态与冀望状态不符，控制器将持续协调外部业务逻辑直到利用更新为冀望状态。
Nebula Operator 将 NebulaGraph 的部署治理形象成自定义资源 CRD，通过 StatefulSet、Service、ConfigMap 等多个内置的 API 对象组合在一起，把日常治理保护 Nebula Graph 的流程编写成管制循环，当 CR 实例提交时，Nebula Operator 依照管制流程驱动数据库集群向终态转移。
Nebula Operator 性能介绍
CRD 定义
上面联合部署 nebula 集群的 CR 文件，来理解下 Nebula Operator 的外围性能。
apiVersion: apps.nebula-graph.io/v1alpha1
kind: NebulaCluster
metadata:
name: nebula
namespace: default
spec:
graphd:
resources:
requests:
cpu: "500m"
memory: "500Mi"
replicas: 1
image: vesoft/nebula-graphd
version: v2.0.0
storageClaim:
resources:
requests:
storage: 2Gi
storageClassName: gp2
metad:
resources:
requests:
cpu: "500m"
memory: "500Mi"
replicas: 1
image: vesoft/nebula-metad
version: v2.0.0
storageClaim:
resources:
requests:
storage: 2Gi
storageClassName: gp2
storaged:
resources:
requests:
cpu: "500m"
memory: "500Mi"
replicas: 3
image: vesoft/nebula-storaged
version: v2.0.0
storageClaim:
resources:
requests:
storage: 2Gi
storageClassName: gp2
reference:
name: statefulsets.apps
version: v1
schedulerName: default-scheduler
imagePullPolicy: IfNotPresentspec 里须要重点关注三个形容局部：graphd、metad、storaged，他们别离示意 Graph 服务、Meta 服务、Storage 服务，控制器会在协调循环里顺次查看内置的 API 对象 StatefulSet、Service、ConfigMap 是否就绪，如果某个依赖的 API 对象没有创立胜利或者某个 Nebula Graph 组件服务协调异样，控制器就会完结返回，期待下一次协调，并反复这个过程。
目前 CRD 里提供的配置参数还不够丰盛，只笼罩了最外围的 resource、replicas、image、schedulerName 等运行过程中必不可少的配置参数，将来 Nebula Operator 会依据应用场景进一步丰盛配置参数。
扩缩容
Storage 扩容分为两个阶段，第一个阶段须要期待所有新增扩容的 Pod 状态为 Ready，第二个阶段执行数据 Balance Data 操作，数据 Balance 的工作由 CRD StorageBalancer 定义，这里将控制器正本的扩容流程跟数据 Balance 流程解耦，能够实现数据 Balance 工作的定制化，比方：增加工作执行工夫，在业务流量较低时执行，可无效减小数据迁徙对于线上服务的影响，这也合乎 Nebula Graph 自身的设计理念：没有采纳齐全自动化 Balance 形式，Balance 机会由用户本人管制。
Storage 缩容和扩容是一个相同的过程，缩容前须要平安移除节点，外部对应的就是 BALANCE DATA REMOVE $host_list 指令，期待移除节点工作实现后，再执行 Storage Pod 的缩容操作。
注：下图只做解释阐明，不做实在配置参考，在高可用场景下，须要保障 3 正本实例在线。
调度平衡
在调度局部，Nebula Operator 提供了两种抉择，能够应用默认调度器或者基于 scheduler extender 接口的调度器。
默认调度器的拓扑散布束缚能够管制 Pod 在集群拓扑域内均匀分布，Nebula Operator 提供了默认的节点标签 kubernetes.io/hostname 的均匀分布，将来会反对自定义节点标签配置。这里没有抉择基于亲和性调度策略次要是因为亲和性实质上是管制 Pod 如何被重叠或是打散，PodAffinity 是将多个 Pod 调度到特定的拓扑域，这是重叠调度；PodAntiAffinity 则是保障特定拓扑域内只有一个 Pod，这是打散调度，然而这些调度策略无奈应答尽可能均匀分布的场景，尤其是在分布式应用场景下，须要实现高可用散布在多个拓扑域。
当然，如果你应用的 Kubernetes 版本较低，无奈体验拓扑散布束缚的个性，还有 Nebula-Scheduler 调度器供你抉择。它的外围逻辑就是保障每个组件的 Pod 能够均匀分布在指定拓扑域上。
工作负载控制器
Nebula Operator 打算反对多种工作负载控制器，通过应用 reference 配置项，可自主地抉择应用哪一种工作负载控制器，以后在原生的 StatefulSet 根底上，Nebula Operator 还额定反对社区版 OpenKruise 的 AdvancedStatefulSet。用户可依据本身业务的须要，在 Nebula Operator 中应用如原地降级、指定节点下线等高级个性，当然这也须要在 Operator 外部实现相应的配置，目前只反对原地降级的参数。
reference:
name: statefulsets.apps
version: v1其余性能
其余诸如 WebHook 提供高可用模式下的配置校验，自定义参数配置更新等性能就不额定介绍了，这些个性都是为了让你通过 Nebula Operator 治理 Nebula Graph 集群更加的平安不便，具体细节能够浏览 GitHub 上的文档，这里不过多论述。
FAQ
Nebula Operator 是否能够在 Kubernetes 之外应用？
不能够，Operator 是依靠于 Kubernetes 运行的，它是 Kubernetes API 的扩大，这是 K8s 畛域内的工具。
如何保障降级、扩缩容的稳固可用，失败后是否回退？
倡议提前做好数据备份，免得失败还能回退。Nebula Operator 目前还不反对操作前数据备份，后续会迭代反对上。
是否兼容 NebulaGraph v1.x 集群？
v1.x 不反对外部域名解析，Nebula Operator 须要外部域名解析的这个个性，无奈兼容。
应用本地存储是否保障集群稳固？
目前无奈保障，应用本地存储就意味着 Pod 与特定的节点有绑定关系，Operator 目前不具备应用本地存储节点宕机后故障转移的能力，应用网络存储没有这个问题。
降级性能何时能反对上？
Nebula Operator 须要跟 NebulaGraph 保持一致，待数据库反对滚动降级后，Operator 会同步反对这个性能。
Nebula Operator 现已开源，欢送拜访 GitHub：https://github.com/vesoft-inc/nebula-operator 来尝鲜~
来加入 Nebula Operator 喊你提需要 流动，帮它成长为你想要的样子吧：Nebula Operator 由你话事
