title: 在 AWS EKS 上部署 TiDB 集群

category: how-to

1.2.3.1.1 在 AWS EKS 上部署 TiDB 集群

本节介绍如何使用个人电脑(Linux 或 macOS 系统)在 AWS EKS (Elastic Kubernetes Service) 上部署 TiDB 集群。

1. 环境配置准备

部署前,请确认已安装以下软件并完成配置:

  • awscli >= 1.16.73,控制 AWS 资源

    要与 AWS 交互,必须配置 awscli。最快的方式是使用 aws configure 命令:

    1. aws configure

    替换下面的 AWS Access Key ID 和 AWS Secret Access Key:

    1. AWS Access Key ID [None]: IOSFODNN7EXAMPLE
    2. AWS Secret Access Key [None]: wJaXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
    3. Default region name [None]: us-west-2
    4. Default output format [None]: json

    注意:

    Access key 必须至少具有以下权限:创建 VPC、创建 EBS、创建 EC2 和创建 Role。

  • terraform >= 0.12

  • kubectl >= 1.11
  • helm >= 2.11.0 且 < 3.0.0
  • jq
  • aws-iam-authenticator,AWS 权限鉴定工具,确保安装在 PATH 路径下。

    最简单的安装方法是下载编译好的二进制文件 aws-iam-authenticator,如下所示。

    Linux 用户下载二进制文件:

    1. curl -o aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/1.12.7/2019-03-27/bin/linux/amd64/aws-iam-authenticator

    macOS 用户下载二进制文件:

    1. curl -o aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/1.12.7/2019-03-27/bin/darwin/amd64/aws-iam-authenticator

    二进制文件下载完成后,执行以下操作:

    1. chmod +x ./aws-iam-authenticator && \
    2. sudo mv ./aws-iam-authenticator /usr/local/bin/aws-iam-authenticator

2. 部署集群

默认部署会创建一个新的 VPC、一个 t2.micro 实例作为堡垒机,并包含以下 ec2 实例作为工作节点的 EKS 集群:

  • 3 台 m5.xlarge 实例,部署 PD
  • 3 台 c5d.4xlarge 实例,部署 TiKV
  • 2 台 c5.4xlarge 实例,部署 TiDB
  • 1 台 c5.2xlarge 实例,部署监控组件

使用如下命令部署集群。

从 Github 克隆代码并进入指定路径:

  1. git clone --depth=1 https://github.com/pingcap/tidb-operator && \
  2. cd tidb-operator/deploy/aws

使用 terraform 命令初始化并部署集群:

  1. terraform init
  1. terraform apply

注意:

terraform apply 过程中必须输入 “yes” 才能继续。

整个过程可能至少需要 10 分钟。terraform apply 执行成功后,控制台会输出类似如下的信息:

  1. Apply complete! Resources: 67 added0 changed0 destroyed.
  2. Outputs:
  3. bastion_ip = [
  4. "34.219.204.217",
  5. ]
  6. default-cluster_monitor-dns = a82db513ba84511e9af170283460e413-1838961480.us-west-2.elb.amazonaws.com
  7. default-cluster_tidb-dns = a82df6d13a84511e9af170283460e413-d3ce3b9335901d8c.elb.us-west-2.amazonaws.com
  8. eks_endpoint = https://9A9A5ABB8303DDD35C0C2835A1801723.yl4.us-west-2.eks.amazonaws.com
  9. eks_version = 1.12
  10. kubeconfig_filename = credentials/kubeconfig_my-cluster
  11. region = us-west-21

可以通过 terraform output 命令再次获取上面的输出信息。

注意:

1.14 版本以前的 EKS 不支持自动开启 NLB 跨可用区负载均衡,因此默认配置下 会出现各台 TiDB 实例压力不均衡额状况。生产环境下,强烈建议参考 AWS 官方文档手动开启 NLB 的跨可用区负载均衡。

3. 访问数据库

terraform apply 完成后,可先通过 ssh 远程连接到堡垒机,再通过 MySQL client 来访问 TiDB 集群。

所需命令如下(用上面的输出信息替换 <> 部分内容):

  1. ssh -i credentials/<eks_name>.pem centos@<bastion_ip>
  1. mysql -h <default-cluster_tidb-dns> -P 4000 -u root

eks_name 默认为 my-cluster。如果 DNS 名字无法解析,请耐心等待几分钟。

