写点什么

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

  • 2023-03-17
    北京
  • 本文字数:2401 字

    阅读完需:约 8 分钟

作者: lqbyz 原文来源:https://tidb.net/blog/95f35f0c

前提条件

  • 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.localnameserver <CoreDNS Pod_IP_1>nameserver <CoreDNS Pod_IP_2>nameserver <CoreDNS Pod_IP_n>
vi /etc/resolv.confsearch default.svc.cluster.local svc.cluster.local cluster.local svc.cluster.localnameserver 10.244.0.32nameserver 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/v1alpha1kind: TidbClustermetadata:  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


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

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


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

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

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

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

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

总结

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


##


发布于: 刚刚阅读数: 4
用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
将TiDB各服务组件混布到物理机集群和K8S环境_实践案例_TiDB 社区干货传送门_InfoQ写作社区