首页 > 其他分享 >TiDB容器化的管理利器--TiDB Operator

TiDB容器化的管理利器--TiDB Operator

时间：2023-05-03 10:32:52浏览次数：43  
标签：Kubernetes -- TiDB 集群 scheduler tidb Operator

作者： lqbyz



简介

TiDB Operator是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上,目前已开源 pingcap/tidb-operator 。

TiDB容器化的管理利器--TiDB Operator_Pod

TiDB Operator 与适用的 TiDB 版本的对应关系如下：

TiDB 版本

适用的 TiDB Operator 版本

dev

dev

TiDB >= 5.4

1.3

5.1 <= TiDB < 5.4

1.3（推荐），1.2

3.0 <= TiDB < 5.1

1.3（推荐），1.2，1.1

2.1 <= TiDB < v3.0

1.0（停止维护）


为什么需要TiDB Operator

第一，TiDB Operator提供自动化部署、升级、扩缩容、备份恢复、配置变更的全生命周期管理。

TiDB 的分层架构对于分布式系统是比较常见的，各个组件都可以根据业务需求独立水平伸缩，并且 TiKV 和 TiDB 都可以独立使用。比如，在 TiKV 之上可以构建兼容 Redis 协议的 KV 数据库，而 TiDB 也可以对接 LevelDB 这样的 KV 存储引擎。但是，这种多组件的分布式系统增加了手工部署和运维的成本。一些传统的自动化部署和运维工具如 Puppet/Chef/SaltStack/Ansible，由于缺乏全局状态管理，不能及时对各种异常情况做自动故障转移，并且很难发挥分布式系统的弹性伸缩能力。其中有些还需要写大量的 DSL 甚至与 Shell 脚本一起混合使用，可移植性较差，维护成本比较高。

第二，在云时代容器成为应用分发部署的基本单位,Kubernetes 成为当前容器编排技术上的标准。

如今各大云厂商都开始提供托管的 Kubernetes 集群，部署在 Kubernetes 平台的应用可以不用绑定在特定云平台，轻松实现在各种云平台之间的迁移，其容器化打包和发布方式也解决了对操作系统环境的依赖。

为了在 Kubernetes 上部署和管理 TiDB 这种有状态的服务，我们需要扩展 StatefulSet 的功能。TiDB Operator 正是基于 Kubernetes 内置的 StatefulSet 云原生开发的 TiDB 集群管理和运维工具。官方本地 PV 方案直到最近的 Kubernetes v1.10 才相对稳定地支持调度功能（需要运行在 Kubernetes v1.10 及以上版本），满足用户对本地 PV 的需求。为了降低用户的使用和管理成本并且拥抱 Kubernetes 开源社区。

第三，执行操作需要TiDB相关的知识。

在通过TiDB Operator部署tidb集群时，需要了解tidb集群的架构，各服务组件的关系以及启动都有相关的顺序的，在扩缩容的时候需要按照相应的组件进行操作。



核心亮点



轻松部署TiDB群集

能安全扩展在TiDB的集群的每个组件，TiDB Operator 则通过自定义资源对象（Custom Resource）、自定义控制器（Custom controller）和调度器扩展（Scheduler extender）为 Kubernetes 注入 TiDB 的专业运维知识，允许用户以 Kubernetes 的声明式 API 风格来管理 TiDB 集群。具体来说，用户只需要描述集群规格，TiDB Operator 就会不断调整 Kubernetes 中的资源，驱动实际集群满足该描述。在这种模式下，TiDB 集群会自动完成服务的健康检查、故障转移，而部署、升级、扩缩容等操作则能通过修改集群的规格定义“一键”完成，极大简化了 TiDB 集群的运维管理



滚动更新。

在没有任何停机的情况下，平稳地执行滚动更新，各服务组件在更新的过程中会逐个进行，当完成后才会有其他的pod进行，出现问题便于快速回滚。



多租户支持

用户可以使用TiDB Operator在单个Kubernetes集群上部署和管理多个TiDB集群。



自动故障切换

当节点/Pod发生故障时，TiDB Operator自动执行故障转移切换。



简单监控

