Todos os produtos
Search
Central de documentação

Container Service for Kubernetes:Visão geral do armazenamento

Última atualização: Jun 27, 2026

Aplicações Kubernetes frequentemente exigem armazenamento persistente. O ACK integra os serviços de armazenamento da Alibaba Cloud (discos em nuvem, OSS, NAS e CPFS) por meio da Container Storage Interface (CSI) e também oferece suporte a volumes nativos do Kubernetes. Isso proporciona opções flexíveis de armazenamento tanto para cargas de trabalho efêmeras quanto persistentes.

Soluções de armazenamento

As opções de armazenamento do ACK dividem-se em duas categorias:

  • Volumes nativos do Kubernetes: Usados para dados efêmeros, injeção de configurações ou interação com o nó host. Esses volumes estão vinculados ao ciclo de vida do Pod e não são adequados para dados persistentes de aplicações.

  • Volumes persistentes da Alibaba Cloud: Integrados aos serviços de armazenamento da Alibaba Cloud via CSI. Esses volumes são desacoplados do ciclo de vida do Pod e oferecem suporte a cargas de trabalho com estado.

image
Antes de usar os recursos de armazenamento de contêineres, certifique-se de compreender os principais conceitos de armazenamento do Kubernetes , como volumes, PersistentVolumes (PVs) e PersistentVolumeClaims (PVCs).

Volumes nativos do Kubernetes

Os volumes nativos do Kubernetes estão vinculados ao ciclo de vida do Pod e não foram projetados para armazenamento persistente de dados.

Tipo

Descrição

Principais características

emptyDir

Volume efêmero que compartilha o ciclo de vida do Pod.

Os dados persistem apenas durante a existência do Pod. Ideal para compartilhamento entre contêineres e caches temporários.

HostPath

Monta um arquivo ou diretório do nó host em um Pod. Use o campo type (por exemplo, DirectoryOrCreate) para controlar a validação pré-montagem e o comportamento de criação.

Para mais informações, consulte Volumes HostPath.

Os dados ficam vinculados ao nó e não acompanham o reagendamento do Pod. Não recomendado para aplicações com estado que exigem alta disponibilidade (como bancos de dados ou caches).

ConfigMap/Secret

Monta entradas de configuração ou credenciais sensíveis como arquivos.

Destinado a pequenos volumes de dados de configuração, e não a dados de aplicação. Use-o para desacoplar a configuração do código da aplicação.

Volumes persistentes da Alibaba Cloud

Para aplicações com estado que exigem dados persistentes, use volumes de armazenamento persistente suportados pelos serviços de armazenamento da Alibaba Cloud. Esses volumes existem independentemente do ciclo de vida do Pod e integram-se ao Kubernetes por meio da CSI.

Comparação

A tabela de comparação abaixo inclui um índice de referência rápida sob o nome de cada solução de armazenamento. Tomando o disco em nuvem como exemplo:

Solução de armazenamento

Descrição

Compensações e limitações

image Disco em nuvem

Estático/Dinâmico | RWO (sem Multi-Attach) | Faturamento

  • Descrição: Serviço de armazenamento em bloco com 99,9999999% de confiabilidade de dados e desempenho de I/O consistente. Os dados são replicados em três cópias no backend. Suporta modo de sistema de arquivos (volumeMode: Filesystem) e modo de dispositivo de bloco (volumeMode: Block). Múltiplas camadas de desempenho estão disponíveis (ESSD AutoPL, ESSD, ESSD Entry, entre outras), além de criptografia em repouso.

  • Caso de uso: Bancos de dados (MySQL, PostgreSQL), middleware (Redis, Elasticsearch) e outras aplicações com estado de instância única que demandam alto desempenho de I/O e confiabilidade de dados.

  • accessModes: Sem o Multi-Attach ativado, o disco em nuvem só pode ser anexado a um Pod por vez. Não suporta cargas de trabalho que exigem acesso compartilhado a dados entre múltiplas instâncias (como compartilhamento de conteúdo em clusters web).

    Use discos em nuvem com StatefulSets ou Deployments de Pod único, e não com Deployments de múltiplas réplicas. Consulte os guias para obter detalhes.
  • Vinculação de zona: Discos em nuvem só podem ser anexados a Pods na mesma zona (exceto discos ESSD com redundância de zona).

    Use uma StorageClass com modo de vinculação WaitForFirstConsumer para habilitar o agendamento ciente de topologia.
  • Compatibilidade de instância: Os tipos de disco em nuvem devem corresponder à família da instância ECS. Para obter detalhes, consulte Visão geral das famílias de instâncias.

