我们上一章介绍了Docker基本情况,目前在规模较大的容器集群基本都是Kubernetes,但是Kubernetes涉及的东西和概念确实是太多了,而且随着版本迭代功能在还增加,笔者有些功能也确实没用过,所以只能按照我自己的理解来讲解。
我们前面讲了很多kubernetes资源,但是都没涉及到持久化数据,一般而言
当涉及到持久化存储方式的综合时,以下是常见的持久化存储类型:
主机路径卷(HostPath):将主机文件系统中的目录或文件挂载到容器中。这种方式可以提供容器之间的文件共享,但在集群中迁移时会受到限制。实际就是和Docker的-v
是一样的效果。
#把主机的/data/目录挂载到容器的/data目录
#volumeMount是容器里面
#volumes是宿主机
apiVersion: v1
kind: Pod
metadata:
name: hostpath-pod
spec:
containers:
- name: my-container
image: your-container-image
volumeMounts:
- name: host-path-volume
mountPath: /data
volumes:
- name: host-path-volume
hostPath:
path: /data
type: DirectoryOrCreate
网络存储卷(Network Storage):通过网络协议(例如 NFS、iSCSI)将外部存储系统挂载到容器中。这种方式可以在集群中的多个节点之间共享数据,并提供持久性和可扩展性。
云提供商的存储选项(Cloud Provider Storage Options):大多数云提供商都提供了特定的存储选项,如 Amazon EBS(Elastic Block Store)和 Azure Disk。这些选项可以方便地在云平台上创建和管理持久卷。
容器存储接口(CSI):容器存储接口是一种标准化的插件架构,用于连接容器运行时和各种存储系统。CSI 允许用户在 Kubernetes 中使用多种不同的存储后端,并提供了更大的灵活性和可扩展性。与之相对应的还CNI网络存储接口和CRI容器运行时。
动态卷配置(Dynamic Volume Provisioning):通过存储类(StorageClass)动态创建持久卷的机制。动态卷配置使得在集群中根据需要动态创建和销毁持久卷变得更加容易,而无需手动进行预配和管理。
空目录卷(EmptyDir):将一个空目录挂载到容器中,适用于需要在容器之间共享临时数据的情况,删除或者重建会丢失数据。
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: container-1
image: busybox
command: ["/bin/sh", "-c", "while true; do sleep 3600; done"]
volumeMounts:
- mountPath: /cache
name: cache-volume
- name: container-2
image: busybox
command: ["/bin/sh", "-c", "while true; do sleep 3600; done"]
volumeMounts:
- mountPath: /data
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
PersistentVolume(PV)
在Kubernetes(简称K8s)中,PV是PersistentVolume(持久卷)的缩写。PV是一种抽象概念,它表示集群中的一块存储资源,可以被Pod使用。
PV的创建和管理是由集群管理员来完成的。管理员可以在集群中定义PV的属性,如容量、访问模式(ReadWriteOnce、ReadOnlyMany、ReadWriteMany)和存储类别等。PV可以与具体的存储提供商进行绑定,如本地存储、云存储或网络存储等。
一旦PV被创建并绑定到某个存储提供商,它就可以被动态地分配给Pod进行使用。Pod可以通过声明式的方式(使用PVC,即PersistentVolumeClaim)请求PV资源,并将其挂载到容器中。
总结起来,PV是Kubernetes中的持久存储资源,可以被Pod动态分配和使用。它提供了一种抽象的方式来管理集群中的存储,并与具体的存储提供商进行集成。
在Kubernetes(简称K8s)中,PVC是PersistentVolumeClaim(持久卷声明)的缩写。PVC用于声明对PV(PersistentVolume)的需求,即请求集群中的持久存储资源。
PVC的创建和管理是由应用开发者或管理员来完成的。通过创建PVC,应用可以申请满足其存储需求的PV资源。PVC定义了一些属性,如容量、访问模式和存储类别等。在PVC中,应用可以指定所需的存储资源的大小和访问模式。
一旦PVC被创建,Kubernetes控制器会根据PVC的需求自动匹配和绑定可用的PV资源。当PVC与PV绑定后,应用可以将PVC挂载到Pod中,并在容器内使用该存储资源。
使用PVC可以使应用与底层存储的具体细节解耦,从而提高可移植性和灵活性。应用开发者可以专注于定义所需的存储资源,而不需要关心具体的存储提供商和实现细节。
总结起来,PVC是Kubernetes中用于声明对PV的需求的机制。它使应用能够方便地申请和使用持久存储资源,而不需要关心底层存储的具体实现。
总结
简单来说就是集群的管理员创建了很多PV,然后用业务方来通过PVC来申请这些资源。这个弊端就是必须预先创建PV,如果没有预先创建,或者预先创建的PV被用光,又或者已有的PV无法满足PVC的要求,则无法在申请到资源。对于自动化运维来说,这是不可接受的。所以kubernetes给我们又提供了一个资源对象:StorageClass(后面单独又一小节来介绍),可以实现自动创建匹配用户提出的PVC申请自动创建PV。