tidb-operator生产实战篇

晓磊聊DB 2024-12-20

还记得在2022年10月19号就写了《TiDB上云之TiDB Operator》这篇对tidb-operator的简单介绍文章，到现在已经鸽了2年多，本文算是续上了。作为一个从2021年就开始调研和生产环境使用tidb-operator的数据库老兵来说,其实基本的操作tidb-operator官方文档就写的比较详细了，本文将基于最新版的tidb-operator来展开，详细介绍下在自建Kubernets生产环境部署一套可供业务访问的TiDB 8.4.0版本集群，包括需要的环境，集群配置、部署流程以及基本TiDB on Kubernets的操作也会一并展示。

一、环境要求

（1）如果是生产环境，建议部署最新GA版本的tidb-operator(当前最新的是V1.6)

（2）如果要部署的TiDB集群版本>=8.0，也建议部署V1.6版本的tidb-operator

（3）Kubernets版本要求：client v1.28 , server v1.20+(kubectl version查看)

（4）Docker版本：docker CE 18.09+

（5）TiDB版本：V8.4.0（当然大家也可以按需安装具体版本）

二、tidb-operator生产环境部署

（1）生产环境Kubernets配置要求

包括且不限于：

关闭防火墙
禁用SELinux
关闭swap
内核参数调优
CPU性能模式
Ulimit配置

（2）初始化pv资源池

生产环境的tikv比较依赖IO性能，所以自建的集群就可以选择本地存储模式，并且要用io性能较好的nvme-ssd，相对于网络存储，本地存储一旦硬盘损坏则tikv数据丢失，需要靠tikv本身的multi-raft机制来保证业务的数据不丢。

这些pv需要提前初始化出来当作一个存储的资源池，基本上都是使用local-static-provisioner 项目中的 local-volume-provisioner 程序创建本地存储对象，具体的初始化方式tidb-operator官网给出了操作步骤，本文假设已经完成了pv存储资源池的初始化。后面我可能会出一篇专门讲Kubernets的存储原理和生产环境pv治理的文章。

（3）部署tidb-operator

tidb-operator的部署一般都是基于Kubernetes中的包管理器helm来安装。helm安装比较简单，这里就不加安装过程了，安装好helm后需要添加pingcap仓库，添加仓库后可以通过search repo的命令查看软件包(专业名词叫chart)，基本的操作方式如下：

