写点什么

TiDB 上云之 TiDB Operator

  • 2022-11-04
    北京
  • 本文字数:2513 字

    阅读完需:约 8 分钟

作者: 代晓磊 _Mars 原文来源:https://tidb.net/blog/c0460a23


如何在自家私有云或者共有云上部署 TiDB 集群?大家要知道,对于“云原生分布式数据库 TiDB”这个 PingCAP 推广词来讲,TiDB 在设计之初就考虑了 Kubernetes 的结合,怎么能让 TiDB 跑在云上呢?本文就介绍下 TiDB 上云的工具 TiDB Operator。

Kubernetes 简介

在聊 TiDB Operator 之前先聊聊 Kubernetes,下面的解释来自维基百科。


Kubernetes(常简称为K8s)是用于自动部署、扩展和管理“容器化(containerized)应用程序”的开源系统。该系统由Google设计并捐赠给Cloud Native Computing Foundation(CNCF)来使用。它旨在提供“跨主机集群的自动部署、扩展以及运行应用程序容器的平台”。它支持一系列容器工具,包括Docker等。
复制代码


来看下 Kubernetes 的架构



Kubernetes 从角色来讲分为 k8s master 节点和 node 节点。 先看上图中绿色的 master 部分,master 节点一般要求 3 个以上 (保障高可用),主要由以下几个核心组件组成:


  • kube-apiserver:提供了资源操作的唯一入口,并提供认证、授权、访问控制、API 注册和发现等机制;

  • kube-controller-manager:负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;

  • kube-scheduler:负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上;

  • etcd:保存了整个集群状态等元信息;


另外看下各个 k8s 集群的 node 节点(上图中蓝色部分)


  • kubelet: 负责维持容器的生命周期,同时也负责 Volume(CVI)和网络(CNI)的管理;

  • cAdvisor: 负责单节点内部的容器和节点资源使用统计,内置在 Kubelet 内部,并通过 Kubelet /metrics/cadvisor 对外提供 API;

  • kube-proxy: 负责为 Service 提供 cluster 内部的服务发现和负载均衡;

  • Pod:Kubernetes 使用 Pod 来管理容器,每个 Pod 可以包含一个或多个紧密关联的容器 (sidecar)。


K8s 网络


在 Kubernetes 网络中存在两种 IP(Pod IP 和 Service Cluster IP),Pod IP 地址是实际存在于某个网卡 (可以是虚拟设备) 上的,Service Cluster IP 它是一个虚拟 IP,是由 kube-proxy 使用 Iptables 规则重新定向到其本地端口,再均衡到后端 Pod 的。

K8s Operator 简介

首先讲什么是 Operator:

Kubernetes Operator 是一种封装、部署和管理 Kubernetes 应用的方法。大家都知道,在 k8s 中管理 mysql/redis 等“有状态的服务”比较复杂,比如我们可以自己组合各种编排对象(Deplayment、StatefulSet、DaemonSet、Job 等)来管理这些服务。Operator 的出现就是为了解决这种“复杂性”问题,使得我们更加灵活的管理 mysql/redis 等服务,Operator 的底层还是使用 Kubernetes API 和 kubectl 工具在 Kubernetes 上部署并管理 Kubernetes 应用。


使用 Operator 可以自动化的事情包括:


  • 按需部署应用 / 数据库服务

  • 获取 / 还原应用状态的备份

  • 处理升级以及配置改动

  • 发布一个 service,要求不支持 Kubernetes API 的应用也能发现它

  • 模拟整个或部分集群中的故障以测试其稳定性

  • 在没有内部成员选举程序的情况下,为分布式应用选择 Leader

TiDB Operator 特性

TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统,提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator,TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上,它具有以下特性:


  • 安全地扩展 TiDB 集群

  • TiDB Operator 赋予了 TiDB 在云上的横向扩展能力。

  • TiDB 集群的滚动更新

  • 对 TiDB 集群按顺序优雅地执行滚动更新,实现 TiDB 集群的零停机。

  • 多租户支持

  • 用户可以在一个 Kubernetes 集群上轻松部署和管理多个 TiDB 集群。

  • 自动故障转移

  • 当节点发生故障时,TiDB Operator 会自动为您的 TiDB 集群进行故障切换。

  • 支持 Kubernetes 包管理器

  • 通过拥抱 Kubernetes 软件包管理器 Helm,用户只需一个命令就可以轻松部署 TiDB 集群。

  • 创建时自动监控 TiDB 集群


自动部署 Prometheus,Grafana 用于 TiDB 集群监控,支持以下功能。


  • 跨越多个 namespace 监控多个集群。

  • 多重复制。

  • 目标分片。

  • 动态更新配置和规则。

  • 集成 Thanos 监控框架。

  • 异构集群

  • 比如我想配置不同的 tidb server 分别给 OLTP 和 OLAP 使用,比如我想给不同的 tikv 配置不同的硬盘,在这些情况下,用户可以部署一个异构集群加入现有的集群。


PS: 说的直白点,可以把 TiDB Operator 看做是 k8s 集群中的 “TiUP” 工具。

TiDB Operator 架构


我们来聊下该架构:


  • 左上角:CR(用户自定义资源)

  • 可以看到 TidbCluster 就是用户自定义的资源,对于 tidb 集群的资源,我们可以通过定义一个 CRD(CustomResourceDefinition) 来将 TiDB 各个组件定义为统一的 TidbCluster 资源,大家有空可以去 github 查看下 TiDB 集群 CRD 描述

  • 右上角:TiDB Pods

  • 就是 TiDB 集群的 TiDB Server/PD/TiKV/TiFlash/Ticdc 等集群组件 Pods,每一个 TiDB 集群会对应存在一个 discovery Pod,用于该集群中组件发现其他已经创建的组件。

  • 中间部分:TiDB Operator

  • tidb-controller-manager 

  • 包括 TiDB/PD/TiKV 等 Controller,这些控制器会不断对比 TidbCluster 对象中记录的期望状态与 TiDB 集群的实际状态,比如我们调整扩容了 tikv 的 replicas( tikv 节点数增加),通过对比发现需要扩容 TiKV, TiKV Controller 调整 Kubernetes 中的资源以驱动 TiDB 集群满足期望状态,并根据其他 CR 完成相应的控制逻辑。

  • tidb-scheduler

  • 基于 Kubernetes 调度器扩展,它为 Kubernetes 调度器注入 TiDB 集群特有的调度逻辑,比如 TidbCluster 里面配置了 Pods 的亲和性,PD 和 TiKV 不能调度到同一个 nodes (宿主机),这时 tidb-scheduler 就会根据调度逻辑来选择合适的 nodes。

  • 底层模块

  • 我想说的是 TiDB Operator 的各种功能和特性,都是基于 K8S 提供的基础能力 ( kube-scheduler、kube-apiserver、kube-controller-manager ) 来实现, 基于 CRD + Controller 模式开发自动化的应用程序管理程序,减少运维负担以及出错的可能性


更多细节

总结 & 彩蛋

可能有人对 K8s 还不了解,后面我会专门写一些云原生的文章。


彩蛋就是,后面我还会花 2-3 篇文章讲如何在自建的 K8s 集群部署 TiDB Operator 并且初始化一套新的 TiDB 集群,另外就是使用 TiDB Operator 实现对集群的各种运维操作。


用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB上云之TiDB Operator_集群管理_TiDB 社区干货传送门_InfoQ写作社区