TiDB Operator支持安装Prometheus和Grafana进行集群监控



多云支持

1提供了面向 AWS、谷歌云和阿里云的 Terraform 部署脚本。 这些脚本能帮助大家在十几分钟内创建一个 Kubernetes 集群，并在该集群上部署一个或更多生产可用的 TiDB 集群。在后续的管理过程中，Terraform 脚本会在操作 TiDB 集群的同时对相关的云资源进行操作。比如，当扩容一个 TiDB 集群时，Terraform 脚本就会自动创建更多的云服务器来承载集群扩容后的资源需求。



架构

TiDB容器化的管理利器--TiDB Operator_docker_02

其中，TidbCluster、TidbMonitor、TidbInitializer、Backup、Restore、BackupSchedule、TidbClusterAutoScaler 是由 CRD（CustomResourceDefinition）定义的自定义资源：

  • TidbCluster 用于描述用户期望的 TiDB 集群
  • TidbMonitor 用于描述用户期望的 TiDB 集群监控组件
  • TidbInitializer 用于描述用户期望的 TiDB 集群初始化 Job
  • Backup 用于描述用户期望的 TiDB 集群备份
  • Restore 用于描述用户期望的 TiDB 集群恢复
  • BackupSchedule 用于描述用户期望的 TiDB 集群周期性备份
  • TidbClusterAutoScaler 用于描述用户期望的 TiDB 集群自动伸缩

TiDB 集群的编排和调度逻辑则由下列组件负责：

  • tidb-controller-manager 是一组 Kubernetes 上的自定义控制器。这些控制器会不断对比 TidbCluster 对象中记录的期望状态与 TiDB 集群的实际状态，并调整 Kubernetes 中的资源以驱动 TiDB 集群满足期望状态，并根据其他 CR 完成相应的控制逻辑；
  • tidb-scheduler 是一个 Kubernetes 调度器扩展，它为 Kubernetes 调度器注入 TiDB 集群特有的调度逻辑。
  • tidb-admission-webhook 是一个 Kubernetes 动态准入控制器，完成 Pod、StatefulSet 等相关资源的修改、验证与运维。
  • discovery 是一个用于组件间发现的服务。每一个 TiDB 集群会对应存在一个 discovery Pod，用于该集群中组件发现其他已经创建的组件。


TiDB Controller Manager

tidb-controller-manager不断持续地调整期望状态和实际状态的差异。如果状态不匹配的话，控制器将触发动作以转换为所期待的状态，具体如下图：

TiDB容器化的管理利器--TiDB Operator_docker_03

TiDB容器化的管理利器--TiDB Operator_Pod_04



TiDB Scheduler扩展调度器

TiDB Scheduler 是 Kubernetes 调度器扩展 的 TiDB 实现。TiDB Scheduler 用于向 Kubernetes 添加新的调度规则。Kubernetes 集群中默认会部署一个 kube-scheduler，用于 Pod 调度，默认调度器名字为 default-scheduler，具体的调度规则请参考K8S-POD资源和调度 。

TiDB Scheduler 通过实现 Kubernetes 调度器扩展（Scheduler extender）来添加自定义调度规则。

TiDB Scheduler 组件部署为一个或者多个 Pod，但同时只有一个 Pod 在工作。Pod 内部有两个 Container，一个 Container 是原生的 kube-scheduler；另外一个 Container 是 tidb-scheduler，实现为一个 Kubernetes scheduler extender。

如果 TidbCluster 中配置组件使用 tidb-scheduler，TiDB Operator 创建的 PD、TiDB、TiKV Pod 的 .spec.schedulerName 属性会被设置为 tidb-scheduler，即都用 TiDB Scheduler 自定义调度器来调度。

此时，一个 Pod 的调度流程是这样的：

  • kube-scheduler 拉取所有 .spec.schedulerName 为 tidb-scheduler 的 Pod，对于每个 Pod 会首先经过 Kubernetes 默认调度规则过滤；
  • 在这之后，kube-scheduler 会发请求到 tidb-scheduler 服务，tidb-scheduler 会通过一些自定义的调度规则（见上述介绍）对发送过来的节点进行过滤，最终将剩余可调度的节点返回给 kube-scheduler；
  • 最终由 kube-scheduler 决定最终调度的节点。


