k8s存储机制概述_k8s集群的内存和宿主机的内存有什么区别

文 | 阿甘兄

发布 | 阿甘兄（blog: https://yanglinwei.blog.csdn.net）

一、前言

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

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

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

二、Volume分类

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

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

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

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

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

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

三、将资源对象映射为存储卷

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

3.1 ConfigMap

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

之前在pod篇有写过，可以参考《k8s教程（pod篇）-配置管理》 https://yanglinwei.blog.csdn.net/article/details/125725754

3.2 Secret

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

apiVersion: v1kind: Secretmetadata:    name: mysecrettype: Opaquedata:    password: dmFsdWUtMgOK     username: dmFsdWUtMOOK

与ConfigMap的用法类似，在Pod的YAML配置中可以将Secret设置为一个

Volume，然后在容器内通过volumeMounts将Secret类型的Volume挂载到/etc/foo目录下：

apiVersion: v1kind: Podmetadata:    name: mypodspec:    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）》： https://yanglinwei.blog.csdn.net/article/details/127102519

3.4 Projected Volume

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

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

apiVersion: v1kind: Podmetadata:    name: volume-testspec:    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.11版本开始引入对ServiceAccountToken的挂载支持, 在1.12版本时达到Beta阶段。ServiceAccountToken通常用于容器内应用访问API Server鉴权的场景中，例子如下：

apiVersion: v1kind: Podmetadata:name: sa-token-testspec:containers:-name: container-testimage: busyboxvolumeMounts: -name: token-volmountPath: "/service-account" readOnly: truevolumes: -name: token-volprojected:sources:-serviceAccountToken:audience: api # 预期受众的名称，Token的接收者必须使用其中的audience标识符来标识自己，否则拒绝该tokenexpirationSeconds: 3600  # Service Account Token国企时间，默认1hpath: token # 挂载目录下的相对路径

四、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: v1kind: Podmetadata:    name: test-podspec:    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: v1kind: Podmetadata:    name: test-podspec:    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不再存在之后，需要由管理员手工删除。