镜像文件系统:配置 Kubernetes 将容器存储在单独的文件系统上

在运行/操作 Kubernetes 集群中,一个常见的问题是磁盘空间不足。当节点被配置时,您应该为您的容器镜像和运行中的容器提供足够的存储空间。容器运行时通常写入到 /var。这可以位于单独的分区或根文件系统上。默认情况下,CRI-O 将其容器和镜像写入到 /var/lib/containers,而 containerd 将其容器和镜像写入到 /var/lib/containerd

在这篇博文中,我们想关注如何配置容器运行时,使其将其内容与默认分区分开存储。
这使得配置 Kubernetes 更加灵活,并支持为容器存储添加更大的磁盘,同时保持默认文件系统不受影响。

一个需要更多解释的领域是 Kubernetes 正在写入磁盘的位置/内容。

了解 Kubernetes 磁盘使用情况

Kubernetes 有持久数据和临时数据。kubelet 和本地 Kubernetes 特定存储的基本路径是可配置的,但通常假定为 /var/lib/kubelet。在 Kubernetes 文档中,这有时被称为根或节点文件系统。此数据的大部分可以分为

  • 临时存储
  • 日志
  • 和容器运行时

这与大多数 POSIX 系统不同,因为根/节点文件系统不是 /,而是 /var/lib/kubelet 所在的磁盘。

临时存储

Pod 和容器可能需要用于其操作的临时或瞬态本地存储。临时存储的生命周期不会超出单个 pod 的生命周期,并且临时存储不能在 pod 之间共享。

日志

默认情况下,Kubernetes 将每个正在运行的容器的日志存储为 /var/log 中的文件。这些日志是临时的,并由 kubelet 监视,以确保它们在 pod 运行时不会变得太大。

您可以自定义每个节点的 日志轮换 设置,以管理这些日志的大小,并配置日志传送(使用第三方解决方案)以避免依赖节点本地存储。

容器运行时

容器运行时具有两个不同的存储区域,用于存储容器和镜像。

  • 只读层:镜像通常表示为只读层,因为它们在容器运行时不会被修改。只读层可以由组合成单个只读层的多个层组成。容器顶部有一个薄层,如果容器写入文件系统,则为容器提供临时存储。

  • 可写层:根据您的容器运行时,本地写入可能会实现为分层写入机制(例如,Linux 上的 overlayfs 或 Windows 上的 CimFS)。这称为可写层。本地写入还可以使用可写文件系统,该文件系统使用容器镜像的完整克隆进行初始化;这用于一些基于虚拟机管理的运行时。

容器运行时文件系统包含只读层和可写层。这在 Kubernetes 文档中被认为是 imagefs

容器运行时配置

CRI-O

CRI-O 使用 TOML 格式的存储配置文件,使您可以控制容器运行时如何存储持久数据和临时数据。CRI-O 使用 存储库
一些 Linux 发行版具有存储的手动条目(man 5 containers-storage.conf)。存储的主要配置位于 /etc/containers/storage.conf 中,并且可以控制临时数据和根目录的位置。
根目录是 CRI-O 存储持久数据的位置。

[storage]
# Default storage driver
driver = "overlay"
# Temporary storage location
runroot = "/var/run/containers/storage"
# Primary read/write location of container storage 
graphroot = "/var/lib/containers/storage"
  • graphroot
    • 从容器运行时存储的持久数据
    • 如果启用了 SELinux,则必须与 /var/lib/containers/storage 匹配
  • runroot
    • 容器的临时读/写访问
    • 建议将其放置在临时文件系统上

以下是一种快速重新标记您的 graphroot 目录以匹配 /var/lib/containers/storage 的方法

semanage fcontext -a -e /var/lib/containers/storage <YOUR-STORAGE-PATH>
restorecon -R -v <YOUR-STORAGE-PATH>

containerd

containerd 运行时使用 TOML 配置文件来控制持久数据和临时数据的存储位置。配置文件的默认路径位于 /etc/containerd/config.toml

containerd 存储的相关字段是 rootstate

  • root
    • containerd 元数据的根目录
    • 默认为 /var/lib/containerd
    • 如果您的操作系统需要,Root 也需要 SELinux 标签
  • state
    • containerd 的临时数据
    • 默认为 /run/containerd

Kubernetes 节点压力驱逐

