在 Kubernetes/OpenShift 中的容器之间共享持久卷声明 [英] Share persistent volume claims amongst containers in Kubernetes/OpenShift

查看:30
本文介绍了在 Kubernetes/OpenShift 中的容器之间共享持久卷声明的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这可能是一个愚蠢的问题,但我在网上没有找到太多,想澄清一下.

This may be a dumb question but I haven't found much online and want to clarify this.

给定两个部署 A 和 B,都具有不同容器镜像:

Given two deployments A and B, both with different container images:

  • 它们部署在 K8/OpenShift 集群中的两个不同 pod(不同的 rc、svc 等)中.
  • 他们都需要访问同一个卷来读取文件(让我们暂时不要锁定它)或至少在该卷中具有相同的目录结构.
  • 使用由针对 NFS 共享配置的 PV(持久卷)支持的 PVC(持久卷声明)安装此卷.

我可以确认上述内容实际上是可能的吗?IE.两个不同 Pod 连接到具有相同 PVC 的同一个卷.所以他们都在阅读同一卷.

Can I confirm that the above would actually be possible? I.e. two different pods connected to the same volume with the same PVC. So they both are reading from the same volume.

希望这是有道理的...

Hope that makes sense...

推荐答案

TL;DR您可以在共享卷(nfs、gluster 等)的同一项目/命名空间中共享 PV 和 PVC,您还可以从多个项目/命名空间访问您的共享卷,但它需要项目专用的 PV 和 PVC,作为PV 绑定到单个项目/命名空间,而 PVC 是项目/命名空间范围的.

TL;DR You can share PV and PVC within the same project/namespace for shared volumes (nfs, gluster, etc...), you can also access your shared volume from multiple project/namespaces but it will require project dedicated PV and PVCs, as a PV is bound to single project/namespace and PVC is project/namespace scoped.

下面我试图说明当前的行为以及 PV 和 PVC 在 OpenShift 中的范围.这些是使用 NFS 作为持久存储层的简单示例.

Below I've tried to illustrate the current behavior and how PV and PVCs are scoped within OpenShift. These are simple examples using NFS as the persistent storage layer.

此时的访问模式只是标签,它们在控制对 PV 的访问方面没有真正的功能.下面是一些例子来说明这一点

the accessModes at this point are just labels, they have no real functionality in terms of controlling access to PV. Below are some examples to show this

PV 是全局的,因为它可以被任何项目/命名空间看到/访问,但是一旦它绑定到一个项目,它就只能被来自同一项目/命名空间的容器访问

the PV is global in the sense that it can be seen/accessed by any project/namespace, HOWEVER once it is bound to a project, it can then only be accessed by containers from the same project/namespace

PVC 是特定于项目/命名空间的(因此,如果您有多个项目,则需要为每个项目创建一个新的 PV 和 PVC 以连接到共享的 NFS 卷 - 不能重用第一个项目的 PV)

the PVC is project/namespace specific (so if you have multple projects you would need to have a new PV and PVC for each project to connect to the shared NFS volume - can not reuse the PV from first project)

示例 1:
我有 2 个不同的 Pod 在默认"项目/命名空间中运行,它们都访问相同的 PV 和 NFS 导出共享.挂载和运行都很好.

Example 1:
I have 2 distinct pods running in "default" project/namespace, both accessing the same PV and NFS exported share. Both mount and run fine.

[root@k8dev nfs_error]# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS    CLAIM  REASON    AGE
pv-nfs    <none>    1Gi        RWO           Bound default/nfs-claim             3m


[root@k8dev nfs_error]# oc get pods    <--- running from DEFAULT project, no issues connecting to PV
NAME              READY     STATUS    RESTARTS   AGE
nfs-bb-pod2-pvc   1/1       Running   0          11m
nfs-bb-pod3-pvc   1/1       Running   0          10m

