Kubernetes存储 - Node本地存储卷

官方文档

• Kubernetes管理的Node本地存储目前有三种，分别是EmptyDir,HostPath,Local，EmptyDir是一种与Pod同生命周期的Node临时存储；HostPath是Node的目录；Local是基于持久卷(PV)管理的Node目录。接下来详细说明这几种类型如何以存储卷的形式使用

EmptyDir

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

1. 基于磁盘进行合并排序操作时所需要的暂存空间

基于磁盘进行合并排序指的是对某些磁盘中无法存放的、特别大的数据进行排序，首先将这些数据分成若干块，先把每块内存排序，然后再多路归并，合并为全量数据

2. 长时间计算任务的中间检查点文件

在长时间计算任务中，中间检查点文件(checkpoint files)指的是用于保存计算任务当前状态的文件，它们的主要目的是在任务执行过程中定期保存进度，以便在任务发生故障或者中断时，任务可以从最近的检查点继续，而不是从头开始，这种机制在高性能计算、大规模数据处理、机器学习训练等领域尤为重要

3. 为某个Web服务提供的临时网站内容文件

在Web服务中，临时网站内容文件通常指的是那些在短时间内提供给用户访问的文件，这些文件可能是为了特定的活动、测试、故障排除或临时展示内容而生成的。以下是一些可能的情况：

1. 缓存文件
   缓存文件是Web服务器或内容分发网络（CDN）生成的临时文件，用于加速内容交付。它们可以包括网页、图片、脚本和样式表等，通过缓存减少服务器负担和提高用户访问速度。
2. 会话文件
   会话文件存储用户会话数据，例如登录状态、购物车内容等。这些文件通常在用户会话结束或超时后被删除。
3. 临时上传文件
   当用户上传文件到服务器时，这些文件可能先存储在一个临时目录中，等待进一步处理（如病毒扫描、格式转换等），然后才移动到最终存储位置。
4. 临时生成的内容
   临时生成的内容文件可能包括：
   测试页面：用于开发和测试的临时页面。
   错误页面：在服务器遇到错误时生成的临时错误页面。
   动态生成内容：如用户请求生成的PDF文件、报告或其他动态内容。
5. 临时配置文件
   在某些情况下，Web服务可能需要临时配置文件来测试新的配置或在故障排除过程中使用。这些文件在测试或故障排除完成后会被删除。
6. 临时静态内容
   有时，Web服务需要临时展示某些静态内容，例如临时公告、活动页面或维护通知。这些文件在活动结束或维护完成后会被移除。
7. 临时备份文件
   在进行更新或维护时，服务器可能会创建临时备份文件，以防更新过程中出现问题。这些备份文件在确认更新成功后会被删除。
8. 临时日志文件
   在调试或监控过程中，服务器可能生成临时日志文件以记录特定事件或操作。这些文件在调试或监控完成后会被清理。
9. 临时数据文件
   在处理用户请求时，服务器可能生成临时数据文件以存储中间计算结果或临时数据。这些文件在请求处理完成后会被删除。

示例：假设一个Web服务允许用户上传图片并对其进行处理（如调整大小或添加滤镜）。在这个过程中，上传的图片文件首先存储在一个临时目录中，等待处理完成后再移动到最终存储位置。处理过程中生成的中间文件（如调整大小后的图片）也可能存储在临时目录中，直到处理完成并返回给用户。
通过使用临时文件，Web服务可以更有效地管理资源，确保系统稳定性和性能，同时提供灵活的内容交付和处理能力。

• 在默认情况下，kubelet会在Node的工作目录下为Pod创建EmptyDir目录，这个目录的存储介质可能是本地磁盘、SSD磁盘或者网络存储设备，取决于环境的配置
• 另外，EmptyDir可以通过medium字段设置存储介质为Memory，表示使用基于内存的文件系统(tmpfs、RAM-backed filesystem)。虽然tmpfs的读写速度非常快，但与磁盘中的目录不同。当主机重启之后，tmpfs的内容就会被清空。此外，写入tmpfs的数据将被统计为容器的内存使用量，受到容器级别的内存资源上限(Memory Resource Limit)的限制
• 使用EmptyDir类型的存储卷的Pod非常简单，只需要在YAML配置中的volume内加上一条emptyDir: {}即可，如下所示

apiVersion: v1
kind: Pod
metadata:name: test-pod
spec:containers:- image: busyboxname: test-containervolumeMounts:- mountPath: /cachename: cache-volumevolumes:- name: cache-volumeemptyDir: {}

HostPath

• 这种类型的存储卷用于讲Node文件系统的目录或文件挂载到容器内部使用。对于大多数容器应用来说，都不需要使用宿主机的文件系统。适合使用HostPath存储卷的一些应用场景如下：

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

例子如下

apiVersion: v1
kind: Pod
metadata:name: hostpath-example-linux
spec:os: { name: linux }nodeSelector:kubernetes.io/os: linuxcontainers:- name: example-containerimage: registry.k8s.io/test-webservervolumeMounts:- mountPath: /fooname: example-volumereadOnly: truevolumes:- name: example-volume# 挂载 /data/foo，但仅当该目录已经存在时hostPath:path: /data/foo # 主机上的目录位置type: Directory # 此字段可选

• 由于HostPath使用的是宿主机的文件系统，所以在使用时有以下注意事项

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