还可以通过 kubectlhelm 命令使用 kubeconfig 文件 credentials/kubeconfig_<eks_name> 和 EKS 集群交互,主要有两种方式,如下所示。

  • 指定 —kubeconfig 参数:

    1. kubectl --kubeconfig credentials/kubeconfig_<eks_name> get po -n <default_cluster_name>
    1. helm --kubeconfig credentials/kubeconfig_<eks_name> ls
  • 或者,设置 KUBECONFIG 环境变量:

    1. export KUBECONFIG=$PWD/credentials/kubeconfig_<eks_name>
    1. kubectl get po -n <default_cluster_name>
    1. helm ls

4. Grafana 监控

可以通过浏览器访问 <monitor-dns>:3000 地址查看 Grafana 监控指标。

Grafana 默认登录信息:

  • 用户名:admin
  • 密码:admin

5. 升级 TiDB 集群

要升级 TiDB 集群,可在 terraform.tfvars 文件中设置 default_cluster_version 变量到更高版本,然后运行 terraform apply

例如,要升级 TiDB 集群到 4.0.1,则修改 default_cluster_versionv4.0.1

  1. default_cluster_version= "v4.0.1"

注意:

升级过程会持续一段时间,可以通过 kubectl --kubeconfig credentials/kubeconfig_<eks_name> get po -n <default_cluster_name> --watch 命令持续观察升级进度。

6. 扩容 TiDB 集群

若要扩容 TiDB 集群,可在 terraform.tfvars 文件中设置 default_cluster_tikv_count 或者 default_cluster_tidb_count 变量,然后运行 terraform apply

例如,可以将 default_cluster_tidb_count 从 2 改为 4 以扩容 TiDB:

  1. default_cluster_tidb_count = 4

注意:

  • 由于缩容过程中无法确定会缩掉哪个节点,目前还不支持 TiDB 集群的缩容。
  • 扩容过程会持续几分钟,可以通过 kubectl --kubeconfig credentials/kubeconfig_<eks_name> get po -n <default_cluster_name> --watch 命令持续观察进度。

7. 自定义

可以按需在 terraform.tfvars 文件中设置各个变量,例如集群名称和镜像版本等。

自定义 AWS 相关的资源

由于 TiDB 服务通过 Internal Elastic Load Balancer 暴露,默认情况下,会创建一个 Amazon EC2 实例作为堡垒机,访问创建的 TiDB 集群。堡垒机上预装了 MySQL 和 Sysbench,所以可以通过 SSH 方式登陆到堡垒机后通过 ELB 访问 TiDB。如果的 VPC 中已经有了类似的 EC2 实例,可以通过设置 create_bastionfalse 禁掉堡垒机的创建。

TiDB 版本和组件数量也可以在 terraform.tfvars 中修改,可以按照自己的需求配置。

自定义 TiDB 参数配置

Terraform 脚本中为运行在 EKS 上的 TiDB 集群提供了合理的默认配置。有自定义需求时,可以在 clusters.tf 中通过 override_values 参数为每个 TiDB 集群指定一个 values.yaml 文件来自定义集群参数配置。

作为例子,默认集群使用了 ./default-cluster.yaml 作为 values.yaml 配置文件,并在配置中打开了”配置文件滚动更新”特性。

值得注意的是,在 EKS 上部分配置项无法在 values.yaml 中进行修改,包括集群版本、副本数、NodeSelector 以及 TolerationsNodeSelectorTolerations 由 Terraform 直接管理以确保基础设施与 TiDB 集群之间的一致性。集群版本和副本数可以通过 cluster.tf 文件中的 tidb-cluster module 参数来修改。

注意:

自定义 values.yaml 配置文件中,不建议包含如下配置(tidb-cluster module 默认固定配置):

  1. pd:
  2. storageClassName: ebs-gp2
  3. tikv:
  4. stroageClassName: local-storage
  5. tidb:
  6. service:
  7. type: LoadBalancer
  8. annotations:
  9. service.beta.kubernetes.io/aws-load-balancer-internal: '0.0.0.0/0'
  10. service.beta.kubernetes.io/aws-load-balancer-type: nlb
  11. service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: >'true'
  12. separateSlowLog: true
  13. monitor:
  14. storage: 100Gi
  15. storageClassName: ebs-gp2
  16. persistent: true
  17. grafana:
  18. config:
  19. GF_AUTH_ANONYMOUS_ENABLED: "true"
  20. service:
  21. type: LoadBalancer

自定义 TiDB Operator

可以通过在 terraform.tfvars 中设置 operator_values 参数传入自定义的 values.yaml 内容来配置 TiDB Operator。示例如下:

  1. operator_values = "./operator_values.yaml"
  2. }

8. 管理多个 TiDB 集群

