Alocação de espaço em disco de dados

Alocar espaço em disco de dados

Ao criar um nó, configure discos de dados para o nó. Você também pode clicar em Expand e personalizar a alocação de espaço em disco de dados para o nó.

Figura 1 Alocação de espaço em disco de dados

• Allocate Disk Space:

  O CCE divide o espaço em disco de dados por duas partes por padrão. Uma parte é usada para armazenar os diretórios de trabalho do Docker/containerd, imagens de contêiner e metadados de imagem. A outra é reservada para os volumes de kubelet e emptyDir. O espaço disponível do mecanismo de contêiner afeta os pulls de imagem e a inicialização e execução do contêiner.

  • Mecanismo de contêiner e espaço de imagem de contêiner (90% por padrão): armazena os diretórios de trabalho do tempo de execução do contêiner, os dados da imagem de contêiner e os metadados da imagem.
  • Espaço kubelet e emptyDir (10% por padrão): armazena arquivos de configuração do pod, segredos e armazenamento montado, como volumes de emptyDir.

  Em clusters de v1.21.10-r0, v1.23.8-r0, v1.25.3-r0 e posteriores, o CCE permite que um mecanismo de contêiner (Docker/containerd) e componentes de kubelet compartilhem espaço em disco de dados.

• Allocate Pod Basesize: indica o tamanho da base de um pod. Você pode definir um limite superior para o espaço em disco ocupado por cada pod de carga de trabalho (incluindo o espaço ocupado por imagens de contêiner). Essa configuração impede que os pods ocupem todo o espaço em disco disponível, o que pode causar exceções de serviço. Recomenda-se que o valor seja menor ou igual a 80% do espaço do mecanismo do contêiner. Este parâmetro está relacionado ao sistema operacional do nó e rootfs de armazenamento de contêiner e não é suportado em alguns cenários.

Alocação de espaço em disco

Para um nó usando um disco de dados não compartilhado (100 GB, por exemplo), a divisão do espaço em disco varia de acordo com o tipo Rootfs de armazenamento de contêiner Device Mapper ou OverlayFS. Para obter detalhes sobre os Rootfs de armazenamento de contêineres correspondentes a diferentes sistemas operacionais, consulte Mapeamento entre SO e Rootfs de armazenamento de contêiner.

• Rootfs (Device Mapper)
  Por padrão, o mecanismo de contêiner e o espaço de imagem, ocupando 90% do disco de dados, podem ser divididos nas duas partes a seguir:

  • O diretório /var/lib/docker é usado como o diretório de trabalho do Docker e ocupa 20% do mecanismo de contêiner e do espaço da imagem de contêiner por padrão. (Tamanho do espaço do diretório /var/lib/docker = espaço em disco de dados x 90% x 20%)
  • O thin pool é usado para armazenar dados de imagem de contêiner, metadados de imagem e dados de contêiner e ocupa 80% do mecanismo de contêiner e do espaço de imagem de contêiner por padrão. (Espaço de thin pool = espaço em disco de dados x 90% x 80%)

    O thin pool é montado dinamicamente. Você pode visualizá-lo executando o comando lsblk em um nó, mas não o comando df -h.

  Figura 2 Alocação de espaço para mecanismos de contêineres do Device Mapper
  

• Rootfs (OverlayFS)

  Não há thin pool separado. Todo o mecanismo de contêiner e o espaço de imagem de contêiner (90% do disco de dados por padrão) estão no diretório /var/lib/docker.

  Figura 3 Alocação de espaço para motores de contêineres do OverlayFS
  

Alocação de tamanho de base para pods

O espaço de contêiner de pod personalizado (tamanho de base) está relacionado ao sistema operacional do nó e ao Rootfs de armazenamento do contêiner. Para obter detalhes sobre o Rootfs de armazenamento de contêineres, consulte Mapeamento entre SO e Rootfs de armazenamento de contêiner.

• O Device Mapper suporta o tamanho de bases de pod personalizado. O valor padrão é 10 GB.
• No modo OverlayFS, o espaço do contêiner do pod não é limitado por padrão.
  

  No caso de usar o Docker em nós do EulerOS 2.9, basesize não terá efeito se CAP_SYS_RESOURCE ou privileged estiver configurado para um contêiner.

