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

前提条件

• K8S集群外的服务器节点和K8S集群内的Pod网络必须保持互通(本文采用将物理机节点加入K8S集群然后打污点并驱逐该服务器里边的pod的方式来实现)
• K8S机器外的服务器节点必须可以通过添加解析的方式来解析K8S集群内部Pod域名（具体见第一步）
• 待迁移集群没有开启组件间 TLS 加密通信

环境

目前环境主要配置如下：

物理机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: 3
    requests:
      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集群不需要中间工具就可以迁移到容器环境中。