ByteDoc 3.0：MongoDB 云原生实践
发布时间：2022-08-05 14:38:42 所属栏目：云计算 来源：互联网
导读：背景 本文分享的是 Bytedoc 3.0 关于集群交付方面的内容以及一些云原生的实践：如何将 Bytedoc 3.0 与云原生的能力结合起来，交付用户一个开箱即用的集群，与软件层的能力相匹配，最大化展示 Bytedoc 3.0 具备的弹性能力。 面临的问题 数据库服务的使用者有
|
背景 本文分享的是 Bytedoc 3.0 关于集群交付方面的内容以及一些云原生的实践：如何将 Bytedoc 3.0 与云原生的能力结合起来，交付用户一个开箱即用的集群，与软件层的能力相匹配，最大化展示 Bytedoc 3.0 具备的“弹性”能力。 面临的问题 数据库服务的使用者有两方：用户(业务)和 DBA(运维)，运维能力不断增强，才能给用户更好的服务体验。 用户需求 运维需求 目标与思路 目标 为了解决上述问题，Bytedoc 3.0 软件层已经实现了相关的能力，我们需要在交付层提供类似的能力，以匹配整体的“弹性”能力： 目标 1：数据库能快速扩展/恢复从库，秒级扩展数据库的读能力。扩容从库实例自动化程度要高，扩容速度尽可能快; 目标 2：计算资源能够按需扩展。对计算密集型业务，能快速扩展计算资源，而且能分配更多的资源供用户使用，匹配实际负载; 目标 3：提升计算/存储资源利用率，降低业务使用成本。 目标 4：更标准的交付能力与更高的交付质量，给用户提供更好的数据库服务。 实现思路 我们通过“Kubernetes 云原生”化来实现我们的目标： Kubernetes 是业界通用的，用于自动部署，扩展和管理容器化应用程序的开源编排系统。简单地说，它能够系统化地打包、运行、管理你的服务，在这里是 Bytedoc 数据库服务。这使得我们能够结合已有的运维经验和业界通用服务交付/管理解决方案，提供更好的、更高质量的数据库服务，以发挥 Bytedoc 3.0 十足的"弹性"能力 在 ByteDoc 1.0 时期，大多数数据库服务实例是直接部署到虚拟机上的，资源的分配受限于虚拟机规格的划分，无法灵活地、按需要分配机器资源，导致大部分的机器资源空闲出来，无法得到有效利用;同时，因为计算与存储的资源绑定，在 1.0 的自研部署平台中，实现容器化部署十分困难，虚拟机部署的方案就一直保留下来。 直到 ByteDoc 3.0 的出现，将数据下沉存储层，交付服务时，更多关注计算层方面的资源分配，使得容器化部署模式可行。结合 Kubernetes 对容器部署与管理的解决方案，我们将容器大部分自动化管理操作交由给 Kubernetes 控制器管理，专注于 ByteDoc 3.0 服务编排过程，如集群部署、从库扩容等，以充分发挥 3.0 的"弹性"能力。 云原生实践 服务云原生化，实际上是一个“迁移”的过程，将原有服务打包、运行、管理能力，以 Kubernetes 提供的解决方案为标准，重现出来。 在 Kubernetes 中，我们把 ByteDoc 3.0 集群定义为一种定制资源(CustomResource)。提供数据库服务，实际上就是创建了一种资源;和 K8s 内置的工作负载资源一样，定制资源也需要一个控制器来进行管理，通常把这类控制器称作 Operator。 所以，ByteDoc 3.0 云原生实践的关键是构建 ByteDoc Operator。 Kubernetes 基本概念 容器化部署 前面说到，Kubernetes 是一个容器编排系统，主要的职责是管理容器生命周期，所以实际的应用程序应该提前打包成一个容器镜像，以便于交付给 K8s 来使用。 Pod https://kubernetes.io/zh/docs/concepts/workloads/pods/ 我们打包好的容器最后会运行在 Pod 中，由 Pod 管理起来。 Pod 是 K8s 中内置的最基本的资源之一，也是最小部署的计算单元，可以类比于一些共享机器资源的容器组。 如果一个 Pod (内的容器)因异常导致退出，通常情况下，这个 Pod 会被删除销毁，高级 workload 会新建一个全新的 Pod 来代替它，而不是“重启”该 Pod。 高级 workload 通常情况下，我们构建的 Operator 不会去直接创建 Pod;而是使用 K8s 提供的高级 workload 资源，他们会帮我们把 Pod 创建出来，并提供一些基本的资源管理能力。 Deployment： 维护一组给定数量的、完全相同的 Pod，通常用于无状态服务。 StatefulSet： 同样维护一组 Pod，特别的是，每个 Pod 都有稳定的网络标示;在此情景下，如果一个 Pod 被销毁重建，在外部使用者看来，该 Pod 是进行“重启”了，所以通常用于有状态的服务。 如何与 K8s 交互 Kubernetes 控制面的核心是 API 服务器。API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。 一般而言，我们与 K8s 交互是通过“声明式”，而非“动作命令式”。 复制 # sample.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx minReadySeconds: 6 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 ByteDoc 3.0 在 Kubernetes 上的架构 (ByteDoc 经典架构，由三部分组成) mongos： 代理层，负责转发、简单处理用户请求; 需要感知 Config Server，从中获取 Shard 的拓扑; config server： 复制集模式，区分主从; 存储集群元信息，包括每个 shard 内实例的地址; shard： 复制集模式，区分主从; server 层，处理用户请求; mongos - deployment，对应无状态的服务 config server/shard - statefulset，对应有状态的服务 对于 mongo 的复制集，复制集成员需要用一个网络标示(host、dns、服务发现、headless service 等)注册进配置中，才能与其他复制集成员进行通信;所以在这里，我们使用 StatefulSet 提供的稳定的网络标示作为成员名称，保证数据库实例(对应的 pod)故障恢复后，以同样的身份加入到复制集中，正常地提供服务。 联邦模式 多机房场景下的架构 实际上，上述 ByteDoc 3.0 集群是在单机房下的架构，在线上生产环境中，还要考虑多机房容灾的场景;在多机房场景下，我们希望一个 3 副本的集群，每个计算实例是分别部署在不同的机房，但是这些副本又是需要在同一个复制集中的，在参考了几种跨 K8s 方案后，我们采取了下面的多机房架构： 有哪些候选的跨 K8s 的方案? 1、社区提供的 Federation V1 方案(deprecated，后续改进为 V2 方案) 主要提供两个主要能力来支持管理多个集群：跨集群同步资源 & 跨集群服务发现 2、云原生 SRE 团队提供的通用 operator 方案 复制 ... spec: charts: - name: nginx chart: charts/nginx values: '"replicaCount": "{{ .replica_count | default 1 }}"' cluster: - placement: - names: - cluster-sample execJobs: - name: ls command: - ls - "-l" mustBefore: - chart.nginx var: replica_count: '2' 定义一系列的 chart、K8s 集群、执行任务、变量 通过通用 operator 在多个 K8s 集群上完成资源部署、任务执行 3、MongoDB 官方提供的跨 K8s 方案 通过 mongodb 额外的 k8s-agent 完成跨 K8s 集群场景下，复制集与集群的构建 代码未开源 为什么选择了现在这种方案? 我们当前的方案实际上和社区的 Federation 方案比较相似，通过以下的能力搭建完整的 ByteDoc 3.0 集群： 资源复制：operator 连接 worker K8s，创建基本相同的资源 服务发现：分具体的网络场景，如果使用 overlay 网络，可以使用社区支持的无头服务(headless service);如果是走 underlay 网络，则需要额外的服务发现能力 组建 ByteDoc 集群：将实例组建为集群的核心逻辑，比较复杂，不太容易通过任务的形式实现 因此，我们选择这种 Meta Operator 的方案，通过 worker K8s 创建资源，后续 Operator 完成集群的搭建工作。 （编辑：我爱制作网_潮州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330565号