为kubernetes

Question

我们有一个进程，它接受一个输入 - 目录位置（NFS共享路径）。进程读取，执行一些处理并写入它。

由于内容的性质，目录和进程权限的设置方式使得进程只能访问该目录而不能访问其他目录。这个过程是短暂的（约1分钟），每天可能有成千上万的调用 - 每次都在不同的目录上。

尝试将此工作负载移至docker / kubernetes环境。我想到的一种方式是

1. 为目录
创建PersistentVolume
2. 创建PersistentVolumeClaim并将其绑定
3. 将上述PVC安装到作业的pod规范
4. 作业完成后，删除PV，PVC和作业

只是看看这些步骤，我认为它可能是过度杀伤或大量开销（在k8s中创建大量对象，在主机上为每个作业安装/卸载底层卷）。

还有其他想法吗？

Answer 1

  

还有其他想法吗？

如果我的设置正确，有几种方法，每种方法都有自己的优点和缺点。我会尝试列出一些想法：

• 如您所述，您可以每次创建所有资源（PV，PVC ......）。现在，我不会担心k8s中的“很多对象”，但这种方法会带来很大的开销和执行时间损失。如果你的过程确实是1-2秒，那么绑定，启动和拆除可能会引入所述开销。 Pro是更好的隔离和并发性，并且引入了开销。

• 另一种方法可能是制作如下目录结构：

  /root_of_raw_data
      |
      +-- /process_folder_1
      |
      +-- /process_folder_2
      |
     ...
      |
      +-- /process_folder_n
  

  然后使PV和PVC仅指向/root_of_raw_data，假设您的配置器允许ReadWriteMany（并且NFS配置器应该允许）。然后你就不需要时间来设置/拆卸PV / PVC（它们会不断被绑定），并且在每个pod开始时你都会使用subPath将它挂载到/process_folder_x（其中x与那个相同）过程）在该窗格中说出/my_process_work_folder，然后使用/my_process_work_folder开始处理。 Pro是你不必为PV / PVC边界引入开销，而且你仍然有开始/拆卸开销的开销。

• 另一种方法可能是拥有与上面相同的目录结构，但不是使用subPath将进程文件夹单独挂载到pod，而是实际将/root_of_raw_data文件夹挂载到，例如{ {1}}在广告连播中。然后，您将开始使用/my_root_work_folder进行处理（再次x绑定到相关进程）。这样你就可以让pod一直运行（或者如果需要可以使用多个pod，再次提供可以用于PV的ReadWriteMany）而不是简单地调用/my_root_work_folder/process_folder_x来启动/拆除pod。 Pro是你根本没有任何开始/停止的开销，而且你的pod经常运行并且它们都共享相同的进程根文件夹。

如果你需要pods日志，你也可以使用作业对所提到的方法进行变化，或者，你可以围绕pod使用等制作调度程序......这个答案主要是为了给你一些关于消除潜在开销的其他角度设置/拆卸，并不是详尽无遗的方法列表。