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. ---
  52. ......
  54.           volumeMounts:
  56.             ......
  58.             - mountPath: /mnt/ssd
  59.               name: local-ssd
  60.               mountPropagation: "HostToContainer"
  61.             - mountPath: /mnt/sharedssd
  62.               name: local-sharedssd
  63.               mountPropagation: "HostToContainer"
  64.             - mountPath: /mnt/disks
  65.               name: local-disks
  66.               mountPropagation: "HostToContainer"
  67.             - mountPath: /mnt/backup
  68.               name: local-backup
  69.               mountPropagation: "HostToContainer"
  70.       volumes:
  72.         ......
  74.         - name: local-ssd
  75.           hostPath:
  76.             path: /mnt/ssd
  77.         - name: local-sharedssd
  78.           hostPath:
  79.             path: /mnt/sharedssd
  80.         - name: local-disks
  81.           hostPath:
  82.             path: /mnt/disks
  83.         - name: local-backup
  84.           hostPath:
  85.             path: /mnt/backup
  86. ......

最后通过 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 的回收策略修改为 Retain。Retain 模式下，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 保留策略。