我的应用程序运行在google kubernetes引擎上,目前使用pvc进行数据存储。我只是不能决定我们应该使用PVC还是磁盘的存储选项?
在PVC的情况下,我们不能有快照,除此之外,还有什么强有力的理由我们应该选择基于磁盘的存储。什么是可取的?在哪些情况下,我们应该考虑使用磁盘而不是pvc
发布于 2018-02-23 00:41:07
您在这里混合了两个不同但又相互关联的概念。持久的卷声明和卷。
永久卷声明不是存储设备/服务。它是对存储特定特征的需求的声明。在某种程度上,你可以说它等同于异步编程promise。它应该在某个时刻以永久卷的形式“返回”存储,以满足声明的要求。你不知道它到底什么时候会(通常是越快越好),也不知道是否会(错误)。
Persistent Volume反过来是Volume的实例,使用典型的Volume定义定义和实例化。AWS EBS id、NFS服务器详细信息、GlusterFS等)。
卷是一种定义某些存储的方式,这些存储不是映像/容器本身的一部分。
现在,有时您可能会将PVC与PV/Volume混淆,这一事实是,如果云提供商或第三方资源调配商具有匹配的存储类别(即,默认,但不仅仅是这样)。
在大多数情况下,当您的pod需要持久存储,但您希望声明与集群无关时,您将使用PVC,并依赖于自动配置,或者以给定基础设施可行的方式创建匹配的PV。例如,您可以通过hostPath卷在开发集群上支持PVC,但在prod上使用中央GlusterFS服务器。
也就是说,问题PVC或磁盘没有相关性,因为PVC实际上可以是磁盘。这更像是一个“本地存储(hostPart或emptyDir)还是网络存储(云块设备、文件服务器等)”的问题。这个问题的答案是……“这取决于”。
如果在pod重新调度时丢失存储的数据不是问题,那么本地存储可能是很好的和快速的解决方案(即,我会考虑它作为缓存存储),如果不是这样的话...那你就不能用本地存储了。但这超出了问题的初始边界。
发布于 2018-02-22 23:36:37
按照目前GKE的实现方式,创建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。
https://stackoverflow.com/questions/48931128
复制相似问题