Vista geral do armazenamento para clusters do GKE

Este documento aborda as opções de armazenamento suportadas pelo GKE e algumas considerações importantes para selecionar a melhor opção para as necessidades da sua empresa. Para determinar que família de máquinas é adequada para a sua seleção, consulte a comparação de séries de máquinas.

O GKE suporta os seguintes tipos de armazenamento e integrações:

Armazenamento em bloco (disco persistente)

Os volumes do Persistent Disk são dispositivos duradouros de armazenamento de rede geridos pelo Compute Engine aos quais os seus clusters do GKE podem aceder, como os discos físicos de um computador ou um servidor. Quando os seus clusters requerem espaço de armazenamento adicional, pode anexar mais volumes de discos persistentes aos seus nós ou redimensionar os volumes de discos persistentes existentes. Pode permitir que o GKE aprovisione dinamicamente PersistentVolumes com base no disco persistente ou pode aprovisionar discos manualmente.

Esta opção de armazenamento é suportada em clusters do GKE Autopilot e Standard.

Por predefinição, os volumes de discos persistentes são recursos zonais (mantidos numa única zona numa região). Pode criar volumes de discos persistentes regionais (mantidos em duas zonas na mesma região). Também pode anexar um volume do Persistent Disk como só de leitura a vários nós em simultâneo. Esta funcionalidade é suportada para volumes de discos persistentes zonais e regionais.

O armazenamento do disco persistente no GKE é persistente, o que significa que os dados armazenados nos seus discos persistem mesmo que o pod que o está a usar seja terminado.

Porquê usar o armazenamento do Persistent Disk

Use o armazenamento do Persistent Disk se os seus clusters precisarem de acesso a um armazenamento em blocos duradouro de elevado desempenho e alta disponibilidade. Normalmente, um volume de disco persistente está associado a um único pod. Esta opção de armazenamento suporta o modo de acesso ReadWriteOnce. O GKE oferece suporte para a configuração de volumes de discos persistentes com uma variedade de opções de latência e desempenho, incluindo as seguintes:

  • Disco persistente equilibrado: adequado para aplicações empresariais padrão. Esta opção oferece um equilíbrio entre o desempenho e o custo. Com o apoio de unidades de estado sólido (SSD). Esta é a opção predefinida para o aprovisionamento dinâmico de volumes em clusters e nós com o GKE 1.24 ou posterior.
  • Performance Persistent Disk: adequado para estatísticas de expansão, bases de dados e armazenamento em cache persistente. Esta opção é ideal para cargas de trabalho sensíveis ao desempenho. Com o apoio de unidades de estado sólido (SSD).
  • Disco persistente padrão: adequado para cargas de trabalho de grandes volumes de dados e computação. Esta opção é o tipo de disco mais rentável. Apoiado por unidades de disco rígido (HDD) padrão.
  • Disco persistente extremo: adequado para aplicações empresariais, como SAP HANA e Oracle. Esta opção oferece o desempenho mais elevado para satisfazer as necessidades das maiores bases de dados na memória. Com o apoio de unidades de estado sólido (SSD). Para aplicações críticas para o desempenho, em que o disco persistente não oferece desempenho suficiente, use discos Hyperdisk Extreme.

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

Armazenamento em bloco (Google Cloud Hyperdisk)

Os volumes Hyperdisk usam a próxima geração de Trusted Cloud armazenamento em blocos. Os volumes Hyperdisk permitem-lhe ajustar dinamicamente o desempenho do armazenamento em blocos à sua carga de trabalho. Pode configurar as operações de entrada/saída por segundo (IOPS) e o débito de forma independente para as suas aplicações e adaptar-se às necessidades de desempenho em constante mudança ao longo do tempo.

Esta opção de armazenamento é suportada em clusters do GKE Autopilot e Standard. Os volumes Hyperdisk são recursos zonais, sujeitos à disponibilidade regional. O armazenamento do Hyperdisk no GKE é persistente, o que significa que os dados armazenados nos seus discos persistem mesmo que o pod que os está a usar seja terminado.