TiDB Operator 准入控制器

Kubernetes 在 1.9 版本引入了 动态准入机制，从而使得拥有对 Kubernetes 中的各类资源进行修改与验证的功能。 在 TiDB Operator 中，我们也同样使用了动态准入机制来帮助我们进行相关资源的修改、验证与运维。

TiDB Operator 准入控制器与大部分 Kubernetes 平台上产品的准入控制器较为不同，TiDB Operator 通过扩展 API-Server 与 WebhookConfiguration 的两个机制组合而成。所以需要 Kubernetes 集群启用聚合层功能，通常情况下这个功能已经默认开启。如需查看是否开启聚合层功能，请参考启用 Kubernetes Apiserver 标志。



原理

Operator 本质上是 Kubernetes 的控制器（Controller），其核心思想是用户给定一个 Spec 描述文件，Controller 根据 Spec 的变化，在 Kubernetes 集群中创建对应资源，并且不断调整资源使其状态满足用户预期的 Spec。

TiDB容器化的管理利器--TiDB Operator_自定义_05

上图是 TiDB Operator 工作流程原理图，其中 TidbCluster 是通过 CRD（Custom Resource Definition）扩展的内置资源类型：

  1. 用户通过 Helm 往 Kubernetes API Server 创建或更新 TidbCluster 对象。
  2. TiDB Operator 通过 watch API Server 中的 TidbCluster 对象创建更新或删除，维护 PD/TiKV/TiDB StatefulSet, Service 和 Deployment 对象更新。
  3. Kubernetes 根据 StatefulSet, Service 和 Deployment 对象创建更新或删除对应的容器和服务。

在第 2 步中，TiDB Operator 在更新 StatefulSet 等对象时会参考 PD API 给出的集群状态来做出 TiDB 集群的运维处理。通过 TiDB Operator 和 Kubernetes 的动态调度处理，创建出符合用户预期的 TiDB 集群。



安装部署TiDB Operator



安装helm

Helm 是一个 Kubernetes 的包管理工具，是查找、分享和使用软件构建 Kubernetes 的最优方式，类似 Linux 的包管理器，如RedHat系的yum、Debian的apt，可以很方便的将之前打包好的 yaml 文件部署到 Kubernetes 上。Helm主要解决以下问题：1、把yaml作为一个整体管理。2、实现yaml的高效复用。3、实现应用级别的版本管理。helm安装比较简单

Helm官方下载地址 （https://github.com/helm/helm/releases ）
wget https://get.helm.sh/helm-v3.4.2-linux-amd64.tar.gz

解压Helm
tar zxvf helm-v3.4.2-linux-amd64.tar.gz

移动到主节点 /usr/bin 目录
mv linux-amd64/helm /usr/bin/

验证是否安装成功
helm version



部署TiDB Operator(离线方式)

由于客户大部分都是内网不能上外网，所以本文档以离线的方式部署TiDB Operatro



下载tidb-operator

#下载最新版本的包
wget http://charts.pingcap.org/tidb-operator-v1.4.3.tgz
#解压
tar zxvf tidb-operator.v1.4.3.tgz



下载所需的镜像，打标签并推到私有仓库

#tidb operator所用到的所有镜像
pingcap/tidb-operator:v1.4.3
pingcap/tidb-backup-manager:v1.4.3
bitnami/kubectl:latest
pingcap/advanced-statefulset:v0.3.3
k8s.gcr.io/kube-scheduler:v1.16.9

##镜像拉取并下载
docker pull pingcap/tidb-operator:v1.4.3
docker pull pingcap/tidb-backup-manager:v1.4.3
docker pull bitnami/kubectl:latest
docker pull pingcap/advanced-statefulset:v0.3.3

docker save -o tidb-operator-v1.4.3.tar pingcap/tidb-operator:v1.4.3
docker save -o tidb-backup-manager-v1.4.3.tar pingcap/tidb-backup-manager:v1.4.3
docker save -o bitnami-kubectl.tar bitnami/kubectl:latest
docker save -o advanced-statefulset-v0.3.3.tar pingcap/advanced-statefulset:v0.3.3