示例 2:
我有 2 个不同的 pod 在默认"项目/命名空间中运行,并尝试使用相同的 PV 创建另一个 pod,但从名为 testproject 的新项目访问相同的 NFS 导出.新 testproject 中的第三个 pod 将无法绑定到 PV,因为它已经被 default 项目绑定.

Example 2:
I have 2 distinct pods running in "default" project/namespace and attempt to create another pod using the same PV but from a new project called testproject to access the same NFS export. The third pod from the new testproject will not be able to bind to the PV as it is already bound by default project.

[root@k8dev nfs_error]# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS    CLAIM  REASON    AGE
pv-nfs    <none>    1Gi        RWO           Bound default/nfs-claim             3m


[root@k8dev nfs_error]# oc get pods    <--- running from DEFAULT project, no issues connecting to PV
NAME              READY     STATUS    RESTARTS   AGE
nfs-bb-pod2-pvc   1/1       Running   0          11m
nfs-bb-pod3-pvc   1/1       Running   0          10m

** 针对来自另一个项目(testproject)的现有 PV 创建一个新声明,PVC 将失败

** Create a new claim against the existing PV from another project (testproject) and the PVC will fail

[root@k8dev nfs_error]# oc get pvc 
NAME        LABELS    STATUS    VOLUME    CAPACITY   ACCESSMODES   AGE
nfs-claim   <none>    Pending                                      2s

** nfs-claim 永远不会绑定到 pv-nfs PV,因为它无法从当前项目范围中看到它

** nfs-claim will never bind to the pv-nfs PV because it can not see it from it's current project scope

示例 3:

我在默认"项目中运行了 2 个不同的 Pod,然后从 testproject 创建另一个 PV、PVC 和 Pod.两个项目都将能够访问相同的 NFS 导出共享,但我需要在每个项目中都有一个 PV 和 PVC.

I have 2 distinct pods running in the "default" project and then create another PV and PVC and Pod from testproject. Both projects will be able to access the same NFS exported share but I need a PV and PVC in each of the projects.

[root@k8dev nfs_error]# oc get pv
NAME      LABELS    CAPACITY   ACCESSMODES   STATUS     CLAIM                    REASON    AGE
pv-nfs    <none>    1Gi        RWX           Bound     default/nfs-claim                  14m
pv-nfs2   <none>    1Gi        RWX           Bound     testproject/nfs-claim2             9m



[root@k8dev nfs_error]# oc get pods --all-namespaces
NAMESPACE     NAME              READY     STATUS    RESTARTS   AGE
default       nfs-bb-pod2-pvc   1/1       Running   0          11m
default       nfs-bb-pod3-pvc   1/1       Running   0          11m
testproject   nfs-bb-pod4-pvc   1/1       Running   0          15s

** 注意,我现在有三个 Pod 运行到跨两个项目的同一个 NFS 共享卷,但我需要两个 PV,因为它们绑定到单个项目,以及 2 个 PVC,每个项目一个,NFS PV I正在尝试访问

** notice, I now have three pods running to the same NFS shared volume across two projects, but I needed two PV's as they are bound to a single project, and 2 PVC's, one for each project and the NFS PV I am trying to access

示例 4:

如果我绕过 PV 和 PVC,我可以直接使用 nfs 插件直接从任何项目连接到共享 NFS 卷

If I by-pass PV and PVC, I can connect to the shared NFS volumes directly from any project using the nfs plugin directly

volumes:
- name: nfsvol
  nfs:
    path: /opt/data5
    server: nfs1.rhs

现在,卷安全是在此之上的另一层,使用补充组(用于共享存储,即 nfs、gluster 等...),管理员和开发人员应该能够进一步管理和控制对共享 NFS 的访问系统.

Now, the volume security is another layer on top of this, using supplementalGroups (for shared storage, i.e. nfs, gluster, etc...), admins and devs should further be able to manage and control access to the shared NFS system.

希望有帮助

这篇关于在 Kubernetes/OpenShift 中的容器之间共享持久卷声明的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