Kubernetes 上的持久化存储类型配置

TiDB 集群中 PD、TiKV、监控等组件以及 TiDB Binlog 和备份等工具都需要使用将数据持久化的存储。Kubernetes 上的数据持久化需要使用 PersistentVolume (PV)。Kubernetes 提供多种存储类型,主要分为两大类:

  • 网络存储

    存储介质不在当前节点,而是通过网络方式挂载到当前节点。一般有多副本冗余提供高可用保证,在节点出现故障时,对应网络存储可以再挂载到其它节点继续使用。

  • 本地存储

    存储介质在当前节点,通常能提供比网络存储更低的延迟,但没有多副本冗余,一旦节点出故障,数据就有可能丢失。如果是 IDC 服务器,节点故障可以一定程度上对数据进行恢复,但公有云上使用本地盘的虚拟机在节点故障后,数据是无法找回的。

PV 一般由系统管理员或 volume provisioner 自动创建,PV 与 Pod 是通过 PersistentVolumeClaim (PVC) 进行关联的。普通用户在使用 PV 时并不需要直接创建 PV,而是通过 PVC 来申请使用 PV,对应的 volume provisioner 根据 PVC 创建符合要求的 PV,并将 PVC 与该 PV 进行绑定。

警告:

为了数据安全,任何情况下都不要直接删除 PV,除非对 volume provisioner 原理非常清楚。

TiDB 集群推荐存储类型

TiKV 自身借助 Raft 实现了数据复制,出现节点故障后,PD 会自动进行数据调度补齐缺失的数据副本,同时 TiKV 要求存储有较低的读写延迟,所以生产环境强烈推荐使用本地 SSD 存储。

PD 同样借助 Raft 实现了数据复制,但作为存储集群元信息的数据库,并不是 IO 密集型应用,所以一般本地普通 SAS 盘或网络 SSD 存储(例如 AWS 上 gp2 类型的 EBS 存储卷,GCP 上的持久化 SSD 盘)就可以满足要求。

监控组件以及 TiDB Binlog、备份等工具,由于自身没有做多副本冗余,所以为保证可用性,推荐用网络存储。其中 TiDB Binlog 的 pump 和 drainer 组件属于 IO 密集型应用,需要较低的读写延迟,所以推荐用高性能的网络存储(例如 AWS 上的 io1 类型的 EBS 存储卷,GCP 上的持久化 SSD 盘)。

在利用 TiDB Operator 部署 TiDB 集群或者备份工具的时候,需要持久化存储的组件都可以通过 values.yaml 配置文件中对应的 storageClassName 设置存储类型。不设置时默认都使用 local-storage

网络 PV 配置

Kubernetes 1.11 及以上的版本支持网络 PV 的动态扩容,但用户需要为相应的 StorageClass 开启动态扩容支持。

  1. kubectl patch storageclass ${storage_class} -p '{"allowVolumeExpansion": true}'

开启动态扩容后,通过下面方式对 PV 进行扩容:

  1. 修改 PVC 大小

    假设之前 PVC 大小是 10 Gi,现在需要扩容到 100 Gi

    1. kubectl patch pvc -n ${namespace} ${pvc_name} -p '{"spec": {"resources": {"requests": {"storage": "100Gi"}}}'
  2. 查看 PV 扩容成功

    扩容成功后,通过 kubectl get pvc -n ${namespace} ${pvc_name} 显示的大小仍然是初始大小,但查看 PV 大小会显示已经扩容到预期的大小。

    1. kubectl get pv | grep ${pvc_name}

本地 PV 配置

Kubernetes 当前支持静态分配的本地存储。可使用 local-static-provisioner 项目中的 local-volume-provisioner 程序创建本地存储对象。创建流程如下:

  1. 参考 Kubernetes 提供的操作文档,在集群节点中预分配本地存储。

  2. 部署 local-volume-provisioner 程序。

    1. kubectl apply -f https://raw.githubusercontent.com/pingcap/tidb-operator/master/manifests/local-dind/local-volume-provisioner.yaml

    通过下面命令查看 Pod 和 PV 状态:

    1. kubectl get po -n kube-system -l app=local-volume-provisioner && \
    2. kubectl get pv | grep local-storage

    local-volume-provisioner 会为发现目录 (discovery directory) 下的每一个挂载点创建一个 PV。注意,在 GKE 上,默认只能创建大小为 375 GiB 的本地卷。

