TiDB上云之TiDB Operator

如何在自家私有云或者共有云上部署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 实现对集群的各种运维操作。