Asignación de espacio en disco de datos
Esta sección describe cómo asignar espacio en disco de datos a los nodos para que pueda configurar el espacio en disco de datos en consecuencia.
Asignación de espacio en disco de datos
Al crear un nodo, debe configurar un disco de datos para el nodo y asegurarse de que la capacidad del disco de datos es mayor o igual a 100 GB. Puede hacer clic en Expand para personalizar la asignación de espacio en disco de datos del nodo.
- Asignar espacio en disco:
CCE divides the data disk space for container engines and pods. The container engine space stores the Docker/containerd working directories, container images, and image metadata. The other is reserved for kubelet and emptyDir volumes. The available container engine space affects image pulls and container startup and running.
- Motor de contenedores y espacio de imagen contenedor (90% por defecto): almacena los directorios de trabajo de contenedor en tiempo de ejecución, datos de imagen de contenedor y metadatos de imagen.
- kubelet y espacio de emptyDir (10% por defecto): almacena archivos de configuración de pod, secretos y almacenamiento montado como volúmenes de emptyDir.
- Asignar tamaño de la base del pod: indica el tamaño de la base de un contenedor. Puede establecer un límite superior para el espacio en disco ocupado por cada pod de carga de trabajo (incluido el espacio ocupado por las imágenes de contenedor). Esta configuración impide que los pods ocupen todo el espacio disponible en disco, lo que puede provocar excepciones de servicio. Se recomienda que el valor sea inferior o igual al 80% del espacio del motor del contenedor. Este parámetro está relacionado con el sistema operativo del nodo y los rootfs de almacenamiento de contenedor y no se admite en algunos escenarios.
Asignación de espacio en disco
Un disco de datos, 100 GB por ejemplo, se puede dividir de la siguiente manera (dependiendo de los Rootfs de almacenamiento contenedor): Para obtener más información sobre los Rootfs de almacenamiento de contenedor correspondientes a diferentes sistemas operativos, consulte la sección Asignación entre SO y roofts de almacenamiento de contenedores.
- Rootfs (Device Mapper)
De forma predeterminada, el motor de contenedor y el espacio de imagen, que ocupan el 90% del disco de datos, se pueden dividir en las dos partes siguientes:
- El directorio /var/lib/docker se utiliza como el directorio de trabajo de Docker y ocupa el 20% del motor de contenedor y el espacio de imagen de contenedor por defecto. (Tamaño del espacio del directorio /var/lib/docker = Espacio en disco de datos x 90% x 20%)
- El thin pool se utiliza para almacenar datos de imagen de contenedor, metadatos de imagen y datos de contenedor, y ocupa el 80% del motor de contenedor y el espacio de imagen de contenedor de forma predeterminada. (Espacio de thin pool = Espacio de disco de datos x 90% x 80%)
El thin pool está montado dinámicamente. Puede verlo ejecutando el comando lsblk en un nodo, pero no el comando df -h.
- Rootfs (OverlayFS)
No hay thin pool separado. Todo el motor de contenedor y el espacio de imagen de contenedor (90% del disco de datos por defecto) están en el directorio /var/lib/docker.
Asignación de tamaño de la base para pods
El espacio de contenedor de pod personalizado (tamaño de la base) está relacionado con el SO del nodo y el almacenamiento de contenedor Rootfs. Para obtener más información acerca de los Rootfs de almacenamiento de contenedor, consulte Asignación entre SO y roofts de almacenamiento de contenedores.
- Device Mapper admite el tamaño de la base de pod personalizado. El valor predeterminado es 10 GB.
- En el modo de OverlayFS, el espacio de contenedor del pod no está limitado de forma predeterminada.
En el caso de usar Docker en los nodos de EulerOS 2.9, el basesize no tendrá efecto si CAP_SYS_RESOURCE o privileged están configurados para un contenedor.
Al configurar basesize, tenga en cuenta el número máximo de pods en un nodo. El espacio de contenedor del motor debe ser mayor que el espacio total en disco utilizado por contenedores. Fórmula: el espacio contenedor del motor y el espacio de imagen contenedor (90% por defecto) > Número de contenedores x tamaño de la base. De lo contrario, el espacio de motor de contenedor asignado al nodo puede ser insuficiente y el contenedor no puede iniciarse.
En el caso de los nodos que admiten basesize, cuando se utiliza Device Mapper, aunque puede limitar el tamaño del directorio /home de un solo contenedor a 10 GB de forma predeterminada, todos los contenedores del nodo siguen compartiendo el grupo delgado del nodo para el almacenamiento. No están completamente aislados. Cuando la suma del espacio de thin pool utilizado por ciertos recipientes alcanza el límite superior, otros recipientes no pueden funcionar correctamente.
Además, después de eliminar un archivo en el directorio /home del contenedor, el espacio de thin pool ocupado por el archivo no se libera inmediatamente. Por lo tanto, incluso si basesize se establece en 10 GB, el espacio de thin pool ocupado por los archivos sigue aumentando hasta 10 GB cuando se crean archivos en el contenedor. El espacio liberado después de la eliminación del archivo se reutilizará, pero después de un tiempo. Si el número de contenedores en el nodo multiplicado por tamaño básico es mayor que el tamaño del espacio de thin pool del nodo, existe la posibilidad de que se haya agotado el espacio de thin pool.
Asignación entre SO y roofts de almacenamiento de contenedores
|
SO |
Rootfs de almacenamiento de contenedor |
Tamaño de la base personalizado |
|---|---|---|
|
CentOS 7.x |
Los clústeres de v1.19.16 y anteriores usan Device Mapper. Los clústeres de v1.19.16 y posteriores usan OverlayFS. |
Se admite cuando Rootfs se establece en Device Mapper y el motor de contenedor es Docker. El valor predeterminado es 10G. No se admite cuando Rootfs se establece en OverlayFS. |
|
EulerOS 2.3 |
Device Mapper |
Se admite solo cuando el motor de contenedor es Docker. El valor predeterminado es 10G. |
|
EulerOS 2.5 |
Device Mapper |
Se admite solo cuando el motor de contenedor es Docker. El valor predeterminado es 10G. |
|
EulerOS 2.8 |
Los clústeres de v1.19.16-r2 y anteriores usan Device Mapper. Los clústeres de v1.19.16-r2 y posteriores usan OverlayFS. |
Se admite cuando Rootfs se establece en Device Mapper y el motor de contenedor es Docker. El valor predeterminado es 10G. No se admite cuando Rootfs se establece en OverlayFS. |
|
EulerOS 2.9 |
OverlayFS |
Solo admite los clústeres de v1.19.16, v1.21.3, v1.23.3 y posteriores. El tamaño de la base del contenedor no está limitado por defecto. No se admite cuando las versiones del clúster son anteriores a v1.19.16, v1.21.3 y v1.23.3. |
|
EulerOS 2.10 |
OverlayFS |
Se admite solo cuando el motor de contenedor es Docker. El tamaño de la base del contenedor no está limitado por defecto. |
|
Ubuntu 18.04 |
OverlayFS |
No se admite. |
|
Huawei Cloud EulerOS 1.1 |
OverlayFS |
No se admite. |
|
Huawei Cloud EulerOS 2.0 |
OverlayFS |
Se admite solo cuando el motor de contenedor es Docker. El tamaño de la base del contenedor no está limitado por defecto. |
|
SO |
Rootfs de almacenamiento de contenedor |
Tamaño de la base personalizado |
|---|---|---|
|
CentOS 7.x |
OverlayFS |
No se admite. |
|
Ubuntu 18.04 |
OverlayFS |
No se admite. |
|
EulerOS 2.9 |
ECS VMs use OverlayFS. ECS PMs use Device Mapper. |
Solo se admite cuando Rootfs se establece en OverlayFS y el motor de contenedor es Docker. El tamaño de la base del contenedor no está limitado por defecto. Se admite cuando Rootfs se establece en Device Mapper y el motor de contenedor es Docker. El valor predeterminado es 10G. |
|
Huawei Cloud EulerOS 1.1 |
OverlayFS |
No se admite. |
|
Huawei Cloud EulerOS 2.0 |
OverlayFS |
Se admite solo cuando el motor de contenedor es Docker. El tamaño de la base del contenedor no está limitado por defecto. |
Políticas de recolección de basura para imágenes de contenedores
Cuando el espacio del motor de contenedor es insuficiente, se activa la recolección de basura de imagen.
La política para la recolección de imágenes de basura tiene en cuenta dos factores: HighThresholdPercent y LowThresholdPercent. El uso del disco por encima del umbral alto (predeterminado: 85%) activará la recolección de basura. La recolección de basura eliminará las imágenes utilizadas menos recientemente hasta que se cumpla el umbral bajo (por defecto: 80%).
Configuración recomendada para el espacio del motor del contenedor
- El espacio de contenedor del motor debe ser mayor que el espacio total en disco utilizado por contenedores. Fórmula: Espacio del motor del contenedor > Número de contenedores x tamaño de la base
- Se recomienda crear y eliminar archivos de servicios en contenedores en volúmenes de almacenamiento locales (como volúmenes de emptyDir y de hostPath) o directorios de almacenamiento en la nube montados en contenedores. De esta manera, el espacio de thin pool no está ocupado. Los volúmenes de emptyDir ocupan el espacio de kubelet. Por lo tanto, planifique correctamente el tamaño del espacio de kubelet.
- Puede desplegar servicios en nodos que utilizan OverlayFS (para obtener más información, consulte Asignación entre SO y roofts de almacenamiento de contenedores) para que el espacio en disco ocupado por los archivos creados o eliminados de contenedores se pueda liberar inmediatamente.