更多信息,可参阅 Kubernetes 本地存储local-static-provisioner 文档

最佳实践

  • Local PV 的路径是本地存储卷的唯一标示符。为了保证唯一性并避免冲突,推荐使用设备的 UUID 来生成唯一的路径
  • 如果想要 IO 隔离,建议每个存储卷使用一块物理盘会比较恰当,在硬件层隔离
  • 如果想要容量隔离,建议每个存储卷一个分区或者每个存储卷使用一块物理盘来实现

更多信息,可参阅 local-static-provisioner 的最佳实践文档

示例

如果监控、TiDB Binlog、备份等组件都使用本地盘存储数据,可以挂载普通 SAS 盘,并分别创建不同的 StorageClass 供这些组件使用,具体操作如下:

  • 给监控数据使用的盘,可以参考步骤挂载盘,创建目录,并将新建的目录以 bind mount 方式挂载到 /mnt/disks 目录,后续创建 local-storage StorageClass

    注意:

    该步骤中创建的目录个数取决于规划的 TiDB 集群数量。1 个目录会对应创建 1 个 PV。每个 TiDB 集群的监控数据会使用 1 个 PV。

  • 给 TiDB Binlog 和备份数据使用的盘,可以参考步骤挂载盘,创建目录,并将新建的目录以 bind mount 方式挂载到 /mnt/backup 目录,后续创建 backup-storage StorageClass

    注意:

    该步骤中创建的目录个数取决于规划的 TiDB 集群数量、每个集群内的 Pump 数量及备份方式。1 个目录会对应创建 1 个 PV。每个 Pump 会使用 1 个 PV,每个 drainer 会使用 1 个 PV,每次 Ad-hoc 全量备份会使用 1 个 PV,所有定时全量备份会共用 1 个 PV。

  • 给 PD 数据使用的盘,可以参考步骤挂载盘,创建目录,并将新建的目录以 bind mount 方式挂载到 /mnt/sharedssd 目录,后续创建 shared-ssd-storage StorageClass

    注意:

    该步骤中创建的目录个数取决于规划的 TiDB 集群数量及每个集群内的 PD 数量。1 个目录会对应创建 1 个 PV。每个 PD 会使用一个 PV。

  • 给 TiKV 数据使用的盘,可通过普通挂载方式将盘挂载到 /mnt/ssd 目录,后续创建 ssd-storage StorageClass

