作者： 代晓磊 _Mars 原文来源：https://tidb.net/blog/e32b968d
还记得在 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 pingcapNAME CHART VERSION APP VERSION DESCRIPTIONpingcap/br-federation v1.6.0 v1.6.0 br-federation Helm chart for Kubernetespingcap/diag v1.3.1 v1.3.1 clinic diag Helm chart for Kubernetespingcap/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 Lightningpingcap/tidb-operator v1.6.0 v1.6.0 tidb-operator Helm chart for Kubernetespingcap/tikv-importer v1.5.1 A Helm chart for TiKV Importerpingcap/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 pingcapbackups.pingcap.com 2024-03-12T07:25:21Zbackupschedules.pingcap.com 2024-03-12T07:25:21Zdmclusters.pingcap.com 2024-03-12T07:25:23Zrestores.pingcap.com 2024-03-12T07:25:24Ztidbclusterautoscalers.pingcap.com 2024-03-12T07:25:24Ztidbclusters.pingcap.com 2024-03-12T07:25:33Ztidbdashboards.pingcap.com 2024-03-12T07:25:34Ztidbinitializers.pingcap.com 2024-03-12T07:25:34Ztidbmonitors.pingcap.com 2024-03-12T07:25:34Ztidbngmonitorings.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-operatorhelm 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-operatorNAME READY STATUS RESTARTS AGEtidb-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/v1alpha1kind: TidbClustermetadata: name: tidb-test namespace: tidb-testspec: 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-testNAME READY PD STORAGE READY DESIRE TIKV STORAGE READY DESIRE TIDB READY DESIRE AGEtidb-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-testNAME READY STATUS RESTARTS AGEtidb-test-discovery-5669ffbc68-vp57q 1/1 Running 0 6d7htidb-test-pd-0 1/1 Running 0 6d7htidb-test-pd-1 1/1 Running 1 6d7htidb-test-pd-2 1/1 Running 0 6d7htidb-test-tidb-0 2/2 Running 0 6d7htidb-test-tidb-1 2/2 Running 0 6d7htidb-test-tidb-2 2/2 Running 0 6d7htidb-test-tiflash-0 4/4 Running 0 6d7htidb-test-tiflash-1 4/4 Running 0 6d7htidb-test-tikv-0 1/1 Running 0 6d7htidb-test-tikv-1 1/1 Running 0 6d7htidb-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-testNAME READY STATUS RESTARTS AGEpod/tidb-test-discovery-5669ffbc68-vp57q 1/1 Running 0 6d7hpod/tidb-test-pd-0 1/1 Running 0 6d7hpod/tidb-test-pd-1 1/1 Running 1 6d7hpod/tidb-test-pd-2 1/1 Running 0 6d7hpod/tidb-test-tidb-0 2/2 Running 0 6d7hpod/tidb-test-tidb-1 2/2 Running 0 6d7hpod/tidb-test-tidb-2 2/2 Running 0 6d7hpod/tidb-test-tiflash-0 4/4 Running 0 6d7hpod/tidb-test-tiflash-1 4/4 Running 0 6d7hpod/tidb-test-tikv-0 1/1 Running 0 6d7hpod/tidb-test-tikv-1 1/1 Running 0 6d7hpod/tidb-test-tikv-2 1/1 Running 0 6d7hNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEservice/tidb-test-discovery ClusterIP xxx.xxx.160 <none> 10261/TCP,10262/TCP 6d7hservice/tidb-test-pd ClusterIP xxx.xxx.114 <none> 2379/TCP 6d7hservice/tidb-test-pd-peer ClusterIP None <none> 2380/TCP,2379/TCP 6d7hservice/tidb-test-tidb NodePort xxx.xxx.213 <none> 4000:32569/TCP,10080:30286/TCP 6d7hservice/tidb-test-tidb-peer ClusterIP None <none> 10080/TCP 6d7hservice/tidb-test-tiflash-peer ClusterIP None <none> 3930/TCP,20170/TCP,8234/TCP,20292/TCP 6d7hservice/tidb-test-tikv-peer ClusterIP None <none> 20160/TCP 6d7hNAME READY UP-TO-DATE AVAILABLE AGEdeployment.apps/tidb-test-discovery 1/1 1 1 6d7hNAME DESIRED CURRENT READY AGEreplicaset.apps/tidb-test-discovery-5669ffbc68 1 1 1 6d7hNAME READY AGEstatefulset.apps/tidb-test-pd 3/3 6d7hstatefulset.apps/tidb-test-tidb 3/3 6d7hstatefulset.apps/tidb-test-tiflash 2/2 6d7hstatefulset.apps/tidb-test-tikv 3/3 6d7h
复制代码
当然了，也有 pd/tikv/tiflash 这些存储依赖的 pv/pvc 的资源
# kubectl get pvc -n tidb-testNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEdata0-tidb-test-tiflash-0 Bound local-pv-d425ecd 3519Gi RWO local-storage 6d8hdata0-tidb-test-tiflash-1 Bound local-pv-c16258d 3519Gi RWO local-storage 6d8hpd-tidb-test-pd-0 Bound local-pv-c575563 3519Gi RWO local-storage 6d8hpd-tidb-test-pd-1 Bound local-pv-ca42a6f0 3519Gi RWO local-storage 6d8hpd-tidb-test-pd-2 Bound local-pv-33c3558a 3519Gi RWO local-storage 6d8htikv-tidb-test-tikv-0 Bound local-pv-d8ef4dc6 3519Gi RWO local-storage 6d8htikv-tidb-test-tikv-1 Bound local-pv-4571d680 3519Gi RWO local-storage 6d8htikv-tidb-test-tikv-2 Bound local-pv-84783a81 3519Gi RWO local-storage 6d8h# kubectl get pv|grep tidb-testlocal-pv-33c3558a 3519Gi RWO Delete Bound tidb-test/pd-tidb-test-pd-2 local-storage 6d8hlocal-pv-4571d680 3519Gi RWO Delete Bound tidb-test/tikv-tidb-test-tikv-1 local-storage 288dlocal-pv-84783a81 3519Gi RWO Delete Bound tidb-test/tikv-tidb-test-tikv-2 local-storage 288dlocal-pv-c16258d 3519Gi RWO Delete Bound tidb-test/data0-tidb-test-tiflash-1 local-storage 288dlocal-pv-c575563 3519Gi RWO Delete Bound tidb-test/pd-tidb-test-pd-0 local-storage 259dlocal-pv-ca42a6f0 3519Gi RWO Delete Bound tidb-test/pd-tidb-test-pd-1 local-storage 6d8hlocal-pv-d425ecd 3519Gi RWO Delete Bound tidb-test/data0-tidb-test-tiflash-0 local-storage 288dlocal-pv-d8ef4dc6 3519Gi RWO Delete Bound tidb-test/tikv-tidb-test-tikv-0
复制代码
四、总结
本次从部署环境、服务器配置、tidb-operator 部署到最后部署上 TiDB 集群，说明了一些生产环境的注意事项，按照本文说明可以在生产环境搭建出一套可用的 TiDB 集群。后面我还会用一篇文章说明 TiDB 集群的初始化，还有生产环境如何访问 TiDB 集群。
评论