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.
• 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.

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