一个 tidb-cluster 模块的实例对应一个 TiDB 集群,可以通过编辑 clusters.tf 添加新的 tidb-cluster 模块实例来新增 TiDB 集群,示例如下:

  1. module example-cluster {
  2. source = "../modules/aws/tidb-cluster"
  3. # The target EKS, required
  4. eks = local.eks
  5. # The subnets of node pools of this TiDB cluster, required
  6. subnets = local.subnets
  7. # TiDB cluster name, required
  8. cluster_name = "example-cluster"
  9. # Helm values file
  10. override_values = file("example-cluster.yaml")
  11. # TiDB cluster version
  12. cluster_version = "v3.0.0"
  13. # SSH key of cluster nodes
  14. ssh_key_name = module.key-pair.key_name
  15. # PD replica number
  16. pd_count = 3
  17. # TiKV instance type
  18. pd_instance_type = "t2.xlarge"
  19. # TiKV replica number
  20. tikv_count = 3
  21. # TiKV instance type
  22. tikv_instance_type = "t2.xlarge"
  23. # The storage class used by TiKV, if the TiKV instance type do not have local SSD, you should change it to storage class
  24. # TiDB replica number
  25. tidb_count = 2
  26. # TiDB instance type
  27. tidb_instance_type = "t2.xlarge"
  28. # Monitor instance type
  29. monitor_instance_type = "t2.xlarge"
  30. # The version of tidb-cluster helm chart
  31. tidb_cluster_chart_version = "v1.0.0"
  32. # Decides whether or not to create the tidb-cluster helm release.
  33. # If this variable is set to false, you have to
  34. # install the helm release manually
  35. create_tidb_cluster_release = true
  36. }

注意:

cluster_name 必须是唯一的。

可以通过 kubectl 获取新集群的监控系统地址与 TiDB 地址。假如希望让 Terraform 脚本输出这些地址,可以通过在 outputs.tf 中增加相关的输出项实现:

  1. output "example-cluster_tidb-hostname" {
  2. value = module.example-cluster.tidb_hostname
  3. }
  4. output "example-cluster_monitor-hostname" {
  5. value = module.example-cluster.monitor_hostname
  6. }

修改完成后,执行 terraform initterraform apply 创建集群。

最后,只要移除 tidb-cluster 模块调用,对应的 TiDB 集群就会被销毁,EC2 资源也会随之释放。

9. 仅管理基础设施

通过调整配置,可以控制 Terraform 脚本只创建 Kubernetes 集群和 TiDB Operator。操作步骤如下:

  • 修改 clusters.tf 中 TiDB 集群的 create_tidb_cluster_release 配置项:

    1. module "default-cluster" {
    2. ...
    3. create_tidb_cluster_release = false
    4. }

    如上所示,当 create_tidb_cluster_release 设置为 false 时,Terraform 脚本不会创建和修改 TiDB 集群,但仍会创建 TiDB 集群所需的计算和存储资源。此时,可以使用 Helm 等工具来独立管理集群。

注意:

在已经部署的集群上将 create_tidb_cluster_release 调整为 false 会导致已安装的 TiDB 集群被删除,对应的 TiDB 集群对象也会随之被删除。

10. 销毁集群

可以通过如下命令销毁集群:

  1. terraform destroy

注意:

  • 该操作会销毁 EKS 集群以及部署在该 EKS 集群上的所有 TiDB 集群。
  • 如果不再需要存储卷中的数据,在执行 terraform destroy 后,需要在 AWS 控制台手动删除 EBS 卷。

11. 管理多个 Kubernetes 集群

本节详细介绍了如何管理多个 Kubernetes 集群(EKS),并在每个集群上部署一个或更多 TiDB 集群。

上述文档中介绍的 Terraform 脚本组合了多个 Terraform 模块:

  • tidb-operator 模块,用于创建 EKS 集群并在 EKS 集群上安装配置 TiDB Operator
  • tidb-cluster 模块,用于创建 TiDB 集群所需的资源池并部署 TiDB 集群。
  • EKS 上的 TiDB 集群专用的 vpc 模块、key-pair模块和bastion 模块

管理多个 Kubernetes 集群的最佳实践是为每个 Kubernetes 集群创建一个单独的目录,并在新目录中自行组合上述 Terraform 模块。这种方式能够保证多个集群间的 Terraform 状态不会互相影响,也便于自由定制和扩展。下面是一个例子:

  1. mkdir -p deploy/aws-staging
  2. vim deploy/aws-staging/main.tf

