目录
- 一、Volume介绍
- 1. Volume的基本概念与特性
- 2. Volume类型及其特性
- a. EmptyDir
- b. HostPath
- c. PersistentVolumeClaim (PVC)
- d. NFS (Network File System)
- e. AWS EBS (Elastic Block Store), GCP PD (Persistent Disk), Azure Disk
- f. CephFS, GlusterFS
- g. LocalVolume
- h. CSI (Container Storage Interface)
- 3. 使用Volume的示例
- 二、PV/PVC介绍
- 1、PersistentVolume (PV)
- 2、PersistentVolumeClaim (PVC)
- 3、 PV与PVC的关系与工作流程
- 4、示例
在Kubernetes中,Volume(卷)是用于持久化存储或共享数据的一种抽象概念,它为Pod内的一个或多个容器提供了一块独立的、生命周期与Pod关联的存储空间。Volumes不仅可以提供持久化存储,确保容器重启或重建时数据的持久性,还能在同一个Pod内的多个容器之间共享数据。Kubernetes支持多种类型的Volume,每种类型对应不同的存储后端和使用场景。
一、Volume介绍
1. Volume的基本概念与特性
-
生命周期:Volume的生命周期与创建它的Pod绑定。当Pod被删除时,与其关联的Volume也会被删除,除非Volume被声明为
persistentVolumeClaim
(PVC)类型,这种情况下,Volume的生命周期由其对应的PersistentVolume(PV)管理。 -
数据持久性:Volume的内容在Pod重启或容器重新启动时保留,即使容器的文件系统被重置,Volume中的数据也不会丢失。
-
容器间共享:同一Pod内的所有容器都可以访问同一Volume,这对于需要共享数据(如日志、配置文件)的多容器应用至关重要。
2. Volume类型及其特性
a. EmptyDir
用途:临时存储空间,用于在Pod的生命周期内保存临时数据。
特性:
- 创建Pod时自动创建,Pod删除时自动清理。
- 存储在Node本地,因此具有较快的访问速度,但数据不跨节点持久化。
- 可以设置介质类型(如
memory
或default
),决定是使用节点的内存还是硬盘作为存储。
b. HostPath
用途:将主机节点上的某个路径挂载到Pod中。
特性:
- 直接访问宿主机的文件系统,适用于测试环境或有特殊需求的场景。
- 不推荐在生产环境中广泛使用,因为这会破坏容器的隔离性和可移植性。
- 宿主机节点故障可能导致数据丢失。
c. PersistentVolumeClaim (PVC)
用途:用户级的存储请求接口,通过声明所需的存储资源(容量、访问模式等),与集群管理员提供的PersistentVolume(PV)动态绑定。
特性:
- PVC与具体的存储后端(如AWS EBS、GCP Persistent Disk、NFS、Ceph等)解耦,提高了灵活性和可移植性。
- 支持多种访问模式:
ReadWriteOnce
(单节点读写)、ReadOnlyMany
(多节点只读)、ReadWriteMany
(多节点读写)。 - 存储资源的生命周期独立于Pod,即使Pod被删除,数据依然保留。
d. NFS (Network File System)
用途:使用网络文件系统(NFS)服务器提供的共享存储。
特性:
- 支持多节点读写访问。
- 适合需要跨多个Pod或节点共享数据的应用。
- 需要预先配置并管理NFS服务器。
e. AWS EBS (Elastic Block Store), GCP PD (Persistent Disk), Azure Disk
用途:云服务商提供的块存储服务,提供高可用、高可靠的数据存储。
特性:
- 与云平台深度集成,易于管理与扩展。
- 提供多种性能等级和加密选项。
- 通常支持多种访问模式。
f. CephFS, GlusterFS
用途:分布式文件系统,提供大规模、高可用的共享存储。
特性:
- 支持多节点读写访问。
- 适用于大规模、高性能、高可用的存储需求。
- 需要预先配置并管理分布式文件系统集群。
g. LocalVolume
用途:利用节点的本地磁盘资源,提供具有性能优势的持久化存储。
特性:
- 数据与节点绑定,不支持跨节点迁移。
- 适用于对性能要求较高且数据不需要在节点间迁移的应用。
h. CSI (Container Storage Interface)
用途:通用存储插件接口,支持第三方存储系统的无缝集成。
特性:
- 允许Kubernetes与各种第三方存储系统(如Portworx, Rook, MinIO等)交互。
- 扩展了Kubernetes对存储类型的支持,使Kubernetes能够适应更广泛的存储需求和环境。
3. 使用Volume的示例
下面是一个使用PersistentVolumeClaim
的示例,创建一个Deployment,其中Pod包含一个容器,并挂载了一个PVC:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: example.com/my-app:v1.0
volumeMounts:
- mountPath: /app/data
name: app-data
volumes:
- name: app-data
persistentVolumeClaim:
claimName: my-pvc
在这个例子中,首先创建了一个名为my-pvc
的PVC,请求1Gi的存储空间。然后,在Deployment中,将这个PVC挂载到容器的/app/data
目录下,供应用程序使用。
二、PV/PVC介绍
PV(PersistentVolume)和PVC(PersistentVolumeClaim)是Kubernetes中用于管理持久化存储的核心组件,它们共同构成了Kubernetes的持久化存储体系。
1、PersistentVolume (PV)
PersistentVolume(持久卷)是一种集群级别的存储资源,它代表了由集群管理员事先配置和提供的某种类型的持久化存储。PV是Kubernetes存储资源的实际提供者,它可以是物理硬件(如磁盘)、网络存储设备(如NAS、SAN),也可以是云服务商提供的块存储(如AWS EBS、GCP Persistent Disk)或其他类型的网络文件系统(如NFS、CephFS)。
PV具有以下几个关键属性:
- Capacity:表示PV的存储容量。
- Access Modes:定义了PV如何被访问,包括
ReadWriteOnce
(单节点读写)、ReadOnlyMany
(多节点只读)、ReadWriteMany
(多节点读写)。 - Storage Class(可选):指定了PV所属的存储类别,用于区分不同性能、成本或特性的存储资源。
- Reclaim Policy:定义了当一个PV不再被使用时,如何处理其存储资源,包括
Retain
(保留数据,需要手动清理)、Recycle
(尝试清除数据,已弃用)和Delete
(删除底层存储资源,仅适用于支持自动删除的云存储)。
2、PersistentVolumeClaim (PVC)
PersistentVolumeClaim(持久卷声明)是由用户(通常是应用程序开发者)创建的请求,用于申请特定容量和访问模式的持久化存储资源。PVC是PV的消费者,它不直接指定使用哪种具体的存储设备或类型,而是通过声明所需存储资源的属性(如容量、访问模式、存储类别),让Kubernetes自动为其匹配合适的PV。
PVC具有以下属性:
- Capacity(请求的存储容量):声明需要多少存储空间。
- Access Modes:声明期望的访问模式,与PV的访问模式匹配。
- Storage Class(可选):如果指定,Kubernetes将仅从该类别的PV中为PVC分配存储资源。
3、 PV与PVC的关系与工作流程
-
供应:集群管理员预先创建PV,定义其容量、访问模式、存储类别等属性,并配置底层存储资源。
-
请求:用户创建PVC,声明所需的存储资源属性。Kubernetes根据PVC的要求,尝试自动匹配一个合适的PV。
-
绑定:当找到匹配的PV后,Kubernetes将PV与PVC进行绑定。此时,PVC的状态变为
Bound
,PV的状态也相应更新,表明其已被分配给特定的PVC。同时,PV的存储资源可供Pod使用。 -
使用:用户在Pod的YAML配置中引用已绑定的PVC,将持久化存储挂载到Pod的指定容器内。Pod运行时,容器内的应用程序可以像操作本地文件系统一样访问这些持久化存储。
-
释放与回收:当Pod被删除时,与之绑定的PVC仍然存在,保持对PV的引用。如果不再需要该存储资源,用户应删除对应的PVC。PVC删除后,根据PV的Reclaim Policy,Kubernetes会执行相应的资源回收操作。
4、示例
下面是一个简单的PV和PVC的配置示例:
# 创建一个1Gi大小、ReadWriteOnce访问模式的PV,使用StorageClass "standard"
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-example
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
storageClassName: standard
# 这里省略具体的存储提供商配置...
---
# 创建一个请求1Gi、ReadWriteOnce访问模式、使用"standard" StorageClass的PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-example
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: standard
在这个示例中,首先创建了一个名为pv-example
的PV,提供了1Gi的存储空间和ReadWriteOnce
访问模式。接着,创建了一个名为pvc-example
的PVC,请求相同的存储资源属性。Kubernetes会自动将这两个资源进行绑定,使得应用程序可以通过引用pvc-example
来使用持久化存储。