Por que motivo deve usar o armazenamento Hyperdisk

Use o armazenamento Hyperdisk se precisar de redimensionar e ajustar dinamicamente as IOPS ou a taxa de transferência. Normalmente, um volume do Hyperdisk está associado a um único pod. Esta opção de armazenamento suporta o ReadWriteOncemodo de acesso. Pode selecionar as seguintes opções de armazenamento do Hyperdisk para o GKE com base nas suas necessidades de preço/desempenho:

  • Hyperdisk Balanced: a melhor opção para a maioria das cargas de trabalho. Esta é uma boa opção para implementar a maioria das apps empresariais e de linha de negócio, bem como bases de dados e servidores Web.
  • Débito do Hyperdisk: otimizado para um débito elevado e económico. Esta é uma boa opção se o seu exemplo de utilização tiver como alvo a análise de dados de expansão (por exemplo, Hadoop ou Kafka), a restauração de dados inativos de servidores de cópia de segurança e cargas de trabalho sensíveis a custos orientadas para o débito.
  • Hyperdisk Extreme: otimizado para o desempenho de IOPS. Esta é uma boa opção se estiver a implementar cargas de trabalho de alto desempenho, como sistemas de gestão de bases de dados.
  • Hyperdisk ML: otimizado para cargas de trabalho de preparação e inferência de IA/AA que precisam de carregar rapidamente os pesos dos modelos. Use esta opção para reduzir a inatividade dos recursos de GPU/TPU devido a gargalos de latência.

As opções de armazenamento do Hyperdisk são suportadas em clusters do GKE Autopilot e Standard.

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

Armazenamento em bloco (conjunto de armazenamento Hyperdisk)

Um conjunto de armazenamento Hyperdisk é um conjunto pré-aprovisionado de recursos de armazenamento (capacidade, débito e IOPS) que os discos no seu cluster do GKE podem usar. Os recursos de armazenamento são partilhados entre todos os hiperdiscos que criar no conjunto de armazenamento.

Os clusters padrão do GKE permitem que os discos de arranque do Hyperdisk (para sistemas operativos) e os Hyperdisks anexados (para armazenamento de dados) façam parte de um conjunto de armazenamento. Os clusters do GKE Autopilot só suportam Hyperdisks anexados para pools de armazenamento.

Para começar a usar esta opção de armazenamento, consulte os seguintes recursos:

Armazenamento em bloco efémero e não processado (SSD local)

Os discos SSD locais são unidades físicas que estão associadas diretamente aos seus nós. Podem oferecer um melhor desempenho, mas são efémeras. Cada volume de SSD local está anexado a um nó específico. Não pode mover o volume para um nó diferente.

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

O armazenamento efémero suportado pelo armazenamento SSD local no GKE está associado ao ciclo de vida de um pod. Quando o seu Pod é terminado, o armazenamento efémero associado a esse Pod também é eliminado.

Por que motivo deve usar o SSD local

A utilização do armazenamento SSD local em clusters do GKE é adequada se precisar de armazenamento em cache rápido para bases de dados e para estatísticas em tempo real, ou armazenamento efémero otimizado para flash que ofereça as latências mais baixas. O armazenamento SSD local pode ser particularmente eficaz como uma camada de colocação em cache à frente do Cloud Storage para exemplos de utilização de IA/AA, processamento em lote, estatísticas e bases de dados na memória.

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

Sistema de arquivos de rede (NFS)

O Filestore oferece um sistema de ficheiros partilhado baseado na nuvem para dados não estruturados, com acesso ao sistema de ficheiros em rede (NFS). As instâncias do Filestore funcionam como servidores de ficheiros que oferecem armazenamento duradouro com acesso ReadWriteMany para os seus clusters do GKE. Trusted Cloud As instâncias do Filestore estão separadas do anfitrião e requerem uma operação manual mínima. As comutações por falha da carga de trabalho são perfeitas porque não existem operações de infraestrutura para anexar ou desanexar volumes.

