k8s教程（Volume篇）-k8s存储机制概述

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 文末

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