image NAS

Estático/Dinâmico | RWX, RWO, ROX | Faturamento

  • Descrição: Serviço de armazenamento de arquivos compartilhado que suporta o protocolo NFS. Múltiplos Pods podem ler e gravar simultaneamente, e tanto a capacidade quanto o desempenho escalam elasticamente. Oferece recursos de lixeira, snapshot e backup para proteção de dados.

  • Caso de uso: Compartilhamento de conteúdo em clusters web, pipelines de CI/CD, armazenamento centralizado de logs e outros cenários onde múltiplas instâncias de aplicação leem e gravam os mesmos dados simultaneamente.

  • Sobrecarga de I/O de rede: Todas as leituras e gravações passam pela rede, o que introduz latência na casa dos milissegundos em comparação ao disco em nuvem. Não recomendado para bancos de dados ou outras aplicações altamente sensíveis à latência de I/O.

  • Vizinho ruidoso: Nos modos subpath ou sharepath, PVs provisionados dinamicamente são subdiretórios da mesma instância NAS no backend. Eles compartilham recursos de desempenho (largura de banda e IOPS), o que pode causar efeitos de vizinho ruidoso.

  • Limites de protocolo e rede: Apenas o protocolo NFS é suportado. A montagem entre VPCs não é suportada.

image OSS

Estático ossfs 1.0/ossfs 2.0

Dinâmico ossfs 1.0/ossfs 2.0

RWX, ROX | Faturamento

  • Descrição: Serviço de armazenamento de objetos de alta capacidade e baixo custo. A ferramenta ossfs monta um bucket como um sistema de arquivos no Pod. Dois drivers de montagem estão disponíveis: ossfs 1.0 (otimizado para compatibilidade POSIX) e ossfs 2.0 (otimizado para alto throughput e concorrência).

  • Caso de uso: Data lakes para IA e análise de big data, armazenamento de mídia estática (imagens, vídeos) e backup/arquivamento de dados de aplicações.

  • Desempenho não nativo: Construído sobre um sistema de arquivos em espaço de usuário (FUSE), que traduz operações de sistema de arquivos em chamadas de API HTTP. Isso resulta em alta latência e baixo desempenho de I/O aleatório. Não recomendado para bancos de dados ou cargas de trabalho com escrita frequente.

  • Compatibilidade POSIX incompleta: Não suporta totalmente todas as operações padrão de sistema de arquivos. Por exemplo, chmod e chown no caminho raiz são restritos, o que pode causar problemas de compatibilidade com aplicações.

image CPFS for Lingjun

Estático/Dinâmico | RWX | Faturamento

  • Descrição: Sistema de arquivos paralelo de alto desempenho desenvolvido para cargas de trabalho de IA. Oferece throughput e IOPS de alta concorrência.

  • Caso de uso: Treinamento e inferência de modelos grandes (AIGC), simulação de direção autônoma e outras cargas de trabalho de IA que exigem alto desempenho de I/O paralelo.

  • Custo e disponibilidade: Custo mais elevado que outras soluções. Atualmente em preview apenas por convite e disponível somente em regiões selecionadas.

  • Limite de montagem: A montagem entre VPCs não é suportada.

image O que é o CPFS Edição Geral