##上传镜像

docker load -i tidb-operator-v1.4.3.tar
docker load -i tidb-backup-manager-v1.4.3.tar
docker load -i bitnami-kubectl.tar
docker load -i advanced-statefulset-v0.3.3.tar

##备注，如果推到私有仓库需要给镜像打标签并上传
docker tag pingcap/tidb-operator:v1.4.3 xxx.com:5003/pingcap/tidb-operator:v1.4.3
docker push xxx.com:5003/pingcap/tidb-operator:v1.4.3



配置TiDB Operator

主要配置的镜像名、limits、requests 和 replicas，请根据需要进行修改

vim ./tidb-operator/values.yaml
clusterScoped: true

rbac:
  create: true

timezone: UTC

operatorImage: pingcap/tidb-operator:v1.4.3
imagePullPolicy: IfNotPresent

tidbBackupManagerImage: pingcap/tidb-backup-manager:v1.4.3
##启用asts配置
features:
- AdvancedStatefulSet=true
advancedStatefulset:
  create: true

appendReleaseSuffix: false

controllerManager:
  create: true
  serviceAccount: tidb-controller-manager

  clusterPermissions:
    nodes: true
    persistentvolumes: true
    storageclasses: true

  logLevel: 2
  replicas: 1
  resources:
    requests:
      cpu: 80m
      memory: 50Mi



  autoFailover: true
  pdFailoverPeriod: 5m
  tikvFailoverPeriod: 5m
  tidbFailoverPeriod: 5m
  tiflashFailoverPeriod: 5m
  dmMasterFailoverPeriod: 5m
  dmWorkerFailoverPeriod: 5m
  detectNodeFailure: false
  affinity: {}
  nodeSelector: {}
  tolerations: []
  selector: []
  env: []
  securityContext: {}
  podAnnotations: {}

scheduler:
  create: true
  serviceAccount: tidb-scheduler
  logLevel: 2
  replicas: 1
  schedulerName: tidb-scheduler
  resources:
    limits:
      cpu: 250m
      memory: 150Mi
    requests:
      cpu: 80m
      memory: 50Mi
  kubeSchedulerImageName: k8s.gcr.io/kube-scheduler
  affinity: {}
  nodeSelector: {}
  tolerations: []
  securityContext: {}
  podAnnotations: {}

  configmapAnnotations: {}

advancedStatefulset:
  create: true
  image: pingcap/advanced-statefulset:v0.4.0
  imagePullPolicy: IfNotPresent
  serviceAccount: advanced-statefulset-controller
  logLevel: 4
  replicas: 1
  resources:
    limits:
      cpu: 500m
      memory: 300Mi
    requests:
      cpu: 200m
      memory: 50Mi
  affinity: {}
  nodeSelector: {}
  tolerations: []
  securityContext: {}

admissionWebhook:
  create: false
  replicas: 1
  serviceAccount: tidb-admission-webhook
  logLevel: 2
  rbac:
    create: true
  validation:
    statefulSets: false
    pingcapResources: false
  mutation:
    pingcapResources: true
  failurePolicy:
    validation: Fail
    mutation: Fail
  apiservice:
    insecureSkipTLSVerify: true
    tlsSecret: ""
    caBundle: ""
  cabundle: ""
  securityContext: {}
  nodeSelector: {}
  tolerations: []



安装TiDB Operator

kubectl create ns tidb-admin
helm install tidb-operator ./tidb-operator --namespace=tidb-admin



升级TiDB Operator

helm upgrade tidb-operator ./tidb-operator --namespace=tidb-admin



Tidb集群部署

具体参考https://tidb.net/blog/9f9d32b3

标签：Kubernetes,--,TiDB,集群,scheduler,tidb,Operator
From： https://blog.51cto.com/u_15550868/6241111

