Kubernetes volumes简介

219次阅读

共计 4211 个字符，预计需要花费 11 分钟才能阅读完成。

容器中的磁盘文件生命周期比较短暂，在一些比较复杂的容器应用中会产生一些问题。一、容器 crash 后，kubelet 会重启该容器，但这些文件会丢失掉。二、pod 中的多个容器经常需要共享文件。因此，Kubernetes 的 Volume 应然而生，用于解决这些问题。

背景

在 Docker 中，也有 volumes 这个概念，volume 只是磁盘上一个简单的目录，或者其他容器中的 volume。生命周期也不受管理，并且直到最近他们都是基于本地后端存储的。Docker 现在也提供了 volume driver，但是现在来说功能也较弱（比如官网提到的 Ceph volume driver，现在已经没有维护了）。
Kubernetes 的 volume，有着明显的生命周期——和使用它的 pod 生命周期一致。因此，volume 生命周期就比运行在 pod 中的容器要长久，即使容器重启，volume 上的数据依然保存着。当然，pod 不再存在时，volume 也就消失了。更重要的是，Kubernetes 支持多种类型的 volume，并且 pod 可以同时使用多种类型的 volume。
内部实现中，volume 只是一个目录，目录中可能有一些数据，pod 的容器可以访问这些数据。这个目录是如何产生的，它后端基于什么存储介质，其中的数据内容是什么，这些都由使用的特定 volume 类型来决定。
要使用 volume，pod 需要指定 volume 的类型和内容（spec.volumes字段），和映射到容器的位置（spec.containers.volumeMounts字段）。
容器中的进程可以看到 Docker image 和 volumes 组成的文件系统。Docker image 处于文件系统架构的 root，任何 volume 都映射在镜像的特定路径上。Volume 不能映射到其他 volume 上，或者硬链接到其他 volume。容器中的每个容器必须堵路地指定他们要映射的 volume。

Volume 类型

Kubernetes 支持很多种类的 volume，包括：emptyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、nfs、iscsi、flocker、glusterfs、rbd、cephfs、gitRepo、secret、persistentVolumeClaim、downwardAPI、azureFileVolume、azuRedisk、vsphereVolume、Quobyte、PortworxVolume、ScaleIO。

emptyDir

当 Pod 被分配到一个 Node 上时，emptyDir volume 就第一次被创建，只要 Pod 还运行在该 Node 上，该 volume 就一直存在。就像它名字里介绍的一样，它初始化时是空的。pod 中的容器都能够完全读写 emptyDir volume 中相同文件，即使 volume 可能被映射到每个容器中不同的路径下。任何情况下，一旦 pod 从该 Node 上移除了，emptyDir volume 中的数据就被永久删除了。注意：容器 crash 并不会在 Node 上删除 pod，因此emptyDir volume 中的数据依然是安全的。
emptyDir volume 的使用场景有：
1) 临时空间，如基于磁盘的排序场景等；
2) 从 crash 中通过 checkpointing 做长时间的计算恢复；
默认的，emptyDir volume 可以存储在任何后端介质之上——普通磁盘、ssd 或网络存储，这都取决于你的环境。然而，你也可以设置emptyDir.medium 字段为Memory，告诉 Kubernetes 映射 tmpfs（基于 RAM 的文件系统）。tmpfs 速度非常快，但要小心它和磁盘不同，一旦机器重启，tmpfs 就会被清空，并且，tmpfs 上写文件会受到容器内存的限制。
pod 示例：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

hostPath

hostPath volume 映射 node 文件系统中的文件或者目录到 pod 里。大多数 Pod 都不需要这个功能，但对于一些特定的场景，该特性还是很有作用的。这些场景包括：
1) 运行的容器需要访问 Docker 内部结构：使用 hostPath 映射 /var/lib/docker
2) 在容器中运行 cAdvisor，使用hostPath 映射 /dev/cgroups
不过，使用这种 volume 要小心，因为：
1) 配置相同的 pod（如通过 podTemplate 创建），可能在不同的 Node 上表现不同，因为不同节点上映射的文件内容不同
2) 当 Kubernetes 增加了资源敏感的调度程序，hostPath 使用的资源不会被计算在内
3) 宿主机下创建的目录只有 root 有写权限。你需要让你的程序运行在 privileged container 上，或者修改宿主机上的文件权限。
pod 示例：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data

rbd

rbd卷可以将 Rados Block Device 设备映射到 pod 中。当 Pod 被移除时，emptyDir卷的内容会被清空，和 emptyDir 不同，rbd卷的内容还存在着，仅仅是卷被卸载掉而已。也就是说，rbd卷可以其上的数据一起，再次被映射，数据也可以在 pod 之间传递。
重要：在使用 rbd 卷之前，你必须先安装 Ceph 环境。
RBD 的一个特性就是能够以只读的方式同时映射给多个用户使用。不幸的是，rbd卷只能被一个用户已可读写的模式映射——不能同时允许多个可写的用户使用。
查看 RBD example 获取更多细节。

cephfs

cephfs卷可以将已经存在的 CephFS 卷映射到 pod 中。与 rbd 卷相同，当 pod 被移除时，cephfs卷的内容还存在着，仅仅是卷被卸载掉而已。另外一点不同的是，CephFS 可以同时以可读写的方式映射给多个用户。
查看 CephFS example 获取更多细节。

使用 subPath

有时，可以在一个 pod 中，将同一个卷共享，使其有多个用处。volumeMounts.subPath特性可以用来指定卷中的一个子目录，而不是直接使用卷的根目录。
这里有一个使用 LAMP 栈（Linux Apache MySQL PHP）的 pod 示例，该 pod 使用了一个共享的卷。HTML 内容映射在它的 html 子目录，而数据库则保存在它的 mysql 目录。

apiVersion: v1
kind: Pod
metadata:
  name: my-lamp-site
spec:
    containers:
    - name: mysql
      image: mysql
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
        subPath: mysql
    - name: php
      image: php
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html
    volumes:
    - name: site-data
      persistentVolumeClaim:
        claimName: my-lamp-site-data

资源

emptyDir或者 hostPath 卷的存储介质（磁盘，SSD 等）取决于 kubelet 根目录（如 /var/lib/kubelet）所处文件系统的存储介质。现在没有限制emptyDir 或者 hostPath 卷能使用的空间大小，也没有对容器或者 pod 的资源隔离。
未来，我们期望 emptyDir 或者 hostPath 卷能够通过 resource 属性，来请求指定大小的空间，并且选择存储介质类型。