利用Kubernetes实现容器的持久化存储
|
绑定——创建PVC时，它具有特定的存储空间和特定的访问模式。当有一个匹配的PV可用时，无论PVC需要多长时间，它都将只与请求的PVC绑定。如果匹配的PV不存在，则PVC将无限期地保持松散状态。在动态供应PV的情况下，控制循环会始终把PV绑定到请求的PVC。否则，PVC至少会得到它们要求的存储空间，但是卷可能会比要求更多。 使用——一旦PVC认领了PV，它就可以作为一个安装体在封闭的Pod中使用。用户可以为附加卷指定特定的模式(例如ReadWriteOnce、ReadOnlymany等)以及其他挂载的存储选项。只要用户需要，就可以使用安装好的PV。 回收——当一个用户完成了对存储的使用后，他需要决定如何处理正在释放的PV。在决定回收策略时，有三个选项：保留(retain)、删除(delete)和循环利用(recycle)。 ·保留PV只需要释放PV，而不需要修改或删除任何包含的数据，并允许相同的PVC在稍后手动回收此PV。 ·删除PV将完全删除PV以及底层存储资源。 ·循环利用PV将从存储资源中删除数据，并使PV可用于任何其他PVC的请求。 下面是一个持久卷(使用静态供应)的示例，以及持久卷声明定义。 apiVersion: v1 kind: PersistentVolume metadata: name: mypv spec: storageClassName: mysc capacity: storage: 8Gi accessModes: — ReadWriteOnce persistentVolumeReclaimPolicy: Recycle awsElasticBlockStore: volumeID: <volume-id> # This AWS EBS Volume must already exist. 持久卷 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc spec: storageClassName: mysc accessModes: — ReadWriteOnce resources: requests: storage: 8Gi 持久卷声明 持久卷定义指定存储资源的容量，以及一些其他特定于卷的属性，如回收策略和访问模式。可以使用spec下的storageClassName将PV分类为特定的存储类，PVC可以利用它来指定要声明的特定存储类。上面的持久卷声明定义指定了它试图声明的持久卷的属性，其中一些是存储容量和访问模式。PVC可以通过指定spec下的storageClassName字段请求特定的PV。特定类的PV只能绑定到请求该类的PVC，没有指定类的PV只能绑定到没有请求特定类的PVC。选择器还可以用于指定要声明的PV的特定类型，有关这方面的更多文档可以在这里(https://kubernetes.io/docs/concepts/storage/persistent-volumes/#selector)找到。 下面是利用持久卷声明来请求存储的Pod定义示例: apiVersion: v1 kind: Pod metadata: name: test-pod spec: containers: — name: test-container image: nginx volumeMounts: — mountPath: /data name: myvolume volumes: — name: myvolume persistentVolumeClaim: claimName: mypvc 当将这个Pod定义与前面使用卷的定义进行比较时，我们可以看到它们几乎是相同的。持久卷声明不是直接与存储资源交互，而是用于从Pod抽象存储细节。 关于持久卷和持久卷声明的一些关键结论: *持久卷的生命周期独立于Pod的生命周期。 *持久卷声明将存储供应的细节从Pod的存储消耗中抽象出来。 *与卷类似，持久卷和持久卷声明不直接处理存储资源的供应。 Kubernetes存储类和持久卷声明 Kubernetes存储类和持久卷声明提供了一种在请求时动态提供存储资源的方法，从而消除了集群管理员过度提供/手动提供存储资源以满足需求的必要性。存储类允许集群管理员描述其提供的存储“类”，并在动态创建存储资源和持久卷时利用这些“类”作为模板。可以根据特定的应用程序需求(如所需的服务质量级别和备份策略)定义不同的存储类。 存储类定义围绕三个特定区域: ·回收(Reclaim )策略 ·供应程序(Provisioner) ·参数(Parameter) Reclaim ——如果持久卷是由存储类创建的，那么只有Retain或Delete作为回收策略可用，而手动创建的、由存储类管理的持久卷在创建时将保留其分配的回收策略。 Provisioner——存储类提供者负责决定在提供PV时需要使用哪个卷插件(例如AWS EBS的AWSElasticBlockStore或Portworx volume的PortworxVolume)。Provisioner字段不仅限于内部可用的Provisioner类型列表，任何遵循明确定义的规范的独立外部供应程序都可以用来创建新的持久卷类型。 Parameter——定义存储类的最后、也可以说最重要的一部分是参数部分。不同的提供程序可以使用不同的参数，这些参数用于描述特定“类”存储的规范。 下面是持久卷声明和存储类定义： apiVersion: v1 kind: StorageClass metadata: name: myscz provisioner: kubernetes.io/aws-ebs parameters: type: io1 iopsPerGB: “10” fsType: ext4 持久卷声明 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc spec: storageClassName: mysc accessModes: — ReadWriteOnce resources: requests: storage: 8Gi 存储类 如果我们将PVC定义与上面静态供应用例中使用的定义进行比较，可以看到它们是相同的。 （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |