Visão geral do armazenamento para clusters do GKE

Neste documento, abordamos as opções de armazenamento compatíveis com o GKE e algumas considerações importantes para selecionar a melhor opção para suas necessidades de negócios.

O GKE é compatível com os seguintes tipos de armazenamento e integrações:

Armazenamento em blocos (disco permanente)

Os volumes de disco permanente são dispositivos duráveis de armazenamento em rede gerenciados pelo Compute Engine que os clusters do GKE podem acessar, como discos físicos em um computador ou servidor. Quando os clusters exigem mais espaço de armazenamento, é possível anexar mais volumes de disco permanente aos nós ou redimensionar os volumes existentes. É possível permitir que o GKE provisione dinamicamente PersistentVolumes com suporte do disco permanente ou que você possa provisionar manualmente os discos.

Essa opção de armazenamento é compatível com o Autopilot do GKE e os clusters Standard.

Por padrão, os volumes de disco permanente são recursos zonais (mantidos em uma única zona dentro de uma região). É possível criar volumes de discos permanentes regionais (mantidos em duas zonas na mesma região). Também é possível anexar um volume de disco permanente como somente leitura a vários nós simultaneamente. Isso é compatível com volumes zonais e regionais de disco permanente.

O armazenamento em disco permanente no GKE é permanente, o que significa que os dados armazenados nos seus discos serão mantidos mesmo se o pod que o estiver usando for encerrado.

Por que usar o armazenamento em disco permanente

Use o armazenamento em disco permanente se os clusters exigirem acesso a armazenamento em blocos durável de alto desempenho e disponível. Um volume de disco permanente normalmente é anexado a um único pod. Essa opção de armazenamento é compatível com o modo de acesso ReadWriteOnce. O GKE oferece suporte para a configuração de volumes de disco permanente com várias opções de latência e desempenho, incluindo as seguintes:

  • Disco permanente equilibrado: adequado para aplicativos empresariais padrão. Essa opção fornece um equilíbrio entre desempenho e custo. Com respaldo das unidades de estado sólido (SSD). Essa é a opção padrão para provisionamento de volume dinâmico em clusters e nós que executam o GKE 1.24 ou posterior.
  • Disco permanente de desempenho: adequado para análise de escalonamento horizontal, bancos de dados e armazenamento em cache permanente. Essa opção é ideal para cargas de trabalho sensíveis ao desempenho. Com respaldo das unidades de estado sólido (SSD).
  • Disco permanente padrão: adequado para cargas de trabalho de Big Data e Big Compute. Esta opção é o tipo de disco mais econômico. Com respaldo dos drives de disco rígido padrão (HDD)
  • Disco permanente extremo: adequado para aplicativos empresariais, como SAP HANA e Oracle. Essa opção oferece o melhor desempenho para atender às necessidades dos maiores bancos de dados na memória. Com respaldo das unidades de estado sólido (SSD). Para aplicativos essenciais para o desempenho, em que o disco permanente não fornece desempenho suficiente, use discos Hyperdisk Extreme.

Para começar a usar essa opção de armazenamento, consulte estes recursos:

Armazenamento em blocos (hiperdisco do Google Cloud)

Os volumes de hiperdisco usam a última geração do armazenamento em blocos do Google Cloud. Os volumes de hiperdisco permitem ajustar dinamicamente o desempenho do armazenamento em blocos à sua carga de trabalho. É possível configurar operações de entrada/saída por segundo (IOPS, na sigla em inglês) e capacidade de forma independente para os aplicativos e se adaptar às mudanças nas necessidades de desempenho ao longo do tempo.

Essa opção de armazenamento é compatível com o Autopilot do GKE e os clusters Standard. Os volumes de hiperdiscos são recursos zonais, sujeitos à disponibilidade regional. O armazenamento de hiperdisco no GKE é permanente, o que significa que os dados armazenados em discos permanecerão mesmo se o pod que o estiver usando for encerrado.

Por que usar o armazenamento do Hyperdisk

Use o armazenamento do Hyperdisk se precisar redimensionar e ajustar dinamicamente as IOPS ou a capacidade. Um volume do hiperdisco normalmente é anexado a um único pod. Essa opção de armazenamento é compatível com o modo de acesso ReadWriteOnce. É possível selecionar as seguintes opções de armazenamento do Hyperdisk para o GKE com base nas suas necessidades de preço-desempenho:

  • Hiperdisco balanceado: a melhor opção para a maioria das cargas de trabalho. Essa é uma boa opção para implantar a maioria dos apps empresariais e de linha de negócios, além de bancos de dados e servidores da Web.
  • Capacidade de processamento do hiperdisco: otimizada para alta capacidade de processamento econômica. Essa é uma boa opção se seu caso de uso segmenta análises de escalonamento horizontal (por exemplo, Hadoop ou Kafka), restauração de dados frios de servidores de backup e cargas de trabalho sensíveis ao custo voltadas para a capacidade.
  • Hyperdisk Extreme: otimizado para desempenho de IOPS. Essa é uma boa opção se você estiver implantando cargas de trabalho de alto desempenho, como sistemas de gerenciamento de banco de dados.
  • Hyperdisk ML: otimizado para cargas de trabalho de treinamento e inferência de IA/ML que precisam carregar pesos de modelo rapidamente. Use essa opção para reduzir o tempo ocioso dos recursos de GPU/TPU devido a gargalos de latência.

As opções de armazenamento de hiperdisco são suportadas nos clusters GKE Autopilot e Standard.

Para começar a usar essa opção de armazenamento, consulte estes recursos:

Armazenamento em blocos efêmero e bruto (SSD local)