Ao configurar basesize, considere o número máximo de pods em um nó. O espaço do mecanismo de contêiner deve ser maior que o espaço total em disco usado pelos contêineres. Fórmula: o espaço do mecanismo de contêiner e o espaço da imagem do contêiner (90% por padrão) > número de contêineres x tamanho de base. Caso contrário, o espaço do mecanismo de contêiner alocado para o nó pode ser insuficiente e o contêiner não pode ser iniciado.

Figura 4 Número máximo de pods

Para nós que suportam basesize, quando o Device Mapper é usado, embora você possa limitar o tamanho do diretório /home de um único contêiner (a 10 GB por padrão), todos os contêineres no nó ainda compartilham o thin pool do nó para armazenamento. Eles não estão completamente isolados. Quando a soma do espaço do thin pool usado por determinados contêineres atinge o limite superior, outros contêineres não podem ser executados corretamente.

Além disso, depois que um arquivo é excluído no diretório /home do contêiner, o espaço do thin pool ocupado pelo arquivo não é liberado imediatamente. Portanto, mesmo que o basesize seja definido como 10 GB, o espaço de thin pool ocupado pelos arquivos continua aumentando até 10 GB quando os arquivos são criados no contêiner. O espaço liberado após a exclusão do arquivo será reutilizado, mas depois de um tempo. Se o número de contêineres no nó multiplicado pelo tamanho de base for maior do que o tamanho do espaço do thin pool do nó, existe a possibilidade de que o espaço do thin pool tenha sido usado.

Mapeamento entre SO e Rootfs de armazenamento de contêiner

Políticas de coleta de lixo para imagens de contêiner

Quando o espaço do mecanismo de contêiner é insuficiente, a coleta de lixo de imagem é acionada.

A política de coleta de imagens de lixo leva dois fatores em consideração: HighThresholdPercent e LowThresholdPercent. O uso do disco acima do limite alto (padrão: 85%) acionará a coleta de lixo. A coleta de lixo excluirá as imagens menos usadas recentemente até que o limite baixo (padrão: 80%) seja atingido.

Configuração recomendada para o espaço do mecanismo de contêiner

• O espaço do mecanismo de contêiner deve ser maior que o espaço total em disco usado pelos contêineres. Fórmula: espaço do mecanismo do contêiner > número de contêineres x tamanho de base
• É aconselhável criar e excluir arquivos de serviços em contêiner em volumes de armazenamento local (como volumes emptyDir e hostPath) ou diretórios de armazenamento em nuvem montados nos contêineres. Desta forma, o espaço da piscina fina não é ocupado. Os volumes emptyDir ocupam o espaço de kubelet. Portanto, planeje adequadamente o tamanho do espaço do kubelet.
• Você pode implantar serviços em nós que usam o OverlayFS (para obter detalhes, consulte Mapeamento entre SO e Rootfs de armazenamento de contêiner) para que o espaço em disco ocupado por arquivos criados ou excluídos em contêineres possa ser liberado imediatamente.

Data Disk Shared Between a Container Engine and kubelet Components

Docker/containerd and kubelet components share the space of a data disk.

• This function is available only to clusters of v1.21.10-r0, v1.23.8-r0, v1.25.3-r0, or later versions.
• If Rootfs is set to OverlayFS, shared data disks are supported. If Rootfs is set to Device Mapper, shared data disks are not supported.
• If you have installed a npd add-on in the cluster, upgrade the add-on to v1.18.10 or later. Otherwise, false alarms will be generated.
• If you have installed a log-agent add-on in the cluster, upgrade the add-on to v1.3.0 or later. Otherwise, log collection will be affected.
• If you have installed ICAgent in the cluster, upgrade it to v5.12.140 or later. Otherwise, log collection will be affected. For details about how to view or upgrade an ICAgent version, see CCE Access.

Figura 5 Configuration for sharing disk space

For nodes using a shared data disk, the container storage Rootfs is of the OverlayFS type. After such a node is created, the data disk space (for example, 100 GB) will not be divided for the container engines, container images, and kubelet components. The data disk is mounted to /mnt/paas, and the storage space is divided using two file systems.

• dockersys: /mnt/paas/runtime
• Kubernetes: /mnt/paas/kubernetes/kubelet

Figura 6 Allocating the storage space of a shared data disk

Problemas comuns

Como expandir a capacidade de armazenamento de um contêiner?

Expansão da capacidade de disco de um nó em um cluster do CCE