#helm repo add pingcap https://charts.pingcap.org/
#helm search repo pingcap
NAME                      CHART VERSION    APP VERSION    DESCRIPTION
pingcap/br-federation     v1.6.0           v1.6.0         br-federation Helm chart for Kubernetes
pingcap/diag              v1.3.1           v1.3.1         clinic diag Helm chart for Kubernetes
pingcap/tidb-backup       v1.5.1                          DEPRECATED(refer new instructions at https://do...
pingcap/tidb-cluster      v1.5.1                          DEPRECATED(refer new instructions at https://do...
pingcap/tidb-drainer      v1.6.0                          A Helm chart for TiDB Binlog drainer.
pingcap/tidb-lightning    v1.6.0                          A Helm chart for TiDB Lightning
pingcap/tidb-operator     v1.6.0           v1.6.0         tidb-operator Helm chart for Kubernetes
pingcap/tikv-importer     v1.5.1                          A Helm chart for TiKV Importer
pingcap/tikv-operator     v0.1.0           v0.1.0         A Helm chart for Kubernetes

在helm准备好后，就可以创建TiDB 集群的用户自定义资源(简称CRD)，CRD的用处在之前的文章中有提到，下面给大家看下TiDB on Kubernetes 都包括哪些自定义的资源：

#wget https://raw.githubusercontent.com/pingcap/tidb-operator/v1.6.0/manifests/crd.yaml
#kubectl create -f ./crd.yaml
#kubectl get crd |grep pingcap
backups.pingcap.com                                         2024-03-12T07:25:21Z
backupschedules.pingcap.com                                 2024-03-12T07:25:21Z
dmclusters.pingcap.com                                      2024-03-12T07:25:23Z
restores.pingcap.com                                        2024-03-12T07:25:24Z
tidbclusterautoscalers.pingcap.com                          2024-03-12T07:25:24Z
tidbclusters.pingcap.com                                    2024-03-12T07:25:33Z
tidbdashboards.pingcap.com                                  2024-03-12T07:25:34Z
tidbinitializers.pingcap.com                                2024-03-12T07:25:34Z
tidbmonitors.pingcap.com                                    2024-03-12T07:25:34Z
tidbngmonitorings.pingcap.com                               2024-03-12T07:25:35Z

需要说明的是，tidb-operator会默认安装2个组件，分别是tidb-controller-manager和tidb-scheduler，tidb-controller-manager是tidb-operator最核心的组件(没有之一),底层也是依赖kubernetes原生的Controller Manager实现了kubernetes中的TiDB集群的生命周期管理。

这里重点说明下：tidb-scheduler这个组件是非必须的，因为当前版本kubernetes的kube-scheduler已经足够强大，tidb-scheduler这个组件这个组件诞生在kubernetes < v1.16版本时代，kubernetes的默认调度器对于Pods 调度不够均匀才产生，所以最新版本直接在部署tidb-operator的配置文件values-tidb-operator.yaml中将scheduler.create配置为false即可不部署tidb-scheduler。

获取配置文件
helm inspect values pingcap/tidb-operator --version=1.6。0 > tidb-operator/values-tidb-operator.yaml
部署tidb-operator
helm install tidb-operator pingcap/tidb-operator --namespace=tidb-operator --version=1.6.0 -f /tidb-operator/values-tidb-operator.yaml
查看tidb-operator部署情况
kubectl get pods -n tidb-operator
NAME                                      READY   STATUS    RESTARTS   AGE
tidb-controller-manager-74dc9cc58-sl454   1/1     Running   0          86d

至此，tidb-operator已经部署完毕就差部署TiDB集群了。

三、tidb on k8s部署

在初始化集群前，需要配置好集群拓扑，下面的是一个3pd/3tikv/3tidbserver/2tiflash的版本是8.4.0集群的基本配置，生产环境需要配置的更多，因每个公司的kubernetes资源情况不同而不同，以下的“生产环境”配置删除了一些配置，好在这些配置在官网都有说明，比如镜像管理：需要把相应的包下载到公司的镜像地址，否则拉取镜像失败，比如亲和性配置，可以有nodes污点的容忍配置，避免tikv/tidb混布到同一台nodes宿主机的亲和性配置；还有一些tikv的参数配置，因依赖ssd的io能力不同而不同，计算层tidb的配置也如此，初次之外没有啥特殊的生产配置了。还有强调一点，生产环境的TiDB集群pods资源QoS是有最低配置要求的(以下配置文件中的limits/requests部分)，详见官网的生产环境TiDB部署资源要求。tidb-test.yaml的简版配置如下：

apiVersion: pingcap.com/v1alpha1
kind: TidbCluster
metadata:
  name: tidb-test
  namespace: tidb-test
spec:
  timezone: Asia/Shanghai
  pvReclaimPolicy: Retain
  configUpdateStrategy: RollingUpdate
  enableDynamicConfiguration: true
  acrossK8s: true
  discovery:
    limits:
      cpu: 2000m
      memory: 4Gi
    requests:
      cpu: 1000m
      memory: 2Gi
  pd:
    baseImage: pingcap/pd:v8.4.0
    replicas: 3
    # if storageClassName is not set, the default Storage Class of the Kubernetes cluster will be used
    enableDashboardInternalProxy: true
    storageClassName: local-storage
    requests:
      cpu: 10000m
      memory: 15Gi
      storage: 300Gi
    limits:
      cpu: 10000m
      memory: 15Gi
    config: {}
  tiflash:
    baseImage: pingcap/tiflash:v8.4.0
    maxFailoverCount: 3
    replicas: 2
    storageClaims:
    - resources:
        requests:
          storage: 1000Gi
      storageClassName: local-storage
  tikv:
    baseImage: pingcap/tikv:v8.4.0
    replicas: 3
    # if storageClassName is not set, the default Storage Class of the Kubernetes cluster will be used
    storageClassName: local-storage
    requests:
      cpu: 6000m
      memory: 12Gi
      storage: 1760Gi
    limits:
      cpu: 14000m
      memory: 32Gi
      storage: 1760Gi
    config:
      log-level: "info"
      raftdb:
        max-background-jobs: 10
        max-sub-compactions: 4
      raftstore:
        apply-pool-size: 8
        store-pool-size: 8
  tidb:
    baseImage: pingcap/tidb:v8.4.0
    replicas: 3
    limits:
      cpu: 12000m
      memory: 20Gi
    requests:
      cpu: 12000m
      memory: 20Gi
    service:
      type: NodePort
    config:
      status:
        record-db-qps: true
      performance:
        feedback-probability: 0.0

编写好了配置，就可以应用执行了，在应用之前，需要先创建namespace，生产环境我不建议所有的TiDB集群都放一个namespace导致不好管理。建议一个集群一个namesapce。

kubectl create namespace tidb-test

kubernetes下部署集群太简单了，一条apply命令足以，部署完的TiDB集群pods组成有：负责TiDB集群组件发现的tidb-test-discovery、TiDB集群大脑pd、SQL计算层tidb-test-tid、OLAP/向量存储依赖的tidb-test-tiflash、集群数据存储tidb-test-tikv。因为TiDB集群底层基于有状态的statefulset资源拉起，所以这些pods都带有0/1/2这些后缀标识。

#kubectl apply -f tidb-test.yaml -n tidb-test


#kubectl get tc  -n tidb-test
NAME        READY   PD                                                 STORAGE   READY   DESIRE   TIKV                                                 STORAGE   READY   DESIRE   TIDB                                                 READY   DESIRE   AGE
tidb-test   True    pingcap/pd:v8.4.0   300Gi     3       3        pingcap/tikv:v8.4.0   1760Gi    3       3        pingcap/tidb:v8.4.0   3       3        6d7h


#kubectl get pods  -n tidb-test
NAME                                   READY   STATUS    RESTARTS   AGE
tidb-test-discovery-5669ffbc68-vp57q   1/1     Running   0          6d7h
tidb-test-pd-0                         1/1     Running   0          6d7h
tidb-test-pd-1                         1/1     Running   1          6d7h
tidb-test-pd-2                         1/1     Running   0          6d7h
tidb-test-tidb-0                       2/2     Running   0          6d7h
tidb-test-tidb-1                       2/2     Running   0          6d7h
tidb-test-tidb-2                       2/2     Running   0          6d7h
tidb-test-tiflash-0                    4/4     Running   0          6d7h
tidb-test-tiflash-1                    4/4     Running   0          6d7h
tidb-test-tikv-0                       1/1     Running   0          6d7h
tidb-test-tikv-1                       1/1     Running   0          6d7h
tidb-test-tikv-2                       1/1     Running   0          6d7h

这样一个TiDB 8.4.0的生产集群就部署完毕了，为了给大家展示一个TiDB on K8S中部署完毕都有什么组件，给大家看个整体的，然后我一一说明，通过下面的展示可以看到，有pod、service、deployment、replicaset、statefulset等组成。

# kubectl get all -n tidb-test
NAME                                       READY   STATUS    RESTARTS   AGE
pod/tidb-test-discovery-5669ffbc68-vp57q   1/1     Running   0          6d7h
pod/tidb-test-pd-0                         1/1     Running   0          6d7h
pod/tidb-test-pd-1                         1/1     Running   1          6d7h
pod/tidb-test-pd-2                         1/1     Running   0          6d7h
pod/tidb-test-tidb-0                       2/2     Running   0          6d7h
pod/tidb-test-tidb-1                       2/2     Running   0          6d7h
pod/tidb-test-tidb-2                       2/2     Running   0          6d7h
pod/tidb-test-tiflash-0                    4/4     Running   0          6d7h
pod/tidb-test-tiflash-1                    4/4     Running   0          6d7h
pod/tidb-test-tikv-0                       1/1     Running   0          6d7h
pod/tidb-test-tikv-1                       1/1     Running   0          6d7h
pod/tidb-test-tikv-2                       1/1     Running   0          6d7h
NAME                             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
service/tidb-test-discovery      ClusterIP   xxx.xxx.160    <none>        10261/TCP,10262/TCP                     6d7h
service/tidb-test-pd             ClusterIP   xxx.xxx.114   <none>        2379/TCP                                6d7h
service/tidb-test-pd-peer        ClusterIP   None             <none>        2380/TCP,2379/TCP                       6d7h
service/tidb-test-tidb           NodePort    xxx.xxx.213   <none>        4000:32569/TCP,10080:30286/TCP          6d7h
service/tidb-test-tidb-peer      ClusterIP   None             <none>        10080/TCP                               6d7h
service/tidb-test-tiflash-peer   ClusterIP   None             <none>        3930/TCP,20170/TCP,8234/TCP,20292/TCP   6d7h
service/tidb-test-tikv-peer      ClusterIP   None             <none>        20160/TCP                               6d7h
NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/tidb-test-discovery   1/1     1            1           6d7h
NAME                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/tidb-test-discovery-5669ffbc68   1         1         1       6d7h
NAME                                 READY   AGE
statefulset.apps/tidb-test-pd        3/3     6d7h
statefulset.apps/tidb-test-tidb      3/3     6d7h
statefulset.apps/tidb-test-tiflash   2/2     6d7h
statefulset.apps/tidb-test-tikv      3/3     6d7h

当然了，也有pd/tikv/tiflash这些存储依赖的pv/pvc的资源：

# kubectl get pvc -n tidb-test
NAME                        STATUS   VOLUME              CAPACITY   ACCESS MODES   STORAGECLASS         AGE
data0-tidb-test-tiflash-0   Bound    local-pv-d425ecd    3519Gi     RWO            local-storage   6d8h
data0-tidb-test-tiflash-1   Bound    local-pv-c16258d    3519Gi     RWO            local-storage   6d8h
pd-tidb-test-pd-0           Bound    local-pv-c575563    3519Gi     RWO            local-storage   6d8h
pd-tidb-test-pd-1           Bound    local-pv-ca42a6f0   3519Gi     RWO            local-storage   6d8h
pd-tidb-test-pd-2           Bound    local-pv-33c3558a   3519Gi     RWO            local-storage   6d8h
tikv-tidb-test-tikv-0       Bound    local-pv-d8ef4dc6   3519Gi     RWO            local-storage   6d8h
tikv-tidb-test-tikv-1       Bound    local-pv-4571d680   3519Gi     RWO            local-storage   6d8h
tikv-tidb-test-tikv-2       Bound    local-pv-84783a81   3519Gi     RWO            local-storage   6d8h
# kubectl get pv|grep tidb-test
local-pv-33c3558a                          3519Gi     RWO            Delete           Bound       tidb-test/pd-tidb-test-pd-2                                                           local-storage                                            6d8h
local-pv-4571d680                          3519Gi     RWO            Delete           Bound       tidb-test/tikv-tidb-test-tikv-1                                                       local-storage                                            288d
local-pv-84783a81                          3519Gi     RWO            Delete           Bound       tidb-test/tikv-tidb-test-tikv-2                                                       local-storage                                            288d
local-pv-c16258d                           3519Gi     RWO            Delete           Bound       tidb-test/data0-tidb-test-tiflash-1                                                   local-storage                                            288d
local-pv-c575563                           3519Gi     RWO            Delete           Bound       tidb-test/pd-tidb-test-pd-0                                                           local-storage                                            259d
local-pv-ca42a6f0                          3519Gi     RWO            Delete           Bound       tidb-test/pd-tidb-test-pd-1                                                           local-storage                                            6d8h
local-pv-d425ecd                           3519Gi     RWO            Delete           Bound       tidb-test/data0-tidb-test-tiflash-0                                                   local-storage                                            288d
local-pv-d8ef4dc6                          3519Gi     RWO            Delete           Bound       tidb-test/tikv-tidb-test-tikv-0                                                       local-storage                                            288d

四、总结

本次从部署环境、服务器配置、tidb-operator部署到最后部署上TiDB集群，说明了一些生产环境的注意事项，按照本文说明可以在生产环境搭建出一套可用的TiDB集群。后面我还会用一篇文章说明TiDB集群的初始化，还有生产环境如何访问TiDB集群。

文章转载自晓磊聊DB，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

tidb-operator生产实战篇

评论