Estático | RWX | Faturamento

  • Descrição: Sistema de arquivos compartilhado para computação de alto desempenho (HPC) que oferece IOPS e throughput superiores aos do NAS de uso geral.

  • Caso de uso: Computação genômica, análise de big data, aceleração de cache de dados e outras cargas de trabalho tradicionais de HPC.

  • Custo e disponibilidade: Custo mais elevado que o NAS de uso geral e disponível apenas em regiões selecionadas.

  • Limite de montagem: Apenas o protocolo NFS é suportado. A montagem entre VPCs não é suportada.

Além do desempenho básico, as soluções de armazenamento diferem na forma como lidam com recuperação de falhas, gerenciamento de capacidade e proteção de dados. Considere as seguintes questões para refinar sua escolha.

Recuperar-se de falhas de nó

Quando um nó falha, a recuperação rápida da aplicação e a segurança dos dados são críticas para a alta disponibilidade.

  • Disco em nuvem: A CSI desanexa automaticamente o disco do nó com falha e o anexa ao novo nó.

  • NAS / OSS / CPFS: Como armazenamento compartilhado, um Pod pode remontar o volume assim que iniciar em outro nó. O tempo de recuperação depende principalmente do tempo de inicialização da aplicação.

  • HostPath: Os dados ficam fixos em um nó específico. Se esse nó falhar, o Pod não poderá acessar seus dados originais a partir de outro nó. A replicação entre nós e a HA devem ser gerenciadas pela própria aplicação.

Recomendação
Se sua aplicação (por exemplo, um banco de dados de instância única) tolerar interrupções curtas, escolha disco em nuvem. Para failover rápido (por exemplo, serviços web de alta disponibilidade), priorize soluções de armazenamento compartilhado com múltiplas réplicas.

Planejar a capacidade de armazenamento

O planejamento de capacidade ajuda a controlar custos e evita interrupções causadas pela falta de armazenamento. A capacidade do PVC comporta-se de maneira diferente dependendo do tipo de armazenamento.

  • Disco em nuvem: A capacidade do PVC mapeia um para um com o tamanho do disco. Limites de capacidade são aplicados e a expansão de volume é suportada. Adequado para cargas de trabalho com necessidades previsíveis de capacidade e fortes requisitos de isolamento.

  • OSS: Capacidade elástica e faturamento baseado no uso real. A capacidade do PVC serve apenas para correspondência de PV e não impõe limite de uso.

  • NAS/CPFS:

    • Volumes provisionados estaticamente: A capacidade do PVC serve apenas para correspondência de PV e não limita o uso real. A capacidade disponível depende da cota da instância no backend, compartilhada entre os Pods.

    • Volumes provisionados dinamicamente: Para NAS (apenas modo subpath, com allowVolumeExpansion: true) e CPFS for Lingjun, a capacidade do PVC é convertida em uma cota de diretório que impõe limites reais de uso. Em outros cenários, o comportamento corresponde ao de volumes provisionados estaticamente.

Recomendação
Para cargas de trabalho que exigem orçamento preciso e forte isolamento (por exemplo, bancos de dados em ambientes multilocatário), use disco em nuvem. Para cargas onde muitos Pods compartilham dados e a capacidade muda frequentemente (por exemplo, logs ou arquivos web estáticos), utilize soluções de armazenamento compartilhado.

Fazer backup dos dados da aplicação

Recomendação
Para backup e restauração completos, rápidos e consistentes do volume, use snapshots de disco em nuvem. Para arquivamento de longo prazo, necessidades de conformidade ou recuperação de arquivo único, utilize os recursos correspondentes do NAS ou OSS. Se você usar HostPath, garanta que sua aplicação possua uma estratégia robusta de proteção de dados.

