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