Esta opção de armazenamento é suportada em clusters do GKE Autopilot e Standard. O armazenamento do Filestore com o nível de serviço empresarial tem, por predefinição, disponibilidade regional, enquanto os outros níveis de serviço têm disponibilidade zonal. O armazenamento do Filestore no GKE é persistente, o que significa que os dados armazenados nas suas instâncias persistem mesmo que o pod que o está a usar seja terminado.

Porquê usar o armazenamento do Filestore

Use o armazenamento do Filestore se as suas aplicações precisarem de acesso ao sistema de ficheiros de rede (NFS) e de vários leitores e escritores. Esta opção de armazenamento é adequada se o seu exemplo de utilização envolver sistemas de gestão de conteúdo, migração de aplicações, análise de dados, renderização e processamento de multimédia.

Para uma maior rentabilidade, as partilhas múltiplas do Filestore para o GKE permitem-lhe partilhar uma instância de nível empresarial do Filestore de 10 GiB ou superior com até 80 PersistentVolumes.

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

Armazenamento de objetos (Cloud Storage FUSE)

O Cloud Storage é um local de armazenamento de objetos para dados binários e de objetos, blobs e dados não estruturados. O controlador CSI do FUSE do Cloud Storage gere a integração do FUSE do Cloud Storage com as APIs Kubernetes para consumir contentores do Cloud Storage existentes como volumes. Pode usar o controlador CSI do FUSE do Cloud Storage para montar contentores como sistemas de ficheiros em nós do GKE.

O controlador CSI do FUSE do Cloud Storage suporta os modos de acesso ReadWriteMany, ReadOnlyMany e ReadWriteOnce em clusters GKE Autopilot e Standard. Os objetos do Cloud Storage têm disponibilidade regional. Os dados do Cloud Storage no GKE são persistentes, o que significa que os dados armazenados nos seus contentores permanecem mesmo que o pod que os está a usar seja terminado.

Porquê usar o FUSE do Cloud Storage

A opção FUSE do Cloud Storage é adequada se precisar de semântica de ficheiros à frente do Cloud Storage para portabilidade. O Cloud Storage FUSE também é uma escolha comum para os programadores que querem armazenar e aceder a dados de modelos e de preparação de aprendizagem automática (AA) como objetos no Cloud Storage.

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

Bases de dados geridas

Uma base de dados gerida, como o Cloud SQL ou o Spanner, oferece uma sobrecarga operacional reduzida e está otimizada para a Trusted Cloud infraestrutura. As bases de dados geridas requerem menos esforço para manter e operar do que uma base de dados que implementa diretamente no Kubernetes.

Por que motivo usar bases de dados geridas

A utilização de uma base de dados gerida permite que as suas cargas de trabalho com estado no GKE acedam a dados persistentes enquanto automatizam tarefas de manutenção, como cópias de segurança, aplicação de patches e escalabilidade. Trusted Cloud Cria uma base de dados, cria a sua app e permite que o Trusted Cloud a dimensione por si. No entanto, isto também significa que pode não ter acesso à versão exata de uma base de dados, uma extensão ou o tipo exato de base de dados que quer.

O GKE oferece suporte para a ligação a serviços de Trusted Cloud bases de dados geridas incluindo o seguinte:

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

Crie artefactos (Artifact Registry)

O Artifact Registry é um gestor de repositórios para imagens de contentores, pacotes de SO e pacotes de idiomas que cria e implementa.

Por que motivo deve usar o Artifact Registry

O Artifact Registry é uma opção adequada para armazenar as suas imagens de contentores privados, gráficos Helm e outros artefactos de compilação.

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

O que se segue?