01 引言

声明：本文为《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第5版）》的读书笔记

容器内部存储的生命周期是短暂的，会随着容器环境的销毁而销毁，具有不稳定性。如果多个容器希望共享同一份存储，则仅仅依赖容器本身是很难实现的。在Kubernetes系统中，将对容器应用所需的存储资源抽象为存储卷 (Volume)概念 来解决这些问题。

Volume是与Pod绑定的（独立于容器）与Pod具有相同生命周期的资源对象，我们可以将Volume的内容理解为目录或文件。

02 volume分类

Kubernetes目前支持的Volume类型包括Kubernetes的内部资源对象类型、开源共享存储类型、存储厂商提供的硬件存储设备和公有云提供的存储等。

将Kubernetes特定类型的资源对象映射为目录或文件，包括以下类型的资源对象：

Kubernetes管理的宿主机本地存储类型如下：

持久化存储(PV)）和网络共享存储类型如下：

存储厂商提供的存储卷类型如下：

公有云提供的存储卷类型如下：

03 将资源对象映射为存储卷

在Kubernetes中有一些资源对象可以以存储卷的形式挂载为容器内的目录或文件，目前包括ConfigMap、Secret、Downward API、ServiceAccountToken、Projected Volume。

3.1 ConfigMap

ConfigMap主要保存应用程序所需的配置文件，并且通过Volume形式挂载到容器内的文件系统中，供容器内的应用程序读取。

之前在pod篇有写过，可以参考： 《k8s教程（pod篇）-配置管理》

3.2 Secret

假设在Kubernetes中已经存在如下Secret资源:

apiVersion: v1
kind: Secret
metadata:
    name: mysecret
type: Opaque
data:
    password: dmFsdWUtMgOK 
    username: dmFsdWUtMOOK

与ConfigMap的用法类似，在Pod的YAML配置中可以将Secret设置为一个
Volume，然后在容器内通过volumeMounts将Secret类型的Volume挂载到/etc/foo目录下：

apiVersion: v1
kind: Pod
metadata:
    name: mypod
spec:
    containers:
    - name: mycontainer
      image: redis
      volumeMounts:
      - name: foo
        mountPath: "/etc/foo"
    volumes:
    - name: foo
    secret:
        secretName: mysecret

3.3 Downward API

通过Downward API可以将Pod或Container的某些元数据信息（例如Pod名称、Pod IP、Node IP、Label、Annotation、容器资源限制等）以文件的形式挂载到容器内，供容器内的应用使用。

之前在pod篇有写过，可以参考： 《k8s教程（pod篇）-容器获取pod信息（Downward API）》

3.4 Projected Volume

Projected Volume是一种特殊的存储卷类型，用于将一个或多个上述资源对象（ConfigMap、Secret、Downward API）一次性挂载到容器内的同一个目录。

下面是一个使用Projected Volume挂载ConfigMap、Secret、Downward API 共3种资源的示例：

apiVersion: v1
kind: Pod
metadata:
    name: volume-test
spec:
    containers:
    - name: container-test
      image: busybox
      volumeMounts:
      - name: all-in-one
        mountPath: "/projected-volume" 
        readonly: true
    volumes:
    - name: all-in-one
      projected:
        sources:
        - secret:
          name: mysecret
          items: 
          - key: username
            path: my-group/my-username
        - downwardAPI:
          items:  
          - path: "labels"
            fieldRef:
            fieldPath: metadata.labels 
          - path: "cpu_limit" 
            resourceFieldRef:
              containerName: container-test 
               resource: limits.cpu
        - configMap:
          name: myconfigmap
          items: 
          - key: config
            path: my-group/my-config

此外，Kubernetes从1.l1版本开始引入对ServiceAccountToken的挂载支持, 在1.l2版本时达到Beta阶段。ServiceAccountToken通常用于容器内应用访问API Server鉴权的场景中，例子如下：

apiVersion: v1
kind: Pod
metadata:
    name: sa-token-test