如果容器文件系统与节点文件系统分离,Kubernetes 将自动检测到。当文件系统分离时,Kubernetes 负责监视节点文件系统和容器运行时文件系统。Kubernetes 文档将节点文件系统和容器运行时文件系统称为 nodefs 和 imagefs。如果 nodefs 或 imagefs 中的任何一个磁盘空间不足,则认为整个节点具有磁盘压力。Kubernetes 将首先通过删除未使用的容器和镜像来回收空间,然后它将诉诸驱逐 pod。在具有 nodefs 和 imagefs 的节点上,kubelet 将 垃圾收集 imagefs 上未使用的容器镜像,并将从 nodefs 中删除死 pod 及其容器。如果只有 nodefs,那么 Kubernetes 垃圾收集包括死容器、死 pod 和未使用的镜像。

Kubernetes 允许更多配置来确定您的磁盘是否已满。
kubelet 中的驱逐管理器具有一些配置设置,可让您控制相关阈值。对于文件系统,相关测量值是 nodefs.availablenodefs.inodesfreeimagefs.availableimagefs.inodesfree。如果容器运行时没有专用磁盘,则忽略 imagefs。

用户可以使用现有默认值

  • memory.available < 100MiB
  • nodefs.available < 10%
  • imagefs.available < 15%
  • nodefs.inodesFree < 5%(Linux 节点)

Kubernetes 允许您在 kubelet 配置文件中的 EvictionHardEvictionSoft 中设置用户定义的值。

EvictionHard
定义限制;一旦超过这些限制,pod 将在没有任何宽限期的情况下被驱逐。
EvictionSoft
定义限制;一旦超过这些限制,pod 将在每个信号都可以设置的宽限期内被驱逐。

如果您为 EvictionHard 指定一个值,它将替换默认值。
这意味着在您的配置中设置所有信号非常重要。

例如,可以使用以下 kubelet 配置来配置驱逐信号和宽限期选项。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
    memory.available:  "100Mi"
    nodefs.available:  "10%"
    nodefs.inodesFree: "5%"
    imagefs.available: "15%"
    imagefs.inodesFree: "5%"
evictionSoft:
    memory.available:  "100Mi"
    nodefs.available:  "10%"
    nodefs.inodesFree: "5%"
    imagefs.available: "15%"
    imagefs.inodesFree: "5%"
evictionSoftGracePeriod:
    memory.available:  "1m30s"
    nodefs.available:  "2m"
    nodefs.inodesFree: "2m"
    imagefs.available: "2m"
    imagefs.inodesFree: "2m"
evictionMaxPodGracePeriod: 60s

问题

Kubernetes 项目建议您使用驱逐的默认设置,或者设置驱逐的所有字段。您可以使用默认设置或指定自己的 evictionHard 设置。如果您错过了某个信号,那么 Kubernetes 将不会监视该资源。管理员或用户可能遇到的一个常见配置错误是将新的文件系统挂载到 /var/lib/containers/storage/var/lib/containerd。Kubernetes 将检测到一个单独的文件系统,因此您要确保检查 imagefs.inodesfreeimagefs.available 是否满足您的需求,如果您已这样做。

另一个令人困惑的领域是,如果您为节点定义了镜像文件系统,则临时存储报告不会更改。镜像文件系统 (imagefs) 用于存储容器镜像层;如果容器写入其自己的根文件系统,则本地写入不会计入容器镜像的大小。容器运行时存储这些本地修改的位置是运行时定义的,但通常是镜像文件系统。如果 pod 中的容器正在写入文件系统支持的 emptyDir 卷,那么这将使用 nodefs 文件系统的空间。kubelet 始终报告基于 nodefs 所代表的文件系统的临时存储容量和分配;当临时写入实际上进入镜像文件系统时,这可能会令人困惑。

未来工作

为了修复临时存储报告的限制并为容器运行时提供更多配置选项,SIG Node 正在研究 KEP-4191。在 KEP-4191 中,Kubernetes 将检测可写层是否与只读层(镜像)分离。这将使我们能够将所有临时存储(包括可写层)放置在与镜像相同的磁盘上,并允许为镜像使用单独的磁盘。

参与其中

如果您想参与其中,可以加入 Kubernetes 节点特别兴趣小组 (SIG)。

如果您想分享反馈,可以在我们的 #sig-node Slack 频道上进行。如果您还不是该 Slack 工作区的一部分,您可以访问 https://slack.k8s.io/ 获取邀请。

特别感谢所有提供精彩评论、分享宝贵见解或提出主题想法的贡献者。

  • Peter Hunt
  • Mrunal Patel
  • Ryan Phillips
  • Gaurav Singh