Principais add-ons e conceitos

  • Add-ons CSI (csi-plugin, csi-provisioner)

    Implementação de plugin de armazenamento recomendada pelo Kubernetes, implantada por padrão em clusters ACK. Esses add-ons interagem com as APIs de armazenamento da Alibaba Cloud para gerenciar o ciclo de vida do volume, incluindo provisionamento, anexação, desanexação e exclusão.

  • CNFS

    Um aprimoramento de armazenamento disponível em clusters ACK Pro. O CNFS representa recursos NAS, OSS e CPFS como Custom Resource Definitions (CRDs) do Kubernetes e fornece capacidades de gerenciamento refinado, como criação dinâmica de subdiretórios, gerenciamento de cotas, monitoramento de I/O, gerenciamento de lixeira e cache distribuído.

Notas de uso

  • Versão do cluster: É necessário Kubernetes 1.14 ou posterior. Para atualizar, consulte Atualizar manualmente um cluster.

  • Ambiente do cluster: A CSI é totalmente testada e validada em clusters ACK. Em clusters não ACK (auto-gerenciados na Alibaba Cloud ou ambientes fora da Alibaba Cloud), a CSI pode exigir adaptação manual devido a diferenças de configuração, permissões e rede.

    Para ambientes não ACK, consulte o código-fonte do alibaba-cloud-csi-driver e adapte-o ao seu ambiente.
  • Configuração do nó: O parâmetro kubelet --enable-controller-attach-detach deve ser definido como true.

  • Sistema operacional: Nós Windows não são suportados.

  • Permissões RBAC: PVs são recursos com escopo de cluster, enquanto PVCs são recursos com escopo de namespace. Ao configurar o RBAC, considere as diferenças de permissão para esses dois tipos de recursos.

    Se as funções predefinidas do ACK (administrador, engenheiro de O&M e outras) não atenderem às suas necessidades, crie funções personalizadas. Por exemplo, a função padrão de engenheiro de O&M tem acesso de leitura e gravação a PVCs, mas apenas leitura a PVs, portanto não pode criar PVs manualmente. Para mais informações, consulte Autorizar operações no cluster com RBAC.

Perguntas frequentes

Como determino qual plugin de armazenamento meu cluster utiliza?

Use um dos métodos a seguir.

Verificar anotações de nó no console

  1. Na página ACK Clusters, clique em no nome do seu cluster. No painel de navegação à esquerda, clique em Nodes > Nodes.

  2. Na coluna Actions, clique em Details e verifique as Annotations do nó na aba Overview.

    Se a anotação volumes.kubernetes.io/controller-managed-attach-detach: true existir, o cluster utiliza CSI. Caso contrário, utiliza Flexvolume.

Verificar parâmetros do kubelet via linha de comando

Nós e verifique os parâmetros do kubelet.

ps -ef | grep kubelet

Exemplo de saída (trecho):

--enable-controller-attach-detach=true
  • true: CSI

  • false: Flexvolume

Como conceder permissões CSI manualmente?

A CSI requer permissões para acessar outros serviços da Alibaba Cloud ao anexar, desanexar, criar ou excluir volumes. Por padrão, a CSI é instalada com as permissões necessárias. Se precisar conceder permissões manualmente, use um dos métodos a seguir.

  • Autorização via função RAM (padrão): A CSI utiliza a função AliyunCSManagedCsiRole para acessar outros serviços em nuvem. Para mais informações, consulte Funções do ACK.

    • Clusters gerenciados ACK: O token da função RAM é armazenado em um Secret chamado addon.csi.token. Monte este Secret para autorizar a CSI através da função RAM.

    • Clusters dedicados ACK: A CSI herda a função RAM do nó onde seu Pod é executado.

    Para mais informações sobre como conceder permissões a funções RAM, consulte Gerenciar permissões para uma função RAM.

  • Autorização via AccessKey:

    • Variáveis de ambiente: Crie o AccessKey como um Secret do Kubernetes e injete-o no Pod da CSI como variáveis de ambiente. Isso evita que credenciais sejam expostas em texto simples nos manifestos de implantação.

    • YAML inline: Escreva o AccessKey diretamente no YAML da CSI. Não recomendado para ambientes de produção.