PVC 和多个命名空间

如何解决PVC 和多个命名空间

我有一个客户可以注册的小型 Saas 应用程序，他们将自己的实例与其他客户完全分离。这是一个简单的 REST API，带有使用 docker-compose 部署的数据库 (postgres) 和 caddy。

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

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

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

这在 minikube 中运行良好，但问题在于托管服务提供商。我使用 DigitalOcean 的托管集群，它们不允许创建多个 PVC，因此无法达到我想要的隔离级别。它们允许您安装块存储（无论您需要什么大小），然后使用它。这意味着数据都存储在“同一个磁盘”上，所有命名空间都可以访问它。

我的问题是：有没有办法实现相同级别的隔离，即分离每个数据库实例的挂载点，这样我仍然可以实现（或至少接近）该级别我需要的分离？这个想法大概是这样的：

/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
这当然会将我作为供应商锁定在他们身上，并使配置和迁移变得更加困难

我仍在寻找建议，这是否适合我的情况。如果您有更好的方法，请告诉我！

理论上应该可以实现

解决方法

有没有办法实现相同级别的隔离，即分离每个数据库实例的挂载点，这样我仍然可以实现（或至少接近）我的隔离级别需要吗？

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

要么在分布式设置中运行数据库，例如使用 Crunchy PostgreSQL for Kubernetes 或使用托管数据库，例如DigitalOcean Managed Database

在该 DBMS 中，为每个客户创建 logical databases 或 schemas - 如果您确实需要这种强隔离。提示：使用较少的隔离可能更容易维护，例如在表中使用多租户。

PVC 和多个命名空间

如何解决PVC 和多个命名空间

解决方法

相关推荐