spec:
    containers:
    - name: container-test
      image: busybox
      volumeMounts: 
      - name: token-vol
        mountPath: "/service-account" 
        readOnly: true
    volumes: 
    - name: token-vol
      projected:
        sources:
        - serviceAccountToken:
            audience: api # 预期受众的名称，Token的接收者必须使用其中的audience标识符来标识自己，否则拒绝该token
            expirationSeconds: 3600  # Service Account Token国企时间，默认1h
            path: token # 挂载目录下的相对路径

04 Node本地存储卷

Kubernetes管理的Node本地存储卷（Volume）的类型如下：

4.1 EmptyDir

这种类型的Volume将在Pod被调度到Node时进行创建，在初始状态下目录中是空的，所以命名为“空目录”(Empty Directory)。它与Pod具有相同的生命周期，当Pod被销毁时，Node上相应的目录也会被删除。同一个Pod中的多个容器都可以挂载这种Volume。

由于EmptyDir类型的存储卷的临时性特点，它通常可以用于以下应用场景中：

• 基于磁盘进行合并排序操作时需要的暂存空间；
• 长时间计算任务的中间检查点文件；
• 为某个Web服务提供的临时网站内容文件。

在默认情况下，kubelet会在Node的工作目录下为Pod创建EmptyDir目录，这
个目录的存储介质可能是本地磁盘、SSD磁盘或者网络存储设备，取决于环境的
配置。

另外， EmptyDir可以通过 medium字段设置存储介质为“ Memory”，表示使用基于内存的文件系统( tmpfs、 RAM-backed filesystem)。虽然 tmpfs的读写速度非常快，但与磁盘中的目录不同，在主机重启之后， tmpfs的内容就会被清空。此外，写入 tmpfs的数据将被统计为容器的内存使用量，受到容器级别内存资源上限 ( Memory Resource Limit)的限制。

下面是使用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: {}

4.2 HostPath

HostPath类型的存储卷用于将Node文件系统的目录或文件挂载到容器内部使用。

对于大多数容器应用来说，都不需要使用宿主机的文件系统，适合使用HostPath存储卷的一些应用场景如下：

• 容器应用的关键数据需要被持久化到宿主机上；
• 需要使用Docker中的某些内部数据，可以将主机的/var/ib/docker目录挂载到容器内；
• 监控系统，例如cAdvisor需要采集宿主机/sys目录下的内容；
• Pod的启动依赖于宿主机上的某个目录或文件就绪的场景。

HostPath存储卷的主要配置参数为path，设置为宿主机的目录或文件路径； 还可以设置一个可选的参数type，表示宿主机路径的类型，目前支持的type配置参数和校验规则如下所示：

下面是使用HostPath类型的存储卷的Pod的YAML配置示例，其中将宿主机的/data目录挂载为容器内的/host-data目录：

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使用的是宿主机的文件系统，所以在使用时有以下注意事项：

• 对于具有相同HostPath设置的多个Pod（例如通过podTemplate创建的）来说，可能会被Master调度到多个Node上运行，但如果多个Node上HostPath中的文件内容（例如是配置文件）不同，则各Pod应用的运行可能出现不同的结果;
• 如果管理员设置了基于存储资源情况的调度策略，则HostPath目录下的磁盘空间将无法计入Node的可用资源范围内，可能出现与预期不同的调度结果;
• 如果是之前不存在的路径，则由kubelet自动创建出来的目录或文件的 owner将是root，这意味着如果容器内的运行用户(User)不是root，则将无法对该目录进行写操作，除非将容器设置为特权模式(Privileged)，或者由管理员修改HostPath的权限以使得非root用户可写。
• HostPath设置的宿主机目录或文件不会随着Pod的销毁而删除，在Pod不再存在之后，需要由管理员手工删除。

05 文末

由于篇幅有限，关于持久卷的内容，后续再出相关的文章，谢谢大家的阅读，希望能帮助到大家，本文完！