我试图在我们的k8s集群上安装一个cassandra状态集。我们想在所有的Cassandra吊舱上安装一个aws efs。在配置卷的过程中,我发现有两种方法可以声明卷。
创建一个efs,在集群上安装efs provisioner(persistentvolume provisioner插件),创建一个 PersistentVolume
使用efs provisioner,并使用 volumeClaimTemplates
(我认为它实际上意味着persistentvolumeclaimtemplates,我不知道为什么它们忽略了persistent前缀)在pod模板中。这样地:
apiVersion: v1
kind: Pod
metadata:
name: hello-openshift-nfs-pod
labels:
name: hello-openshift-nfs-pod
spec:
containers:
- name: hello-openshift-nfs-pod
image: openshift/hello-openshift
ports:
- name: web
containerPort: 80
volumeMounts:
- name: nfsvol
mountPath: /usr/share/nginx/html
securityContext:
supplementalGroups: [100003]
privileged: false
volumes:
- name: nfsvol
persistentVolumeClaim:
claimName: nfs-pvc
(文章中的代码)
或者我可以将efs直接安装到我的Cassandra吊舱上:
apiVersion: v1
kind: Pod
metadata:
name: hello-openshift-nfs-pod
labels:
name: hello-openshift-nfs-pod
spec:
containers:
- name: hello-openshift-nfs-pod
image: openshift/hello-openshift
ports:
- name: web
containerPort: 80
volumeMounts:
- name: nfsvol
mountPath: /usr/share/nginx/html
securityContext:
supplementalGroups: [100003]
privileged: false
volumes:
- name: cassandra-shared-volume
nfs:
server: <EFS file system endpoint url>
path: "/cassandra/shared"
所以对我来说,方法1就像将nfs(在本例中是efs) Package 在persistentvolume中一样。我不知道方法1的主要优点是什么,尽管它几乎是每个团队如何使用nfs的。有一个简短的答案 efs-provisioner
常见问题解答:他们说
我注意到efs被直接装载到efs provisioner容器,我可以为我的应用程序这样做吗?可以,但不推荐。您将失去storageclass的可重用性,无法为新容器和pod动态地提供新的持久卷。
这个答案是好的,但我想知道是否有任何暗示背后 persistentVolume
比 volume
一个人。有 StatefulSet
医生说:
给定pod的存储必须由persistentvolume provisioner根据请求的存储类进行调配,或者由管理员进行预调配。
所以我想知道s的statefulset是否必须有一个存储类型:persistentvolume。主要的冲突是,与块存储不同,efs本身是持久性的,它的动态扩展能力已经由aws处理了,不需要 persistentVolumeProvisioner
创造新的资源。
我想知道方法1有什么主要的优点或者方法2中的缺陷,我必须使用方法1吗?非常感谢!
1条答案
按热度按时间px9o7tmv1#
由于性能问题,一般不建议cassandra使用san和efs等网络文件系统。根据工作流程的不同,您可以使用临时(示例)存储和ebs获得可接受的性能,如下所述。
添加容器层并没有阻止这些问题,目前我们正在进行类似的概念验证设置一个写密集型场景,并且我们已经能够使用i3示例和persistentvolumes定义的临时存储获得一些可接受的性能,但这还不是一个明确的回应,因为我们仍在为我们的目的寻找正确的配置。