As unidades de estado sólido (SSDs) locais são unidades SSD de tamanho fixo que podem ser montadas em uma única VM do Compute Engine. É possível usar SSDs locais no GKE para ter um armazenamento de alto desempenho que não seja persistente (efêmero) e anexado a cada nó do cluster. Eles oferecem maior capacidade e menor latência que os discos padrão.
A partir da versão 1.25.3-gke.1800, é possível configurar um pool de nós do GKE para usar o SSD local com uma interface NVMe para armazenamento temporário local ou armazenamento em blocos brutos.
Se você estiver usando o GKE com clusters padrão, poderá anexar volumes SSDs locais a nós ao criar pools de nós. Isso melhora o desempenho do armazenamento temporário para as cargas de trabalho que usam volumes emptyDir ou PersistentVolumes locais. É possível criar pools de nós com SSDs locais dentro dos limites do tipo de máquina do cluster e das cotas do projeto.
Um disco SSD local é anexado a apenas um nó, e os próprios nós são temporários. É possível programar uma carga de trabalho em um nó diferente a qualquer momento.
Para mais informações sobre os benefícios e as limitações dos SSDs locais, como desempenho e número permitido de discos SSDs por tipo de máquina, consulte SSDs locais na documentação do Compute Engine.
Por que escolher o SSD local para o GKE
O SSD local é uma boa opção quando as cargas de trabalho têm algum dos seguintes requisitos:
- Executar aplicativos que fazem o download e o processamento de dados, como IA ou machine learning, análise, processamento em lote, armazenamento em cache local e bancos de dados na memória.
- Seus aplicativos têm necessidades de armazenamento especializadas e você quer acesso de bloco bruto em armazenamento temporário de alto desempenho.
- você quer executar aplicativos de dados especializados e operar volumes SSDs locais, como um cache no nível do nó para seus pods. É possível usar essa abordagem para melhorar o desempenho de aplicativos de banco de dados na memória, como Aerospike ou Redis.
Armazenamento temporário
Recomendamos o uso da opção --ephemeral-storage-local-ssd para provisionar o SSD local para armazenamento temporário do nó. (esse é o padrão se você estiver usando uma série de máquinas de terceira geração).
Essa abordagem coloca os volumes emptyDir, as camadas graváveis em contêiner e as imagens que, juntas, constituem o armazenamento temporário do nó no SSD local. Os benefícios
incluem maior largura de banda de E/S do que o Persistent Disk padrão e tempos de inicialização do pod aprimorados.
O uso do SSD local para armazenamento temporário do nó significa que os volumes do SSD local do disco de inicialização não estão disponíveis para outros usos. Não modifique o disco de inicialização diretamente usando um Demonset, HostPath ou outro mecanismo privilegiado. Caso contrário, ele pode falhar. Se você precisar de um controle refinado sobre os volumes do SSD local, use a abordagem de bloco bruto.
Armazenamento do dispositivo de transferência por blocos
O armazenamento de dispositivo de transferência por blocos permite acesso aleatório a dados em blocos de tamanho fixo. Alguns aplicativos especializados exigem acesso direto a um armazenamento de dispositivo em bloco, porque, por exemplo, a camada do sistema de arquivos introduz sobrecarga desnecessária.
Cenários comuns para usar o armazenamento de dispositivo de transferência por blocos incluem o seguinte:
- Bancos de dados em que os dados são organizados diretamente no armazenamento subjacente.
- Software que implementa um tipo de serviço de armazenamento (sistemas de armazenamento definidos por software).
Na versão 1.25.3-gke.1800 e posterior do GKE, é possível criar clusters e pools de nós com SSDs NVMe locais de bloco bruto anexadas, usando a opção --local-nvme-ssd-block. Em seguida, personalize o armazenamento em blocos formatando um sistema de arquivos de sua escolha (como ZFS ou HDFS) e configurando a RAID. Essa opção é adequada se você precisa de controle adicional para executar
cargas de trabalho que exigem acesso específico ao armazenamento em blocos apoiado pelo SSD local.
Você também pode usar a abordagem de acesso em blocos com SSDs locais se quiser que um cache de dados unificado compartilhe dados entre pods e os dados estejam vinculados a um ciclo de vida do nó. Para fazer isso, instale um DaemonSet com uma configuração RAID, formate um sistema de arquivos e use um PersistentVolume local para compartilhar dados entre pods.
Requisitos da máquina
A maneira como você provisiona o SSD local para seus clusters e pools de nós do GKE depende do tipo de máquina subjacente. O GKE aceita volumes SSD locais em séries de máquinas do Compute Engine de primeira, segunda e terceira geração. Os volumes de SSD local exigem o tipo de máquina n1-standard-1 ou maior.
O tipo de máquina padrão e2-medium não é compatível.
Para identificar a série de máquinas, use o número no nome do tipo de máquina. Por exemplo, as máquinas N1 são de primeira geração, e as máquinas N2 são de segunda geração.
Para ver uma lista de séries e tipos de máquinas disponíveis, consulte o Guia de recursos e comparação de famílias de máquinas na documentação do Compute Engine.
Requisitos das séries de máquinas de primeira e segunda geração
Para usar uma série de máquinas de primeira ou segunda geração com o SSD local, o cluster ou o pool de nós precisa executar a versão 1.25.3-gke.1800 ou posterior do GKE.
Para provisionar o SSD local em uma série de máquinas de primeira ou segunda geração, especifique o número de volumes SSD locais a serem usados com sua VM. Para ver uma lista de séries de máquinas e o número permitido correspondente de SSDs locais, consulte Como escolher um número válido de SSDs locais na documentação do Compute Engine.
Requisitos da série de máquinas de terceira geração
Se você quiser usar uma série de máquinas de terceira geração com SSD local, seu cluster ou pool de nós precisará estar executando uma das seguintes versões do GKE ou mais recentes:
- 1.25.13-gke.200 a 1.26
- 1.26.8-gke.200 a 1.27
- 1.27.5-gke.200 a 1.28
- 1.28.1-gke.200 a 1.29
Para séries de máquinas de terceira geração, cada tipo de máquina é pré-configurado sem SSD local ou com uma quantidade fixa de volumes de SSD local. Você não especifica o número de volumes SSD locais a serem incluídos. Em vez disso, a capacidade do SSD local disponível para os clusters é definida implicitamente como parte do formato da VM.
Para conferir uma lista de séries de máquinas e o número permitido correspondente de SSDs locais, consulte Como escolher um número válido de SSDs locais na documentação do Compute Engine.
Padrão de uso de volumes SSD locais
Para usar volumes SSD locais nos clusters, siga estas etapas gerais:
- Provisionar um pool de nós com SSD local anexado: para criar um pool de nós do GKE com SSDs locais anexados, transmita o parâmetro de armazenamento temporário ou armazenamento em blocos brutos ao chamar o comando
create cluster. A definição dos parâmetros do SSD local cria um pool de nós do GKE com o SSD local anexado e configurado como armazenamento temporário local ou armazenamento em blocos brutos, dependendo dos parâmetros escolhidos. Para saber mais sobre as opções de provisionamento do SSD local, consulte Parâmetros do SSD local. - Acessar dados de volumes SSD locais: para usar os dados de volumes SSD locais, utilize uma construção do Kubernetes, como o emptyDir ou o volume permanente local. Para saber mais sobre essas opções, consulte Acesso ao SSD local.
Parâmetros do SSD local no GKE
A tabela a seguir resume os parâmetros recomendados que o GKE fornece para provisionar o armazenamento SSD local em clusters. É possível usar a gcloud CLI para transmitir esses parâmetros.
| Tipo de SSD local | Comando da CLI gcloud | Disponibilidade do GKE | Perfil da SSD local |
|---|---|---|---|
| SSD local de armazenamento temporário | gcloud container clusters create |
v1.25.3-gke.1800 ou posterior |
Tecnologia de armazenamento : NVMe Dados compartilhados entre pods: não Ciclo de vida dos dados: pod Tamanho e necessidade de configuração de RAID: até 9 TiB. O GKE configura automaticamente a RAID em segundo plano. Formato: sistema de arquivos (Kubernetes emptyDir) Integração do programador do Kubernetes: totalmente integrado por padrão. O programador do Kubernetes vai garantir espaço no nó antes da posição e escalonar nós, se necessário. Para saber como usar esse parâmetro de API, consulte Provisionar e usar armazenamento temporário com SSD local. |
| Bloco de SSD de NVMe local | gcloud container clusters create |
v1.25.3-gke.1800 ou posterior |
Tecnologia de armazenamento : NVMe Dados compartilhados entre pods: sim, via PVs locais. Ciclo de vida dos dados: nó Tamanho e necessidade de configuração de RAID: até 9 TiB. Você precisa configurar manualmente a RAID para tamanhos maiores. Formato : bloco bruto Integração do programador do Kubernetes : não, por padrão. Você precisa garantir a capacidade nos nós e lidar com problemas. Se você ativar o PV local, a programação será integrada. Para saber como usar esse parâmetro de API, consulte Provisionar e usar o armazenamento em blocos brutos com suporte de SSD local. |
Suporte para parâmetros SSD locais atuais
A tabela a seguir resume esses parâmetros de SSD local atuais e os substitutos recomendados:
| Parâmetros do SSD local atuais | Comando da CLI gcloud | Perfil da SSD local | Versão recomendada do GA dos parâmetros de SSD local |
|---|---|---|---|
| Parâmetro de contagem do SSD local | gcloud container clusters create |
Tecnologia de armazenamento : SCSI Dados compartilhados entre pods: sim, via PVs locais Ciclo de vida dos dados: nó Tamanho e necessidade de configuração de RAID: 375 GiB. Você precisa configurar manualmente a RAID para tamanhos maiores. Formato: sistema de arquivos (ext-4) Integração do programador do Kubernetes: não por padrão. Você precisa garantir a capacidade dos nós e lidar com vizinhos barulhentos. Se você ativar o PV local, a programação será integrada. |
gcloud container clusters create |
| Parâmetro de armazenamento temporário (Beta) | gcloud beta container clusters create |
Tecnologia de armazenamento : NVMe Dados compartilhados entre pods: não Ciclo de vida dos dados: pod Tamanho e necessidade de configuração de RAID: até 9 TiB. O GKE configura automaticamente a RAID em segundo plano. Formato: sistema de arquivos (Kubernetes emptyDir) Integração do programador do Kubernetes: totalmente integrado por padrão. O programador do Kubernetes vai garantir espaço nos nós antes da posição e escalonar nós, se necessário. |
gcloud container clusters create |
| Parâmetro de volumes de SSD locais (Alfa) | gcloud alpha container clusters create |
Tecnologia de armazenamento : NVMe ou SCSI Dados compartilhados entre pods: não Ciclo de vida dos dados: nó Tamanho e necessidade de configuração de RAID: 375 GiB. Você precisa configurar a RAID manualmente para tamanhos maiores. Formato: sistema de arquivos (ext-4) ou bloco bruto Integração do programador do Kubernetes : não, por padrão, você precisa garantir a capacidade dos nós e lidar com vizinhos barulhentos. |
gcloud container clusters create |
Acesso ao SSD local
É possível acessar volumes SSD locais com um dos métodos a seguir.
volume emptyDir
Na versão 1.25.3-gke.1800 e mais recentes do GKE, é possível usar o armazenamento temporário como um
volume emptyDir
apoiado por SSDs locais, por meio da opção --ephemeral-storage-local-ssd. Recomendamos
essa abordagem na maioria dos casos, incluindo aplicativos que precisam de espaço temporário
de alto desempenho.
O GKE permite configurar um pool de nós para montar o armazenamento temporário de nós em SSD local com uma interface de NVMe.
Para saber mais, consulte este exemplo.
Volume permanente local
Um volume permanente local representa um disco local anexado a um único nó. Os volumes permanentes locais permitem compartilhar recursos SSD locais entre pods. Como o disco local é um SSD local, os dados ainda são temporários.
Recomendamos essa abordagem se alguma das seguintes situações for executada no seu cluster:
- cargas de trabalho que usam StatefulSets e volumeClaimTemplates;
- cargas de trabalho que compartilham pools de nós. Cada volume SSD local pode ser reservado por meio de um PersistentVolumeClaim, e HostPaths específicos não são codificados diretamente na especificação do pod.
- Pods que exigem gravidade de dados para o mesmo SSD local. Um pod sempre é programado para o mesmo nó que o respectivo PersistentVolume local.
Para saber mais, consulte este exemplo e a documentação de volumes de código aberto do Kubernetes.
Restrições
Seu aplicativo precisa lidar com a perda de acesso a dados em volumes SSD locais de maneira prática. Os dados gravados em um disco SSD local não permanecem quando o pod ou o nó é excluído, reparado, atualizado ou apresenta um erro irrecuperável.
O parâmetro SSD local de armazenamento temporário configura os volumes de SSD local para ter um ciclo de vida de dados baseado em pod, e o parâmetro de bloco de SSD local de NVMe configura os volumes de SSD locais para ter um ciclo de vida de dados baseado em nó.
Se você precisar de armazenamento permanente, recomendamos o uso de uma opção de armazenamento durável (como Persistent Disk, Filestore ou Cloud Storage). Também é possível usar réplicas regionais para minimizar o risco de perda de dados durante o ciclo de vida do cluster ou nas operações de ciclo de vida do aplicativo.
As definições de configuração de SSD local não poderão ser modificadas depois que o pool de nós for criado. Não é possível ativar, desativar ou atualizar a configuração de SSD local de um pool de nós atual. É necessário excluir o pool de nós e recriar um novo para fazer alterações.
Os pods que usam emptyDir usam o SSD local de forma transparente. No entanto, isso é verdadeiro para todos os pods em todos os nós desse pool. O GKE não aceita, no mesmo pool de nós, alguns pods que usam volumes emptyDir de SSD local apoiados por SSD local e outros pods que usam volumes emptyDir apoiados por um disco de inicialização de nós. Se você tiver cargas de trabalho que usam volumes emptyDir com um disco de inicialização de nós, programe as cargas de trabalho em um pool de nós diferente.
Os clusters do Autopilot e o provisionamento automático de nós não são compatíveis com SSDs locais.
Recomendamos o uso do SSD local como armazenamento temporário para cargas de trabalho em execução em VMs com otimização para armazenamento (Z3). Os nós Z3 são encerrados durante eventos de manutenção. Por isso, os dados no SSD local para esses nós podem não estar disponíveis durante os eventos de manutenção, e a recuperação de dados não é garantida após a manutenção.
A seguir
- Provisione e use o armazenamento temporário com suporte de SSD local.
- Provisione e use o armazenamento em blocos brutos de SSD local.