Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Computação
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Redes
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Gerenciamento e governança
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
Cloud Operations Center
Resource Governance Center
Migração
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Análises
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
IoT
IoT Device Access
Outros
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Segurança e conformidade
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Serviços de mídia
Media Processing Center
Video On Demand
Live
SparkRTC
Armazenamento
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Cloud Server Backup Service
Storage Disaster Recovery Service
Scalable File Service
Volume Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Bancos de dados
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Aplicações de negócios
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Data Lake Factory
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Distribuição de conteúdo e computação de borda
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Soluções
SAP Cloud
High Performance Computing
Serviços para desenvolvedore
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
Cloud Application Engine
MacroVerse aPaaS
KooPhone
KooDrive
Central de ajuda/ Cloud Container Engine/ Referência de API/ Apêndice/ Alocação de espaço em disco de dados

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

Atualizado em 2024-09-10 GMT+08:00

Esta seção descreve como alocar espaço em disco de dados aos nós para que você possa configurar o espaço em disco de dados de acordo.

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

Tabela 1 Sistemas operacionais de nó e mecanismos de contêiner em clusters do CCE

SO

Rootfs de armazenamento de contêiner

Tamanho da base personalizado

CentOS 7.x

Clusters de v1.19.16 e anteriores usam Device Mapper.

Clusters de v1.19.16 e posterior usam OverlayFS.

Suportado quando Rootfs é definido como Device Mapper e o mecanismo de contêiner é Docker. O valor padrão é 10 GB.

Não é suportado quando Rootfs está definido como OverlayFS.

EulerOS 2.3

Device Mapper

Suportado somente quando o mecanismo de contêiner é Docker. O valor padrão é 10 GB.

EulerOS 2.5

Device Mapper

Suportado somente quando o mecanismo de contêiner é Docker. O valor padrão é 10 GB.

EulerOS 2.8

Clusters de v1.19.16-r2 e anteriores usam Device Mapper.

Clusters de v1.19.16-r2 e posterior usam OverlayFS.

Suportado quando Rootfs é definido como Device Mapper e o mecanismo de contêiner é Docker. O valor padrão é 10 GB.

Não é suportado quando Rootfs está definido como OverlayFS.

EulerOS 2.9

OverlayFS

Suportado apenas por clusters de v1.19.16, v1.21.3, v1.23.3 e posteriores. O tamanho da base do contêiner não é limitado por padrão.

Não há suporte se as versões de cluster forem anteriores a v1.19.16, v1.21.3 e v1.23.3.

EulerOS 2.10

OverlayFS

Suportado somente quando o mecanismo de contêiner é Docker. O tamanho da base do contêiner não é limitado por padrão.

Ubuntu 18.04

OverlayFS

Não compatível.

Huawei Cloud EulerOS 1.1

OverlayFS

Não compatível.

Huawei Cloud EulerOS 2.0

OverlayFS

Suportado somente quando o mecanismo de contêiner é Docker. O tamanho da base do contêiner não é limitado por padrão.

Tabela 2 Sistemas operacionais de nó e mecanismos de contêiner em clusters do CCE Turbo

SO

Rootfs de armazenamento de contêiner

Tamanho da base personalizado

CentOS 7.x

OverlayFS

Não compatível.

Ubuntu 18.04

OverlayFS

Não compatível.

EulerOS 2.9

As VMs do ECS usam OverlayFS.

As PMs do ECS usam Device Mapper.

Suportado somente quando Rootfs é definido como OverlayFS e o mecanismo de contêiner é Docker. O tamanho da base do contêiner não é limitado por padrão.

Suportado quando Rootfs é definido como Device Mapper e o mecanismo de contêiner é Docker. O valor padrão é 10 GB.

Huawei Cloud EulerOS 1.1

OverlayFS

Não compatível.

Huawei Cloud EulerOS 2.0

OverlayFS

Suportado somente quando o mecanismo de contêiner é Docker. O tamanho da base do contêiner não é limitado por padrão.

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

Usamos cookies para aprimorar nosso site e sua experiência. Ao continuar a navegar em nosso site, você aceita nossa política de cookies. Saiba mais

Feedback

Feedback

Feedback

0/500

Conteúdo selecionado

Envie o conteúdo selecionado com o feedback