相关文章

  • TiCDC 源码解读（5）-- TiCDC DDL 事件处理逻辑 与 Filter 实现介绍
    作者：asddongmen内容概要本文是TiCDC源码解读的第五篇，本文将会介绍TiCDC对DDL的处理方式和Filter功能的实现（基于TiCDCv6.5.0版本代码），文章将会围绕以下4个问题展开。为什么TiCDC只用Owner节点来同步DDL？DDL事件会对同步任务的进度有什么影响？TiCDC是怎么在内......
  • 携程 x TiDB丨应对全球业务海量数据增长，一栈式 HTAP 实现架构革新
    作者：TiDB社区小助手导读携程作为全球领先的一站式旅行平台，旗下拥有携程旅行网、去哪儿网、Skyscanner等品牌。携程旅行网向超过9000万会员提供酒店预订、酒店点评及特价酒店查询、机票预订、飞机票查询、时刻表、票价查询、航班查询等服务。随着业务量迅速增长，携程需要更敏......
  • 基于阿里云数据库TiDB的性能压测初体验
    作者：arron基于阿里云数据库TiDB的性能压测初体验申请阿里云TiDB地址：https://market.aliyun.com/isv-pingcap的过程，申请和部署过程非常简单直观，按提示一步步来即可，这里就忽略了。本次实验，主要对该云TiDB集群进行性能测试，使用测试工具有sysbench，tpcc，CH-benCHmark参考文档：如何用......
  • 基于 TiCDC 的 TiDB 复制集群的计划内和计划外切换验证步骤
    作者：pepezzzz环境准备集群名称和版本上游tidb集群:tidb-h下游tidb集群:tidb-cdc版本：v6.5.0CDC专用用户：cdcuser注：业务负载用户应独立于CDC专用用户。业务数据库：cdcdb模拟业务应用：Sysbench、BANK。上下游创建ticdc同步用户和数据库createusercdcuseridentified......
  • 物理机安装 TiKV 时 RAID 卡在线配置方式
    作者：pepezzzzRaid配置的规划安装TiDB集群的物理机配置如下：组件配置描述CPU2*IntelXeonGold5218R(2.1GHz,20Core)内存384GB系统盘2*480GBSATASSDRAID1数据盘14*1.92TBSATASSDRAID10用14*1.92TBSATASSD组成RAID10后，减去RAID的元数据和1024的转换损......
  • Win11系统，VS2022编写数据库程序，小体积，绿色单文件，支持密码保护，XP到Win11都能运行
    在WIN11中用VS2022编写小体积的绿色单文件,支持密码保护，XP到WIN11都能运行的数据库程序1.用VC60建立一个Win32工程，VC60建立的工程默认是字节型的。2.用VS2010读取并转换为2010格式，再用VS2022读取，选择SDK和平台都不升级3.把wxsqlite3-4.5.1.zip\wxsqlite3-4.5.1\sqlite3se......
  • 根据PDF模板生成具体内容PDF，模板pdf需要设置字段域
    packagecom.zudp.common.core.utils.pdf;importcom.itextpdf.text.DocumentException;importcom.itextpdf.text.Image;importcom.itextpdf.text.Rectangle;importcom.itextpdf.text.pdf.*;importorg.apache.commons.lang3.StringUtils;importorg.apache.http.en......
  • harbor数据库迁移
    harbor数据库迁移(相同版本间迁移)一、数据导出（旧harbor机）1、进入数据库容器[root@localhost~]#dockerexec-uroot-itd53efe26b3da/bin/bash12、导出registry数据库**root[**/**]#**pg_dump-Upostgresregistry>registry.sql​**root[**/**]#**exit1233......
  • 学习《操作系统导论》04
    调度：多级反馈队列（MLFQ：Multi-LevelFeedQueue）续接上一节中最后的问题，没有完备的关于进程相关的知识背景，如何设计一个调度方案？答：从历史中学习，MLFQ就是从历史经验中预测未来的一个典型例子，如果工作具有明显的阶段性行为，因此可以预测，那么此时可能会很有效，当然也需要格外小心使用这......
  • PAT Advanced 1005. Spell It Right
    PATAdvanced1005.SpellItRight1.ProblemDescription:Givenanon-negativeinteger \(N\),yourtaskistocomputethesumofallthedigitsof \(N\),andoutputeverydigitofthesuminEnglish.2.InputSpecification:Eachinputfilecontainson......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99