将TiDB各服务组件混布到物理机集群和K8S环境的探索

前提条件

K8S集群外的服务器节点和K8S集群内的Pod网络必须保持互通(本文采用将物理机节点加入K8S集群然后打污点并驱逐该服务器里边的pod的方式来实现)

K8S机器外的服务器节点必须可以通过添加解析的方式来解析K8S集群内部Pod域名（具体见第一步）

待迁移集群没有开启组件间 TLS 加密通信

环境

目前环境主要配置如下：

序号

环境

集群名称

组件

数量

备注

1

IDC

tidb-idc

tidb

1

2

pd

3

3

tikv

3

4

K8S环境

tidb-test

tidb

2

命名空间为lqbyz

5

pd

3

6

tikv

3

物理机dashboard如下

第一步：在待迁移的物理机集群的所有节点中配置K8S集群内的DNS解析服务

获取K8S集群CoreDNS 或 kube-dns 服务的 endpoints 的 Pod ip 地址列表：

kubectl describe svc/kube-dns -n kube-system

修改所有待迁移物理机集群的节点/etc/resolv.conf配置，添加如下配置

search default.svc.cluster.local svc.cluster.local cluster.local nameserver <CoreDNS Pod_IP_1> nameserver <CoreDNS Pod_IP_2> nameserver <CoreDNS Pod_IP_n> vi /etc/resolv.conf search default.svc.cluster.local svc.cluster.local cluster.local svc.cluster.local nameserver 10.244.0.32 nameserver 10.244.0.33

通过ping在物理机节点测试K8S集群内域名是否正常访问

第二步：在K8S中创建TiDB集群

查看pd节点的地址和端口号

pd-ctl -u http://<address>:<port> member | jq .members | .[] | .client_urls ##执行结果如下： [root@tiup-172-16-5-144 ctl]# ./pd-ctl -u http://172.16.5.144:2379 member | jq .members | .[] | .client_urls [ "http://172.16.5.144:2379" ] [ "http://172.16.5.198:2379" ] [ "http://172.16.6.132:2379" ]

在K8S中创建目标TiDB集群（TiKV 节点个数不少于 3 个），并在 spec.pdAddresses 字段中指定待迁移 TiDB 集群的 PD 节点地址（以 http:// 开头）

spec ... pdAddresses: - http://pd1_addr:port - http://pd2_addr:port - http://pd3_addr:port ### 具体配置如下，仅供参： apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: tidb-test namespace: lqbyz spec: version: "v6.5.0" timezone: Asia/Shanghai hostNetwork:true imagePullPolicy: IfNotPresent enableDynamicConfiguration: true configUpdateStrategy: RollingUpdate pdAddresses: - http://172.16.5.xxx:2379 - http://172.16.5.xxx:2379 - http://172.16.6.xxx:2379 pd: baseImage: pingcap/pd requests: cpu:"100m" memory: "400Mi" storage: 12Gi limits: cpu: "2000m" memory: "4Gi" config: | [dashboard] internal-proxy = true lease = 3 enable-prevote = true replicas: 3 mountClusterClientSecret: false storageClassName: "local-hostpath"tidb: baseImage: pingcap/tidb maxFailoverCount: 6 replicas: 2 config: {} service: externalTrafficPolicy: Cluster type: NodePort mysqlNodePort: 30082 statusNodePort: 30092 tikv: baseImage: pingcap/tikv replicas: 3requests: cpu:"100m" memory: "400Mi" storage: 50Gi limits: cpu: "2000m" memory: "4Gi" maxFailoverCount: 6 mountClusterClientSecret: false storageClassName: "local-hostpath" config: {} enablePVReclaim: false pvReclaimPolicy: Delete tlsCluster: {}

通过apply应用改配置，确认部署在 Kubernetes 内的 TiDB 集群与待迁移物理机 TiDB 集群组成的新集群是否正常运行。

在dashboar上可以查看所有组件信息

第三步：逐步缩容待迁移物理机集群各服务组件

缩容待迁移的集群物理机的 TiDB节点，将TiDB节点缩容至0

如果待迁移集群使用 TiUP 部署，参考缩容 TiDB/PD/TiKV 节点一节。

如果待迁移集群使用 TiDB Ansible 部署，参考缩容 TiDB 节点一节。

若通过负载均衡或数据库访问层中间件的方式接入待迁移 TiDB集群，则先修改配置，将业务流量迁移至目标 TiDB 集群，避免影响业务。

缩容待迁移集群物理机的 TiKV 节点，将TiKV节点缩容至0

如果待迁移集群使用 TiUP 部署，参考缩容 TiDB/PD/TiKV 节点一节。

如果待迁移集群使用 TiDB Ansible 部署，参考缩容 TiKV 节点一节。

依次缩容待迁移集群的 TiKV 节点，等待上一个 TiKV 节点对应的 store 状态变为 "tombstone" 后，再执行下一个 TiKV 节点的缩容操作。

可通过 PD Control 工具查看 store 状态

缩容待迁移集群 PD 节点，将TiKV节点缩容至0

如果待迁移集群使用 TiUP 部署，参考缩容 TiDB/PD/TiKV 节点一节。

如果待迁移集群使用 TiDB Ansible 部署，参考缩容 PD 节点一节。

第四部：删除容器环境下spec.pdAddresses字段

为避免后续对集群进行操作时产生困惑，迁移成功后，建议将新集群的 manifest 中的 spec.pdAddresses 字段删除。

总结

本文介绍通过Tiup部署管理的TiDB集群在不借助备份恢复工具通过和K8S网络打通将TiDB数据库迁移到通过tidb Operator管理的K8S环境中，从而实现由物理机迁移到K8S环境的目的,也可实现物理机和容器共同管理TiDB集群，最后通过缩容物理机实现tidb集群不需要中间工具就可以迁移到容器环境中。