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

? ? ? ? ? ? ? ? 基于 Nebula Operator 的 K8s 自动化部署运维 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Nebula Operator 摘要：Nebula Operator 是 Nebula Graph 在 Kubernetes 系统上的自动化部署运维插件。在本文，你将了解到 Nebula Operator 的特性及它的工作原理。 从 Nebula Graph 的架构谈起 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 ApiServe