盘挂载完成后,需要根据上述磁盘挂载情况修改 local-volume-provisioner yaml 文件,配置发现目录并创建必要的 StorageClass。以下是根据上述挂载修改的 yaml 文件示例:

  1. apiVersion: storage.k8s.io/v1
  2. kind: StorageClass
  3. metadata:
  4. name: "local-storage"
  5. provisioner: "kubernetes.io/no-provisioner"
  6. volumeBindingMode: "WaitForFirstConsumer"
  7. ---
  8. apiVersion: storage.k8s.io/v1
  9. kind: StorageClass
  10. metadata:
  11. name: "ssd-storage"
  12. provisioner: "kubernetes.io/no-provisioner"
  13. volumeBindingMode: "WaitForFirstConsumer"
  14. ---
  15. apiVersion: storage.k8s.io/v1
  16. kind: StorageClass
  17. metadata:
  18. name: "shared-ssd-storage"
  19. provisioner: "kubernetes.io/no-provisioner"
  20. volumeBindingMode: "WaitForFirstConsumer"
  21. ---
  22. apiVersion: storage.k8s.io/v1
  23. kind: StorageClass
  24. metadata:
  25. name: "backup-storage"
  26. provisioner: "kubernetes.io/no-provisioner"
  27. volumeBindingMode: "WaitForFirstConsumer"
  28. ---
  29. apiVersion: v1
  30. kind: ConfigMap
  31. metadata:
  32. name: local-provisioner-config
  33. namespace: kube-system
  34. data:
  35. nodeLabelsForPV: |
  36. - kubernetes.io/hostname
  37. storageClassMap: |
  38. shared-ssd-storage:
  39. hostDir: /mnt/sharedssd
  40. mountDir: /mnt/sharedssd
  41. ssd-storage:
  42. hostDir: /mnt/ssd
  43. mountDir: /mnt/ssd
  44. local-storage:
  45. hostDir: /mnt/disks
  46. mountDir: /mnt/disks
  47. backup-storage:
  48. hostDir: /mnt/backup
  49. mountDir: /mnt/backup
  50. ---
  51. ......
  52. volumeMounts:
  53. ......
  54. - mountPath: /mnt/ssd
  55. name: local-ssd
  56. mountPropagation: "HostToContainer"
  57. - mountPath: /mnt/sharedssd
  58. name: local-sharedssd
  59. mountPropagation: "HostToContainer"
  60. - mountPath: /mnt/disks
  61. name: local-disks
  62. mountPropagation: "HostToContainer"
  63. - mountPath: /mnt/backup
  64. name: local-backup
  65. mountPropagation: "HostToContainer"
  66. volumes:
  67. ......
  68. - name: local-ssd
  69. hostPath:
  70. path: /mnt/ssd
  71. - name: local-sharedssd
  72. hostPath:
  73. path: /mnt/sharedssd
  74. - name: local-disks
  75. hostPath:
  76. path: /mnt/disks
  77. - name: local-backup
  78. hostPath:
  79. path: /mnt/backup
  80. ......

最后通过 kubectl apply 命令部署 local-volume-provisioner 程序。

  1. kubectl apply -f https://raw.githubusercontent.com/pingcap/tidb-operator/master/manifests/local-dind/local-volume-provisioner.yaml

后续创建 TiDB 集群或备份等组件的时候,再配置相应的 StorageClass 供其使用。

数据安全

一般情况下 PVC 在使用完删除后,与其绑定的 PV 会被 provisioner 清理回收再放入资源池中被调度使用。为避免数据意外丢失,可在全局配置 StorageClass 的回收策略 (reclaim policy) 为 Retain 或者只将某个 PV 的回收策略修改为 RetainRetain 模式下,PV 不会自动被回收。

  • 全局配置

    StorageClass 的回收策略一旦创建就不能再修改,所以只能在创建时进行设置。如果创建时没有设置,可以再创建相同 provisioner 的 StorageClass,例如 GKE 上默认的 pd 类型的 StorageClass 默认保留策略是 Delete,可以再创建一个名为 pd-standard 的保留策略是 Retain 的存储类型,并在创建 TiDB 集群时将相应组件的 storageClassName 修改为 pd-standard

    1. apiVersion: storage.k8s.io/v1
    2. kind: StorageClass
    3. metadata:
    4. name: pd-standard
    5. parameters:
    6. type: pd-standard
    7. provisioner: kubernetes.io/gce-pd
    8. reclaimPolicy: Retain
    9. volumeBindingMode: Immediate
  • 配置单个 PV

    1. kubectl patch pv ${pv_name} -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

注意:

TiDB Operator 默认会自动将 PD 和 TiKV 的 PV 保留策略修改为 Retain 以确保数据安全。

PV 保留策略是 Retain 时,如果确认某个 PV 的数据可以被删除,需要通过下面的操作来删除 PV 以及对应的数据:

  1. 删除 PV 对应的 PVC 对象:

    1. kubectl delete pvc ${pvc_name} --namespace=${namespace}
  2. 设置 PV 的保留策略为 Delete,PV 会被自动删除并回收:

    1. kubectl patch pv ${pv_name} -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'

要了解更多关于 PV 的保留策略可参考修改 PV 保留策略