在同一个Pod中的多个容器能够共享Pod级别的存储卷Volume。Volume可以被定义为各种类型，多个容器各自进行挂载操作，将一个volume 挂载为容器内部需要的目录。

kubernetes 管理的宿主机本地存储类型：

• EmptyDir：临时存储
• HostPath：宿主机目录

持久化存储（PV）和网络共享存储类型：

• CephFS：一种开源共享存储系统
• Cinder：一种开源共享存储系统
• CSI：容器存储接口
• FC（Fibre Channel）：光纤存储设备
• Flocker：一种开源共享存储系统
• Glusterfs：一种开源共享存储系统
• iSCSI：iSCSI存储设备
• Local：本地持久化存储
• NFS：网络文件系统
• PersistentVolumeChaim：简称PVC，持久化存储的申请空间
• Portworx Volumes：Portworx 提供的存储服务
• Quobyte Volumes：Quobyte 提供的存储服务
• RBD（Ceph Block Device）：Ceph 块存储

Node 本地存储卷

kubernetes 管理的 Node 本地存储卷（Volume）的类型：

• EmptyDir：与 Pod 同生命周期的Node 临时存储
• HostPath： Node 目录
• Local：基于持久卷（PV）管理的 Node 目录

emptyDir

当 Pod 分派到某个 Node 上时，emptyDir 卷会被创建，并且在 Pod 在该节点上运行期间，卷一直存在。 就像其名称表示的那样，卷最初是空的。 尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，这些容器都可以读写 emptyDir 卷中相同的文件。 当 Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会被永久删除。

下面是使用 EmptyDir 类型的存储卷的 Pod 的YAML 配置示例，该类型的存储卷的参数只有一对花括号"{}"

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - image: busybox
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

hostPath

hostPath 类型的存储卷将主机节点文件系统上的文件或目录挂载到容器中。

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - image: busybox
    name: test-container
    volumeMounts:
    - mountPath: /host-data
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /data  # 宿主上目录位置
      type: Directory # 此字段为可选, Directory 表示该目录必须存在

HostPath 的 type 配置参数：

• 空：系统默认值。为向后兼容的设置，意为系统在挂载 path 时不做任何校验
• DirectoryOrCreate：path 指定的路径必须是目录，如果不存在，则系统将自动创建该目录，将权限设置为 0755，与kubelet具有相同的 owner 和 group
• Directory：path 指定的目录必须存在，否则挂载失败
• FileOrCreate：path 指定的路径必须是文件，如果不存在，则系统将自动创建该文件，将权限设置为 0644，与kubelet 具有相同的 owner 和group
• File：path 指定的文件必须存在，否则挂载失败
• Socket：path 指定的 UNIX socket 必须存在，否则挂载失败
• CharDevice：path 指定的字符设备（character device）必须存在，否则挂载失败
• BlockDevice：path 指定的块设备（block device）必须存在，否则挂载失败

持久卷

为了能够屏蔽底层存储实现的细节，让用户方便使用及管理员方便管理，Kubernetes 从1.0版本就引入了 Persistent Volume (PV) 和 Persistent Volume Claim(PVC) 两个资源对象来实现存储管理子系统。

PV 描述的，是持久化存储数据卷。

PVC 则是用户对存储资源的一个申请。

NFS

centos 8 安装

$ yum install nfs-utls -y
$ cat /etc/exports # 配置 exports
/data/nfs/192.168.0.0/24(rw,sync,no_subtree_check,no_root_squash)
$ systemctl start nfs-server

PV、PVC

定义一个NFS 类型的PV，如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  nfs:
    path: /
    server: 172.17.0.2

定义声明一个1GIB 大小的PVC，如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs
spec:
  resources:
    requests:
      storage: 1Gi
  storageClassName: manual
  accessModes:
    - ReadWriteMany

用户创建的 PVC 必须和符合条件的 PV进行绑定，检查条件包括两部分：

• PV 和 PVC 的 spec 字段，比如 PV 的存储（storage）大小，必须满足 PVC 的要求。
• PV 和 PVC 的 storageClassName 字段必须一致。

PVC 和 PV 绑定之后，Pod 就可以使用这个 PVC了，YAML 如下：

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    role: web-frontend
spec:
  containers:
    - name: web
      image: nginx
      resources:
        limits:
          memory: "128Mi"
          cpu: "500m"
      ports:
        - containerPort: 80
      volumeMounts:
        - name: nfs
          mountPath: "/usr/share/nginx/html"
  volumes:
    - name: nfs
      persistentVolumeClaim:
        claimName: nfs

pod 在volumes 字段声明使用 PVC 名字，等 Pod 创建之后，kubelet 就会把 PVC 所对应的 PV 的 Volume，挂载到 Pod 容器的目录上。

StorageClass

PV 的创建，是由运维人员完成的。在大规模的生产环境里，这是一个非常麻烦的工作。

这是因为，一个大规则的 Kubernetes 集群里很可能有成千上万个 PVC，这就意味着运维人员必须事先创建出成千上万个PV。更麻烦的是，随着新的 PVC 不断被提交，运维人员不得不继续添加新的、能满足条件的PV，否则新的 Pod 就会因为 PVC 绑定不到 PV而失败。在实际操作中，这几乎没办法靠人工做到。

所以，Kubernetes 为我们提供了一套可以自动创建 PV 的机制，即 Dynamic Provisioning。

相比之下，前面人工管理的 PV 的方式就叫做 Staic Provisioning。

Dynamic Provisioning 机制工作的核心，在于一个名叫 StorageClass 的 API 对象。

StorageClass 对象会定义两部分内容：

• PV的属性，比如，存储类型、Volume 的大小等。
• 创建 PV 需要用到的存储插件。比如，Ceph 等

有了这两个信息后，Kubernetes 就能够根据用户提交的 PVC，找到一个对应的 StorageClass 了。然后，Kubernetes 就会调用 StorageClass 声明的存储插件，创建出需要的 PV。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: block-service
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

provisioner：描述存储资源的提供者，用于提供具体的 PV 资源。provisioner的值为：kubernetes.io/gce-pd，表示Kubernetes 内置的 GCE PD 存储插件的名字。

parameters 字段就是 PV 的参数。type=pd-ssd，指的是这个 PV 的类型是SSD 格式的 GCE 远程磁盘。

目前 StorageClass 资源对象支持设置的存储参数最多为 512 个，全部 key 和 value 所占的空间不能超过 256KB。

如果你使用部署在本地的 Kubernetes 集群以及 Rook 存储服务的话，YAML 如下：

apiVersion: ceph.rook.io/v1
kind: Pool
metadata:
  name: replicapool
  namespace: rook-ceph
spec:
  replicated:
    size: 3
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: block-service
provisioner: ceph.rook.io/block
parameters:
  pool: replicapool
  clusterNamespace: rook-ceph

创建 StorageClass

$ kubectl apply -f sv.yaml

PVC 指定使用 StorageClass 名字即可，YAML 如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
spec:
  resources:
    requests:
      storage: 1Gi
  storageClassName: block-service
  accessModes:
    - ReadWriteOnce

有了 Dynamic Provisioning 机制，运维人员只需要在 Kubernetes 集群里创建出数量有限的 StorageClass 对象就可以了。