Overview
传统上,容器引擎(Container Engine)不提供比容器寿命更长的存储。由于容器被认为是瞬态(transient)的,这可能会导致数据丢失或复杂的外部存储选项。Kubernetes卷共享 Pod 生命周期,而不是其中的容器。如果容器终止,数据将继续可供新容器使用。
卷(volume)是一个目录,可能是预先填充的,可供 Pod 中的容器(container)使用。目录的创建、数据和内容的后端存储取决于卷类型(volume type)。截至 v1.13,有 27 种不同的卷类型,从用于访问 Ceph 的 rbd、NFS,到来自 Google 的 gcePersistentDisk 等云提供商的动态卷。每个都有特定的配置选项和依赖性。
容器存储接口 (CSI-Container Storage Interface) 的采用实现了容器container orchestration行业标准接口的目标,以允许访问任意存储系统。目前,卷插件是“树内 (in-tree)”的,这意味着它们是使用核心 Kubernetes 二进制文件编译和构建的。这个“树外(out-of-tree)”对象将允许存储供应商开发单个驱动程序并允许插件容器化。这将取代现有的 Flex 插件,后者需要提升对主机节点的访问权限,这是一个很大的安全问题。
如果您希望存储生命周期与 Pod 不同,则可以使用持久卷(Persistent Volumes)。这些允许 Pod 使用持久卷声明(Persistent Volume Claim)来声明空卷或预填充卷,使得这些volume比Pod 的寿命更长。然后,卷内的数据可以被另一个 Pod 使用,或者作为检索数据的一种方式。
已经存在两个 API 对象来向 Pod 提供数据。编码(encoded)数据可以使用 Secret 传递,非编码数据(non-encoded)可以使用 ConfigMap 传递。这些可用于传递重要数据,例如 SSH 密钥、密码,甚至是/etc/hosts等配置文件。
Introducing Volumes
Pod 规范可以声明一个或多个卷以及它们的可用位置。每个都需要名称(name)、类型(type)和安装点(a mount point)。同一卷可以供 Pod 中的多个容器使用,这可以是容器到容器通信的一种方法。一个卷可以供多个 Pod 使用,每个 Pod 都指定一个写入访问模式。没有并发检查,这意味着数据可能损坏,除非在外部进行锁定。
特定的访问模式(access mode)是 Pod 请求的一部分。作为请求,用户可能会被授予更多但不少于的访问权限,尽管首先会尝试直接匹配。集群将具有相同模式的卷分组在一起,然后按大小从最小到最大对卷进行排序。将针对该访问模式组中的每个卷检查声明,直到有足够大小的卷匹配为止。三种访问模式是:
ReadWriteOnce,允许单节点(node)读写
ReadOnlyMany,允许多个节点只读
ReadWriteMany,允许多个节点读写。
因此,同一节点上的两个 pod 可以写入 ReadWriteOnce,但不同节点上的第三个 pod 由于 FailedAttachVolume 错误而不会准备就绪。
当请求卷时,本地 kubelet 使用kubelet_pods.go脚本映射原始设备,确定并创建容器的挂载点,然后在主机节点文件系统上创建符号链接(symbolic link)以将存储与容器关联。API 服务器向StorageClass插件发出存储请求,但对后端存储的请求的具体内容取决于所使用的插件。
如果未发出对特定StorageClass 的请求,则使用的唯一参数将是访问模式和大小。该卷可以来自任何可用的存储类型,并且没有配置来确定将使用哪些可用的存储类型。
Volume Spec
可用的多种存储类型之一是emptyDir。kubelet 将在容器中创建目录,但不会挂载任何存储。创建的任何数据都会写入共享容器空间。因此,它不会是持久存储。当 Pod 被销毁时,该目录将与容器一起被删除。
apiVersion: v1
kind: Pod
metadata:name: fordpinto namespace: default
spec:containers:- image: simpleapp name: gastank command:- sleep- "3600"volumeMounts:- mountPath: /scratchname: scratch-volumevolumes:- name: scratch-volumeemptyDir: {}
上面的 YAML 文件将创建一个带有单个容器的 Pod,并创建一个名为scrap-volume 的卷,这将在容器内创建/scratch目录。
Volume Types (卷类型)
您可以使用多种类型来定义卷,每种类型都有其优点和缺点。有些是本地的,还有许多利用基于网络的资源。
在 GCE 或 AWS 中,您可以使用GCEpersistentDisk或awsElasticBlockStore类型的卷,这允许您在 Pod 中挂载 GCE 和 EBS 磁盘(假设您已经设置了帐户和权限)。
emptyDir和hostPath卷易于使用。如前所述, emptyDir是一个空目录,当 Pod 终止时该目录会被删除,但会在容器重新启动时重新创建。hostPath卷从主机节点文件系统挂载资源。资源可以是目录、文件套接字、字符或块设备。这些资源必须已存在于要使用的主机上。有两种类型: DirectoryOrCreate和FileOrCreate,它们在主机上创建资源,并在资源不存在时使用它们。
NFS(网络文件系统)和 iSCSI(互联网小型计算机系统接口)是多读卡器场景的直接选择。
用于块存储的 rbd 或 CephFS 和 GlusterFS(如果在 Kubernetes 集群中可用)可以是满足多个写入器需求的不错选择。
除了我们刚刚提到的卷类型之外,还有许多其他可能的卷类型,并且还会添加更多:azureDisk、azureFile、csi、downwardAPI、fc(光纤通道)、flocker、gitRepo、local、projected、portworxVolume、quobyte、scaleIO、secret、storageos、vsphereVolume、permanentVolumeClaim、CSIPersistentVolumeSource等
CSI 允许更大的灵活性和解耦插件,而无需编辑核心 Kubernetes 代码。它是作为未来公开任意插件的标准而开发的。
Shared Volume Example (共享卷)
以下 YAML 文件创建一个 pod exampleA,其中包含两个容器,两个容器都可以访问共享卷:
您可以轻松使用emptyDir或hostPath,因为这些类型不需要任何额外的设置,并且可以在您的Kubernetes集群中工作。
请注意,一个容器 ( betacont ) 进行写入,而另一个容器 ( alphacont ) 可以立即访问数据。没有什么可以阻止容器覆盖对方的数据。锁定或版本控制注意事项必须成为容器化应用程序的一部分,以避免损坏。