我的应用程序在google kubernetes引擎上运行,目前使用pvc进行数据存储。我只是无法决定使用PVC或磁盘的哪个存储选项?
对于PVC,我们不能拥有快照,除此之外,我们应该采用基于磁盘的存储。什么是可取的?在哪些情况下我们应该考虑使用磁盘而不是pvc
答案 0 :(得分:3)
您在这里混合了两个不同但已连接的概念。持续交易量和交易量。
永久卷声明不是存储设备/服务。它是需要存储特定特征的声明。在某种程度上,你可以说它相当于异步编程承诺。它应该在某个时刻以“持久卷”的形式“返回”存储,以满足声明的要求。你不知道它究竟会在什么时候(通常是asap)或者它根本不会(错误)。
Persistent Volume又是Volume的一个实例,使用典型的Volume定义(即AWS EBS id,NFS服务器详细信息,GlusterFS等)进行定义和实例化。
Volume是定义某个存储的方式,该存储不是它自己的图像/容器的一部分。
现在,有时您可能会将PVC混淆为PV / Volume,这一事实是,如果云提供商或第三方供应商具有匹配的存储类别(即默认情况下,但不仅仅是),PV可以自动创建。
在大多数情况下,当您需要持久存储为您的pod,但您希望声明与群集无关时,您将使用PVC并依赖于自动配置,或者以对于给定的infra可行的方式创建匹配的PV。例如,您可以通过hostPath
卷在开发群集上支持PVC,但在prod上使用中央GlusterFS
服务器。
也就是说,PVC或磁盘的问题没有关系,因为PVC实际上可能是磁盘。这更像是一个问题,比如“本地存储(hostPart或emptyDir)与网络存储(云块设备,文件服务器等)。”这个问题的答案是......“它取决于”。
如果pod重新安排上的存储数据丢失不是一个问题,可能本地存储是好的和快速的解决方案(即我会考虑它用于缓存存储),如果不是......那么你就不能使用本地存储。但这超出了初始边界的问题。
答案 1 :(得分:0)
在当前实施GKE的方式中,创建PVC时会自动配置永久磁盘。 PVC与磁盘在概念上是不同的,PersistentVolumeClaim表示磁盘上的一个声明,它绑定到PersistentVolume,它将由您的群集自动配置。
以下是使用创建的PVC,PV和间接持久磁盘的PostgreSQL StatefulSet
的示例清单。
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: postgres-claim
spec:
storageClassName: ssd
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Gi
---
kind: Service
apiVersion: v1
metadata:
name: postgres-service
spec:
selector:
app: postgres
ports:
- protocol: TCP
port: 5432
---
apiVersion: apps/v1beta2
kind: StatefulSet
metadata:
name: postgres-set
spec:
serviceName: postgres-service
replicas: 1
selector:
matchLabels:
app: postgres
updateStrategy:
type: RollingUpdate
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:10.1-alpine
volumeMounts:
- name: pg-data
mountPath: /var/lib/postgresql/data
env:
- name: POSTGRES_USER
value: wollner
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
volumes:
- name: pg-data
persistentVolumeClaim:
claimName: postgres-claim
只要应用此清单,就会在群集中创建新的PVC和PV。之后,集群会提供一个支持PV的新永久磁盘。您将能够看到新{PV}出现的kubectl get pv
。您还会在gcloud compute instances disks list
中看到新磁盘。默认情况下,如果删除此PVC,则也会删除该磁盘。