数据盘空间分配说明
本章节将详细介绍节点数据盘空间分配的情况,以便您根据业务实际情况配置数据盘大小。
设置数据盘空间分配
在创建节点时,您需要配置节点数据盘,您可单击“展开高级配置”,自定义节点数据盘的空间分配。
- 容器引擎空间分配:
- 指定磁盘空间:CCE将数据盘空间默认划分为两块,一块用于存放容器引擎 (Docker/Containerd) 工作目录、容器镜像的数据和镜像元数据;另一块用于Kubelet组件和EmptyDir临时存储等。容器引擎空间的剩余容量将会影响镜像下载和容器的启动及运行。
- 容器引擎和容器镜像空间(默认占90%):用于容器运行时工作目录、存储容器镜像数据以及镜像元数据。
- Kubelet组件和EmptyDir临时存储(默认占10%):用于存储Pod配置文件、密钥以及临时存储EmptyDir等挂载数据。
当“容器引擎和容器镜像空间”和“Kubelet组件和EmptyDir临时存储空间”分配比例之和不满100%时,剩余空间将分配给用户数据使用,您可以将其挂载到指定路径下。挂载路径请填写业务目录路径,不可设置为空或根目录等操作系统关键路径。
- 指定磁盘空间:CCE将数据盘空间默认划分为两块,一块用于存放容器引擎 (Docker/Containerd) 工作目录、容器镜像的数据和镜像元数据;另一块用于Kubelet组件和EmptyDir临时存储等。容器引擎空间的剩余容量将会影响镜像下载和容器的启动及运行。
- Pod容器空间分配:即容器的basesize设置,每个工作负载下的容器组 Pod 占用的磁盘空间设置上限(包含容器镜像占用的空间)。合理的配置可避免容器组无节制使用磁盘空间导致业务异常。建议此值不超过容器引擎空间的 80%。该参数与节点操作系统和容器存储Rootfs相关,部分场景下不支持设置。详情请参见操作系统与容器存储Rootfs对应关系。
- 写入模式:
- 线性:线性逻辑卷是将一个或多个物理卷整合为一个逻辑卷,实际写入数据时会先往一个基本物理卷上写入,当存储空间占满时再往另一个基本物理卷写入。
- 条带化:有两块以上数据盘时才可支持选择条带化模式。创建逻辑卷时指定条带化,当实际写入数据时会将连续数据分成大小相同的块,然后依次存储在多个物理卷上,实现数据的并发读写从而提高读写性能。条带化模式的存储池不支持扩容。
容器引擎空间分配
对于容器引擎和Kubelet不共享磁盘空间的节点,数据盘根据容器存储Rootfs不同具有两种划分方式(以100G大小为例):Device Mapper类型和OverlayFS类型。不同操作系统对应的容器存储Rootfs请参见操作系统与容器存储Rootfs对应关系。
- Device Mapper类型存储Rootfs
其中默认占90%的容器引擎和容器镜像空间又可分为以下两个部分:
- 其中/var/lib/docker用于Docker工作目录,默认占比20%,其空间大小 = 数据盘空间 * 90% * 20%
- thinpool用于存储容器镜像数据、镜像元数据以及容器使用的磁盘空间,默认占比为80%,其空间大小 = 数据盘空间 * 90% * 80%
thinpool是动态挂载,在节点上使用df -h命令无法查看到,使用lsblk命令可以查看到。
图1 Device Mapper类型容器引擎空间分配
- OverlayFS类型存储Rootfs
相比Device Mapper存储引擎,没有单独划分thinpool,容器引擎和容器镜像空间(默认占90%)都在/var/lib/docker目录下。
图2 OverlayFS类型容器引擎空间分配
Pod容器空间分配
自定义Pod容器空间(basesize)设置与节点操作系统和容器存储Rootfs相关(容器存储Rootfs请参见操作系统与容器存储Rootfs对应关系):
- Device Mapper模式下支持自定义Pod容器空间(basesize)配置,默认值为10GiB。
- OverlayFS模式默认不限制Pod容器空间大小。
配置Pod容器空间(basesize)时,需要同时考虑创建节点时的最大实例数配置。理想情况下,容器引擎空间需要大于容器使用的磁盘总空间,即:容器引擎和容器镜像空间(默认占90%) > 容器数量 * Pod容器空间(basesize)。否则,可能会引起节点分配的容器引擎空间不足,从而导致容器启动失败。
对于支持配置basesize的节点,尽管可以限制单个容器的主目录大小(开启时默认为10GiB),但节点上的所有容器还是共用节点的thinpool磁盘空间,并不是完全隔离,当一些容器使用大量thinpool空间且总和达到节点thinpool空间上限时,也会影响其他容器正常运行。
另外,在容器的主目录中创删文件后,其占用的thinpool空间不会立即释放,因此即使basesize已经配置为10GiB,而容器中不断创删文件时,占用的thinpool空间会不断增加一直到10GiB为止,后续才会复用这10GiB空间。如果节点上的容器数量*basesize > 节点thinpool空间大小,理论上有概率出现节点thinpool空间耗尽的场景。
操作系统与容器存储Rootfs对应关系
操作系统 |
容器存储Rootfs |
自定义Pod容器空间(basesize) |
---|---|---|
CentOS 7.x |
v1.19.16以下版本集群使用Device Mapper v1.19.16及以上版本集群使用OverlayFS |
Rootfs为Device Mapper且容器引擎为Docker时支持,默认值为10G。 Rootfs为OverlayFS时不支持。 |
Ubuntu 22.04 |
OverlayFS |
不支持。 |
镜像回收策略说明
当容器引擎空间不足时,会触发镜像垃圾回收。
镜像垃圾回收策略只考虑两个因素:HighThresholdPercent 和 LowThresholdPercent。 磁盘使用率超过上限阈值(HighThresholdPercent,默认值为80%)将触发垃圾回收。 垃圾回收将删除最近最少使用的镜像,直到磁盘使用率满足下限阈值(LowThresholdPercent,默认值为70%)。
容器引擎空间大小配置建议
- 容器引擎空间需要大于容器使用的磁盘总空间,即:容器引擎空间 > 容器数量 * Pod容器空间(basesize)
- 容器业务的创删文件操作建议在容器挂载的本地存储(如emptyDir、hostPath)或云存储的目录中进行,这样不会占用thinpool空间。其中Emptydir使用的是kubelet空间,需要规划好kubelet空间的大小。
- 可将业务部署在使用OverlayFS存储模式的节点上(请参见操作系统与容器存储Rootfs对应关系),避免容器内创删文件后占用的磁盘空间不立即释放问题。