为什么所有 pods 都可以访问我的主机路径持久卷?

Why is my Host Path Persistent Volume reachable from all pods?

我非常坚持名为 PVPVC 的 Kubernetes 学习步骤。
我在这里要做的是了解如何处理多个 pods.
上的共享读写卷 我在这里的理解是 PVC 不能在 pods 之间共享,除非配置了类似 NFS 的存储 class。
我仍然使用我的 hostPath 存储 Class 我尝试了以下(Docker 桌面3 节点 microK8s 集群) :

  1. PVC 具有动态主机路径配置
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-desktop
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Mi
  1. 部署有 3 个复制 pods 在同一个 PVC 上写。
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
spec:
  replicas: 3
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
        - name: busybox
          image: library/busybox:stable
          command: ["/bin/sh"]
          args:
            ["-c", 'while true; do echo "1: $(hostname)" >> /root/index.html; sleep 2; done;',]
          volumeMounts:
            - mountPath: /root
              name: vol-desktop
      volumes:
        - name: vol-desktop
          persistentVolumeClaim:
            claimName: pvc-desktop
  1. 用于服务卷内容的 Nginx 服务器
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          volumeMounts:
            - mountPath: /usr/share/nginx/html
              name: vol-desktop
          ports:
            - containerPort: 80
      volumes:
        - name: vol-desktop
          persistentVolumeClaim:
            claimName: pvc-desktop

根据我在文档中的理解,这是不可能的,但实际上一切 运行 都非常顺利,我的 Nginx 服务器显示了最新的 index.html 文件。
居然在单节点集群和多节点集群上运行。

我没有得到什么?为什么这个东西有效?
每个 Pod 安装在启动时都是自己的主机路径卷吗?
hostPath 存储如何在多个节点之间工作?

编辑:对于多节点情况,在每台机器的相同存储路径之间创建了一个网络文件夹,这就是所有内容都已成功复制的原因。我不明白在每个安装了 PVC 的节点上创建了相同的主机路径。
对于有同样问题的任何人:安装此主机路径 PVC 的每个节点都将在 PV 路径中创建自己的文件夹。
因此,如果节点之间没有网络复制,只有同一节点的 pods 会共享同一文件夹
这就是为什么由于 pod 在集群上的位置不可预测而在多节点集群上不鼓励使用它。

谢谢!

how to handle shared read-write volume on multiple pods.

重新设计您的应用程序以避免它。安全地管理多个编写器往往很脆弱且困难;您依赖于您的应用程序正确执行诸如文件锁定之类的事情,底层共享文件系统实现正确处理事情,以及系统能够容忍可能发生的任何类型的网络问题。

您给出的示例经常出现在 Docker Compose 设置中:拥有一个混合了后端代码和静态文件的应用程序,然后尝试在 上发布静态文件运行time 通过卷到反向代理。相反,您可以在构建时构建一个复制静态文件的映像 :

FROM nginx
ARG app_version=latest
COPY --from=my/app:${app_version} /app/static /usr/share/nginx/html

让您的 CI 系统构建它并在构建后端映像后立即推送它。生成的图像提供相应的静态文件,但不需要共享卷或卷内容的任何手动管理。

对于其他类型的内容,请考虑将数据存储在数据库中,或使用维护自己的后备存储并可以处理并发注意事项的对象存储服务。然后你的大部分 pods 可以完全无状态,你可以单独管理数据(甚至可以在 Kubernetes 之外)。

How can a hostPath storage works between multiple nodes?

没有。这是给 Kubernetes 的指令,无论 pod 恰好被安排在哪个节点上,将该主机目录挂载到容器中。没有任何目录内容的管理;如果两个 pods 被安排在同一个节点上,他们将共享目录,否则,他们不会;如果您的 pod 的 Deployment 已更新并且 pod 被删除并在其他地方重新创建,则它可能不是同一个节点并且可能没有相同的数据。

除了一些非常具体的例外,您根本不应该使用 hostPath 卷。例外情况是日志收集器 运行 作为 DaemonSets,其中 每个 节点上只有一个 pod,并且您有兴趣获取不同的主机目录内容在每个节点上。

在您的特定设置中,您很幸运能够将数据生产者和消费者置于同一位置,或者您的 MicroK8s 设置有一些问题导致主机目录被共享。它不是一般可靠的存储。