deploy/aws-staging/main.tf 的内容可以是:

  1. provider "aws" {
  2. region = "us-west-1"
  3. }
  4. # 创建一个 ssh key,用于登录堡垒机和 Kubernetes 节点
  5. module "key-pair" {
  6. source = "../modules/aws/key-pair"
  7. name = "another-eks-cluster"
  8. path = "${path.cwd}/credentials/"
  9. }
  10. # 创建一个新的 VPC
  11. module "vpc" {
  12. source = "../modules/aws/vpc"
  13. vpc_name = "another-eks-cluster"
  14. }
  15. # 在上面的 VPC 中创建一个 EKS 并部署 tidb-operator
  16. module "tidb-operator" {
  17. source = "../modules/aws/tidb-operator"
  18. eks_name = "another-eks-cluster"
  19. config_output_path = "credentials/"
  20. subnets = module.vpc.private_subnets
  21. vpc_id = module.vpc.vpc_id
  22. ssh_key_name = module.key-pair.key_name
  23. }
  24. # 特殊处理,确保 helm 操作在 EKS 创建完毕后进行
  25. resource "local_file" "kubeconfig" {
  26. depends_on = [module.tidb-operator.eks]
  27. sensitive_content = module.tidb-operator.eks.kubeconfig
  28. filename = module.tidb-operator.eks.kubeconfig_filename
  29. }
  30. provider "helm" {
  31. alias = "eks"
  32. insecure = true
  33. install_tiller = false
  34. kubernetes {
  35. config_path = local_file.kubeconfig.filename
  36. }
  37. }
  38. # 在上面的 EKS 集群上创建一个 TiDB 集群
  39. module "tidb-cluster-a" {
  40. source = "../modules/aws/tidb-cluster"
  41. providers = {
  42. helm = "helm.eks"
  43. }
  44. cluster_name = "tidb-cluster-a"
  45. eks = module.tidb-operator.eks
  46. ssh_key_name = module.key-pair.key_name
  47. subnets = module.vpc.private_subnets
  48. }
  49. # 在上面的 EKS 集群上创建另一个 TiDB 集群
  50. module "tidb-cluster-b" {
  51. source = "../modules/aws/tidb-cluster"
  52. providers = {
  53. helm = "helm.eks"
  54. }
  55. cluster_name = "tidb-cluster-b"
  56. eks = module.tidb-operator.eks
  57. ssh_key_name = module.key-pair.key_name
  58. subnets = module.vpc.private_subnets
  59. }
  60. # 创建一台堡垒机
  61. module "bastion" {
  62. source = "../modules/aws/bastion"
  63. bastion_name = "another-eks-cluster-bastion"
  64. key_name = module.key-pair.key_name
  65. public_subnets = module.vpc.public_subnets
  66. vpc_id = module.vpc.vpc_id
  67. target_security_group_id = module.tidb-operator.eks.worker_security_group_id
  68. enable_ssh_to_workers = true
  69. }
  70. # 输出 tidb-cluster-a 的 TiDB 服务地址
  71. output "cluster-a_tidb-dns" {
  72. description = "tidb service endpoints"
  73. value = module.tidb-cluster-a.tidb_hostname
  74. }
  75. # 输出 tidb-cluster-b 的监控地址
  76. output "cluster-b_monitor-dns" {
  77. description = "tidb service endpoint"
  78. value = module.tidb-cluster-b.monitor_hostname
  79. }
  80. # 输出堡垒机 IP
  81. output "bastion_ip" {
  82. description = "Bastion IP address"
  83. value = module.bastion.bastion_ip
  84. }

上面的例子很容易进行定制,比如,假如不需要堡垒机,便可以删去对 bastion 模块的调用。同时,项目中提供的 Terraform 模块均设置了合理的默认值,因此在调用这些 Terraform 模块时,可以略去大部分的参数。

可以参考默认的 Terraform 脚本来定制每个模块的参数,也可以参考每个模块的 variables.tf 文件来了解所有可配置的参数。

另外,这些 Terraform 模块可以很容易地集成到自己的 Terraform 工作流中。假如对 Terraform 非常熟悉,这也是我们推荐的一种使用方式。

注意:

  • 由于 Terraform 本身的限制(hashicorp/terraform#2430),在自己的 Terraform 脚本中,也需要保留上述例子中对 helm provider 的特殊处理。
  • 创建新目录时,需要注意与 Terraform 模块之间的相对路径,这会影响调用模块时的 source 参数。
  • 假如想在 tidb-operator 项目之外使用这些模块,需要确保 modules 目录中的所有模块的相对路径保持不变。

假如不想自己写 Terraform 代码,也可以直接拷贝 deploy/aws 目录来创建新的 Kubernetes 集群。但要注意不能拷贝已经运行过 terraform apply 的目录(已经有 Terraform 的本地状态)。这种情况下,推荐在拷贝前克隆一个新的仓库。