我一直在读关于如何在kubernetes上推送数据库的文章。最初,我将数据附加到docker映像并部署 service
以及 deployment
文件夹。但问题是,当容器/吊舱重新启动时,数据会丢失。i、 然后,我们遇到了持久性卷声明的概念。我发现(https://www.magalix.com/blog/kubernetes-and-database)以及(https://kubernetes.io/docs/tutorials/stateful-application/cassandra/)非常有用。不过,我对他们没有什么问题:
聚氯乙烯:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
光伏:
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 20Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
pvc如何从集群中的pv获得存储?如果我使用amazon云运行我的服务,那么相同的步骤是什么(如果有的话)。
2条答案
按热度按时间fdbelqdn1#
pvc将消耗您配置的pv资源。kubernetes文档中对持久卷有更详细的解释,包括卷的生命周期和pv声明。
顺便说一句,如果您还不知道的话,有几个cassandra操作符随时可用,这使得您可以更容易地在kubernetes上部署集群,包括instaclustr的、orange的casskop和datastax的cass操作符。
datastax cass操作符允许您部署dse集群或apache cassandra集群。你可以在这里的官方文档网站上找到更多信息。你也可以直接联系cass操作符的作者https://community.datastax.com if 你有任何问题。干杯!
tvz2xvvm2#
持久卷:
PV
群集中已由管理员或管理员配置的存储dynamically provisioned
使用Storage Classes
. 持久卷声明PVC
是用户对存储的请求。它类似于豆荚。pod消耗节点资源和PVCs
消费PV
资源。如果你想绑起来
PV
以及PVC
您可以在两种配置方式中进行选择:静止的
群集管理员会创建一些
PVs
. 它们包含真实存储的详细信息,可供集群用户使用。它们存在于kubernetes api中,可供使用。动态
当没有静电
PVs
管理员创建的匹配用户的PersistentVolumeClaim
,群集可能会尝试动态地为PVC
. 此资源调配基于StorageClasses:
这个PVC
必须请求storage class
管理员必须已经创建并配置了该类才能进行动态资源调配。请求类“”的声明有效地为自己禁用了动态资源调配。简而言之,如果你正在使用
Static
资源调配,针对每个PVC
你需要创造PV
,因为它们是1:1的边界关系。您可以在此线程中找到更多有用的详细信息。
当您使用支持动态卷配置的云环境(amazon)时,您只需使用
PVC
.Dynamic Provisioning
将创建PV
与PVC
要求。当你使用
Statefulset
你需要确保每个吊舱都有自己的PV
,您可以使用VolumeClaimTemplate
就像文档示例一样。关于主要问题:
pvc如何从集群中的pv获得存储?如果我使用amazon云运行我的服务,那么相同的步骤是什么(如果有的话)。
如果要使用静态资源调配,则需要创建
PV
以及PVC
对于每个吊舱。大多数云提供商都支持
Dynamic Provisioning
你可以创造PVC
云资源调配器将自动创建PV
与PVC
要求。另外,最常见的创作方式PV
以及PVC
对于豆荚statefulset
是用来VolumeClaimTemplate
,其中可以指定storageclass,storage
以及更多其他参数: