PVCs与多个命名空间

Question

我有一个小Saas应用程序，客户可以注册，他们得到自己的实例与其他客户完全分开。它是一个简单的REST，带有一个DB (postgres)和caddy，它使用一个坞-组合来部署。

这很好，但是需要我创建VPS，部署不同的服务，实际上是很难管理的，因为我大部分的工作都是手动的。

我已经决定使用kubernetes，我已经到了可以为每个客户端创建一个独立的系统实例，完全自动化的地步。这将创建不同的部署、服务和吊舱。另外，我为每个命名空间/客户端创建了一个PVC。

这个问题与持久性卷声明以及它们在命名空间中的工作方式有关。由于我希望将数据与其他实例完全分离，所以我希望为每个客户端创建一个PVC，以便只有来自该客户机的DB才能访问它(以及服务器，因为它需要将一些数据写入磁盘)。

这是很好的迷你库，但问题是托管提供商。我使用DigitalOcean的托管集群，它们不允许创建多个PVCs，因此不可能达到我想要的隔离级别。它们允许您挂载块存储(无论您需要什么大小)，然后使用它。这意味着数据都存储在“同一个磁盘”上，所有名称空间都可以访问它。

我的问题是:是否有一种方法可以达到相同的隔离级别，即为每个DB实例分离挂载点，这样我仍然可以达到(或至少接近)到我所需要的隔离级别？这样做的目的是：

/pvc-root
   /client1
      /server
      /db
   /client2
      /server
      /db
...

这就是我现在拥有的：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: null
  labels:
    io.kompose.service: database-claim
  name: database-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  labels:
    io.kompose.service: database
  name: database
spec:
  ports:
  - name: "5432"
    port: 5432
    targetPort: 5432
  selector:
    io.kompose.service: database
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    io.kompose.service: database
  name: database
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: database
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        io.kompose.service: database
    spec:
      containers:
      - env:
        - name: POSTGRES_DB
          value: db_name
        - name: POSTGRES_PASSWORD
          value: db_password
        - name: POSTGRES_USER
          value: db_user
        image: postgres:10
        imagePullPolicy: ""
        name: postgres
        ports:
        - containerPort: 5432
        resources: {}
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: database-claim
      restartPolicy: Always
      serviceAccountName: ""
      volumes:
      - name: database-claim
        persistentVolumeClaim:
          claimName: database-claim
---
apiVersion: v1
kind: Service
metadata:
  labels:
    io.kompose.service: server
  name: server
spec:
  ports:
  - name: "8080"
    port: 8080
    targetPort: 8080
  selector:
    io.kompose.service: server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    io.kompose.service: server
  name: server
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: server
  template:
    metadata:
      labels:
        io.kompose.service: server
    spec:
      containers:
      - env:
        - name: DB_HOST
          value: database
        - name: DB_NAME
          value: db_name
        - name: DB_PASSWORD
          value: db_password
        - name: DB_PORT
          value: "5432"
        - name: DB_USERNAME
          value: db_user
        image: <REDACTED>
        name: server-image
        ports:
        - containerPort: 8080
      restartPolicy: Always
      volumes: null

编辑2021年2月2日

我一直与DO的客户支持部门保持联系，他们澄清了几件事情：

• 您需要手动将卷附加到集群，因此忽略PVC部署文件。然后将卷挂载并提供给集群，但不能在ReadWriteMany配置中使用，该配置本可以很好地满足这种情况。
• 它们提供了一个API，因此理论上我可以通过编程方式创建卷(针对每个客户端)，然后为特定的客户端附加一个卷，同时保留一个ReadWriteOnce。
• 当然，这会将我锁定为供应商，并使配置和迁移变得更加困难。

我仍在寻找建议，这是否是正确的做法，我的情况。如果你有更好的方法告诉我！

从理论上讲，这应该是可以实现的。

Answer 1

是否有一种方法可以达到相同的隔离级别，即为每个DB实例分离挂载点，这样我仍然可以达到(或至少接近)到我所需要的隔离级别？

不要使用单个卷运行生产数据库。您希望运行具有某种复制形式的数据库，以防卷或节点崩溃。

要么在分布式设置中运行数据库，例如使用Kubernetes的脆PostgreSQL，要么使用托管数据库(如DigitalOcean管理数据库 )

在这个数据库管理系统中，为每个客户创建逻辑数据库或图式 --如果您真的需要这种强大的隔离。提示:使用较少的隔离可能更容易维护，例如在表中使用多租户。

Answer 2

聚会晚了，但是这里有一个解决方案可能对您的用例是个好兆头--如果您还没有找到解决方案。

创建一个高度可用的NFS/CEPH服务器，然后以您的荚可以附加到它的方式导出它。然后根据你的意愿创建PV's和PVC's，并绕过所有的阻塞。

您的应用程序与我所支持的非常类似，我使用了一个高可用的NFS服务器，使用DRBD、Corosync和Pacemaker，所有这些都如预期的那样工作。到目前为止还没有问题。