Os discos SSD locais são unidades físicas anexadas diretamente aos nós. Eles podem oferecer um desempenho melhor, mas são temporários. Cada volume SSD local é anexado a um nó específico. Não é possível mover o volume para um nó diferente.

Essa opção de armazenamento é compatível com clusters padrão do GKE. O suporte do Autopilot para SSD local está disponível na visualização em máquinas A2 Ultra A100, em clusters e pools de nós que executam o GKE 1.27 e posterior.

O armazenamento temporário respaldado pelo armazenamento SSD local no GKE está vinculado ao ciclo de vida de um pod. Quando o pod é encerrado, o armazenamento temporário associado a ele também é excluído.

Por que usar o SSD local

O uso do armazenamento SSD local nos clusters do GKE é adequado se você precisar de armazenamento em cache quente para bancos de dados e para análise em tempo real ou armazenamento temporário otimizado para flash, oferecendo as latências mais baixas. O armazenamento SSD local pode ser particularmente eficaz como uma camada de armazenamento em cache na frente do Cloud Storage para casos de uso de IA/ML, processamento em lote, análise e bancos de dados na memória.

Para começar a usar essa opção de armazenamento, consulte estes recursos:

Armazenamento de arquivos

O Filestore fornece um sistema de arquivos compartilhado baseado em nuvem para dados não estruturados, com acesso ao sistema de arquivos de rede (NFS, na sigla em inglês). As instâncias do Filestore funcionam como servidores de arquivos no Google Cloud que fornecem armazenamento durável com acesso ReadWriteMany para os clusters do GKE. As instâncias do Filestore são dissociadas do host e exigem operação manual mínima. Os failovers de carga de trabalho são contínuos porque não há operações de infraestrutura para anexar ou remover volumes.

Essa opção de armazenamento é compatível com o Autopilot do GKE e os clusters Standard. O armazenamento do Filestore com o nível de serviço corporativo tem a disponibilidade regional por padrão, enquanto os outros níveis têm disponibilidade zonal. O armazenamento do Filestore no GKE é permanente, o que significa que os dados armazenados nas instâncias persistirão mesmo que o pod que o esteja usando seja encerrado.

Por que usar o armazenamento do Filestore

Use o armazenamento do Filestore se os aplicativos precisarem de acesso ao sistema de arquivos de rede (NFS, na sigla em inglês) e vários leitores e gravadores. Essa opção de armazenamento é adequada quando o caso de uso envolve sistemas de gerenciamento de conteúdo, migração de aplicativos, análise de dados, renderização e processamento de mídia.

Para aumentar a eficiência de custos, os compartilhamentos múltiplos do Filestore para o GKE permitem compartilhar uma instância de nível empresarial do Filestore de 10 GiB ou maior com até 80 PersistentVolumes.

Para começar a usar essa opção de armazenamento, consulte estes recursos:

Armazenamento de objetos (Cloud Storage FUSE)

O Cloud Storage é um repositório de dados binários e de objeto, blobs e dados não estruturados. O driver CSI do FUSE do Cloud Storage gerencia a integração do Cloud Storage FUSE com as APIs do Kubernetes para consumir os buckets do Cloud Storage como volumes. É possível usar o driver CSI do FUSE do Cloud Storage para ativar buckets como sistemas de arquivos em nós do GKE.

O driver FUSE CSI do Cloud Storage é compatível com os modos de acesso ReadWriteMany, ReadOnlyMany e ReadWriteOnce nos clusters do GKE Autopilot e Standard. Os objetos do Cloud Storage têm disponibilidade regional. Os dados do Cloud Storage no GKE são permanentes, o que significa que os dados armazenados nos seus buckets serão mantidos, mesmo que o pod que os esteja usando seja encerrado.

Por que usar o Cloud Storage FUSE

A opção FUSE do Cloud Storage é adequada se você precisar de semântica de arquivos na frente do Cloud Storage para portabilidade. O Cloud Storage FUSE também é uma escolha comum para desenvolvedores que querem armazenar e acessar o treinamento de machine learning (ML) e modelar dados como objetos no Cloud Storage.

Para começar a usar essa opção de armazenamento, consulte estes recursos:

Bancos de dados gerenciados

Um banco de dados gerenciado, como o Cloud SQL ou o Spanner, fornece sobrecarga operacional reduzida e é otimizado para a infraestrutura do Google Cloud. Os bancos de dados gerenciados exigem menos esforço para manter e operar do que um banco de dados implantado diretamente no Kubernetes.

Por que usar bancos de dados gerenciados

O uso de um banco de dados gerenciado do Google Cloud permite que suas cargas de trabalho com estado no GKE acessem dados persistentes enquanto automatizam tarefas de manutenção, como backups, patches e escalonamento. Você cria um banco de dados, cria seu aplicativo e deixa o Google Cloud escaloná-lo para você. No entanto, isso também significa que você pode não ter acesso à versão exata do banco de dados, da extensão ou da variação exata que você quer.

O GKE é compatível com a conexão com os serviços de banco de dados gerenciados do Google Cloud, incluindo:

Para começar a usar essa opção de armazenamento, consulte estes recursos:

Artefatos da versão (Artifact Registry)

O Artifact Registry é um gerenciador de repositórios para imagens de contêiner, pacotes do SO e pacotes de linguagem que você cria e implanta.

Por que usar o Artifact Registry

O Artifact Registry é uma opção adequada para armazenar imagens de contêiner particulares, gráficos do Helm e outros artefatos de versão.

Para extrair imagens dos repositórios Docker do Artifact Registry para o GKE, consulte Como implantar no Google Kubernetes Engine na documentação do Artifact Registry.

A seguir