使用挂载目录创建 Kubernetes 持久卷答案

【问题标题】：Create Kubernetes Persistent Volume with mounted directory使用挂载目录创建 Kubernetes 持久卷
【发布时间】：2020-11-18 21:09:35
【问题描述】：

在我的/mnt/ 中，我安装了许多硬盘驱动器（例如/mnt/hdd1/、/mnt/hdd2/）。有没有什么办法可以在/mnt上做一个K8s Persistent Volume，可以看到/mnt下挂载的硬盘的内容？当我在 /mnt 上创建本地持久卷时，K8s pod 看到目录 hdd1 和 hdd2，但它们显示为空。

以下是我测试过的：

不需要的解决方案 1：

我可以在/mnt/hdd1 上创建一个本地持久卷，然后我的 K8s pod 将能够看到 hdd1 硬盘驱动器的内容。但正如我之前提到的，我希望我的 pod 可以看到所有硬盘驱动器，并且我不想为每个硬盘驱动器创建一个持久卷，尤其是当我在 /mnt 下安装一个新硬盘驱动器时.

不需要的解决方案 2：

我可以在 yaml 文件中使用 K8s 选项 mountPropagation: HostToContainer 在 /mnt/ 上挂载本地持久卷以用于我的部署。在这种情况下，如果我重新安装硬盘驱动器，我的 pod 将看到硬盘驱动器的内容。但这是不希望的，因为如果 pod 重新启动，我需要重新安装硬盘驱动器才能让 pod 看到它的内容！（仅在 pod 处于活动状态时重新安装硬盘时才有效）

【问题讨论】：

您好。在 Kubernetes 中，土地豆荚被认为是牛。我们尝试设计一些东西，以便 pod 可以任意重启，这没什么大不了的。愚蠢的问题：您是否考虑过忽略 PersistentVolume 的东西，只是将 hostPath 挂载到 pod kubernetes.io/docs/concepts/storage/volumes/#hostpath
将两个硬盘直接安装在Pod 中不是更好吗？本地卷给了你这样的可能性。它不像hostpath，您只能在主机上挂载特定目录。这样可以避免额外的抽象层。这是一个非常有趣的发现，但不幸的是，当/mnt 安装到Pod 时，我无法告诉您是什么机制阻止了hdd1 和hdd2 子目录的内容。但如果它以这种方式工作，可能很难找到令人满意的解决方法。你试过hostpath 吗？效果一样吗？
关于remount，您能详细说明一下吗？
@JustinTamblyn 感谢您的回复。我最初不喜欢主机路径，因为在我当前的配置中，我有部署而不是 pod，并且根据 K8s 参考资料，我不能在部署定义中使用主机路径。我刚刚检查并意识到我实际上可以在 PersistentVolume 下拥有“主机路径”！所以基本上我在我的 PersistentVolume 定义中将“local”重命名为“hostPath”，它可以工作，我现在可以在 pod 中看到硬盘驱动器的内容！我还使用 nodeSelector 来确保我的 pod 只能在安装了硬盘的服务器上运行。
@mario，也感谢您的回复。在找到上一条消息中的解决方案之前，我一直将每个硬盘分别安装到 pod。关键是我有多个硬盘驱动器，我会一直安装和拆卸它们，所以它不仅仅是两个硬盘驱动器单独安装。关于重新挂载，当我选择 mountPropagation:HostToContainer 选项时，它只会将新挂载的硬盘传播到 Pod，并且在 Pod 启动之前挂载的硬盘看起来是空的。

标签： kubernetes persistent-volumes persistent-volume-claims mounted-volumes

【解决方案1】：

我能够让 pod 查看使用主机路径安装在目录中的所有硬盘驱动器。可以在主机路径“模式”中定义 PersistentVolume。我的最终解决方案是：

解决方案中最重要的部分：在主机路径“模式”中定义一个 PersistentVolume， 使用 nodeAffinity 确保它只会安装在具有硬盘驱动器的节点上：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: all-harddrives-pv
spec:
  volumeMode: Filesystem
  storageClassName: all-harddrives-storage
  hostPath:
    path: /mnt      # Where all the hard drives are mounted
    type: Directory
  nodeAffinity:     # Use nodeAffinity to ensure it will only be mounted on the node with harddrives.
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - MyNodeName

定义绑定到上述 PV 的 PersistentVolumeClaim：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: all-harddrives-pvc
spec:
  storageClassName: all-harddrives-storage

将其安装到部署中：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-deployment
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: my-deployment
    spec:
      containers:
        - name: mycontainername
          image: myimage
          volumeMounts:
            - mountPath: /mnt
              name: all-harddrives-pvc
      nodeSelector:
        kubernetes.io/hostname: MyNodeName

【讨论】：

听起来您真正想要的是使用本地持久卷。 kubernetes.io/blog/2019/04/04/… 请记住，在生产中使用这些东西中的任何一个都是一个坏主意。如果将您的 pod 绑定到单个节点，您首先会失去在 Kubernetes 上运行的许多好处。
是的，但是当我有 TB 的数据需要卸载到连接到单个服务器的多个硬盘驱动器时，最好将该 pod 绑定到同一服务器。

【解决方案2】：

Local Persistence Volume Static Provisioner 这种方法更适合 Kubernetes 的工作方式。

它支持指标、存储生命周期（例如清理）、节点/pv 亲和性、可扩展性（例如动态临时存储）。例如，使用eks-nvme-ssd-provisioner，可以运行守护程序集以将快速存储配置为本地。这非常适合需要临时本地存储以进行数据缓存、快速计算的工作负载，同时无需在 pod 启动之前手动在 ec2 节点上执行挂载。

使用 yaml 示例在这里，sig-storage-local-static-provisioner/examples。

【讨论】：