As unidades de disco de estado sólido (SSDs) locais são unidades SSD de tamanho fixo que podem ser montadas numa única VM do Compute Engine. Pode usar o SSD local no GKE para obter armazenamento de alto desempenho que não é persistente (efémero) e que está anexado a todos os nós no seu cluster. Os SSDs locais também oferecem um débito mais elevado e uma latência inferior à dos discos padrão.
Na versão 1.25.3-gke.1800 e posteriores, pode configurar um pool de nós do GKE para usar um SSD local com uma interface NVMe para armazenamento efémero local ou armazenamento de blocos não processados.
Se estiver a usar o GKE com clusters Standard, pode anexar volumes de SSD local a nós quando cria pools de nós. Isto melhora o desempenho do armazenamento efémero para as suas cargas de trabalho que usam volumes emptyDir ou volumes persistentes locais. Pode criar node pools com SSD local dentro dos limites do tipo de máquina do seu cluster e das quotas do seu projeto.
Um disco SSD local está associado apenas a um nó, e os próprios nós são efémeros. Uma carga de trabalho pode ser agendada para um nó diferente em qualquer altura.
Quando configura SSDs locais, o GKE monta automaticamente os seguintes diretórios no volume do SSD local para melhorar o desempenho: /var/lib/kubelet, /var/log/pods e /var/lib/containerd. Isto garante
um acesso mais rápido a dados kubelet críticos, registos de pods e ficheiros de tempo de execução de contentores.
Para mais informações sobre as vantagens e as limitações do SSD local, como o desempenho e o número permitido de discos SSD por tipo de máquina, consulte o artigo SSDs locais na documentação do Compute Engine.
Por que motivo deve escolher o SSD local para o GKE
O SSD local é uma boa escolha se as suas cargas de trabalho tiverem algum dos seguintes requisitos:
- Quer executar aplicações que transferem e processam dados, como IA ou aprendizagem automática, estatísticas, processamento em lote, colocação em cache local e bases de dados na memória.
- As suas aplicações têm necessidades de armazenamento especializadas e quer acesso a blocos não processados no armazenamento efémero de elevado desempenho.
- Quer executar aplicações de dados especializadas e operar volumes de SSD local como uma cache ao nível do nó para os seus pods. Pode usar esta abordagem para gerar um melhor desempenho para aplicações de base de dados na memória, como o Aerospike ou o Redis.
Armazenamento temporário
Recomendamos que use a opção --ephemeral-storage-local-ssd para aprovisionar o SSD local para o armazenamento efémero de nós (esta é a predefinição se estiver a usar uma série de máquinas de terceira geração).
Esta abordagem coloca os volumes emptyDir, as camadas graváveis por contentores e as imagens que, em conjunto, constituem o armazenamento efémero do nó no SSD local. As vantagens
incluem uma largura de banda de E/S melhorada em comparação com o Persistent Disk predefinido e tempos de arranque de pods melhorados.
A utilização de SSD local para o armazenamento efémero de nós significa que os volumes de SSD local do disco de arranque não estão disponíveis para outras utilizações. Não modifique os dispositivos SSD locais, como /dev/nvme*
diretamente através de um Daemonset privilegiado, HostPath ou outro mecanismo. Caso contrário,
o nó pode falhar.
Se precisar de um controlo detalhado sobre os volumes de SSD local, use a abordagem de blocos não processados.
Bloqueie o armazenamento do dispositivo
O bloqueio do armazenamento do dispositivo permite o acesso aleatório a dados em blocos de tamanho fixo. Algumas aplicações especializadas requerem acesso direto ao armazenamento do dispositivo porque, por exemplo, a camada do sistema de ficheiros introduz uma sobrecarga desnecessária.
Os cenários comuns para usar o armazenamento de dispositivos de blocos incluem o seguinte:
- Bases de dados onde os dados são organizados diretamente no armazenamento subjacente.
- Software que implementa algum tipo de serviço de armazenamento (sistemas de armazenamento definidos por software).
Na versão v1.25.3-gke.1800 e posteriores do GKE, pode criar clusters e pools de nós com SSDs NVMe locais de blocos não processados anexados, usando a opção --local-nvme-ssd-block. Em seguida, pode personalizar o armazenamento em blocos
formatando um sistema de ficheiros à sua escolha (como ZFS ou HDFS) e configurando o RAID. Esta opção é adequada se precisar de controlo adicional para executar cargas de trabalho que exijam especificamente acesso ao armazenamento de blocos suportado por SSD local.
Também pode usar a abordagem de bloqueio do acesso com o SSD local se quiser uma cache de dados unificada para partilhar dados entre pods e os dados estiverem associados a um ciclo de vida do nó. Para tal, instale um DaemonSet com uma configuração RAID, formate um sistema de ficheiros e use um PersistentVolume local para partilhar dados entre Pods.
Requisitos da máquina
A forma como aprovisiona o SSD local para os seus clusters e node pools do GKE depende do tipo de máquina subjacente. O GKE suporta volumes de SSD local nas séries de máquinas de primeira, segunda e terceira geração do Compute Engine. Os volumes de SSD local requerem o tipo de máquina n1-standard-1 ou superior.
O tipo de máquina predefinido, e2-medium, não é suportado.
Para identificar a série da máquina, 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 tipos e séries de máquinas disponíveis, consulte o recurso de famílias de máquinas e o guia de comparação na documentação do Compute Engine.
Requisitos da série de máquinas de primeira e segunda geração
Para usar uma série de máquinas de primeira ou segunda geração com SSD local, o cluster ou o conjunto de nós tem de estar a executar a versão 1.25.3-gke.1800 ou posterior do GKE.
Para aprovisionar um SSD local numa série de máquinas de primeira ou segunda geração, especifica o número de volumes de SSD local a usar com a sua VM. Para ver uma lista das séries de máquinas e o número permitido correspondente de SSDs locais, consulte a secção Escolher um número válido de SSDs locais na documentação do Compute Engine.
Requisitos da série de máquinas de terceira e quarta geração
Se quiser usar uma série de máquinas de terceira geração com SSD local, o cluster ou o conjunto de nós tem de estar a executar uma das seguintes versões do GKE ou posterior:
- 1.25.13-gke.200 para 1.26
- 1.26.8-gke.200 para 1.27
- 1.27.5-gke.200 para 1.28
- 1.28.1-gke.200 para 1.29
Se quiser usar uma série de máquinas de quarta geração com SSD local, o cluster ou o conjunto de nós tem de estar a executar uma das seguintes versões do GKE ou posterior:
- 1.32.1-gke.1357000
Para as séries de máquinas de terceira e quarta geração, cada tipo de máquina é pré-configurado sem SSD local ou com uma quantidade fixa de volumes de SSD local. Não especifica o número de volumes de SSD local a incluir. Em alternativa, a capacidade do disco SSD local disponível para os seus clusters é definida implicitamente como parte do formato da VM.
Para ver uma lista das séries de máquinas e o número permitido correspondente de SSDs locais, consulte o artigo Escolher um número válido de SSDs locais na documentação do Compute Engine.
Padrão de utilização para volumes de SSD local
Para usar volumes de SSD local nos seus clusters, siga estes passos gerais:
- Aprovisione um conjunto de nós com um SSD local associado: para criar um conjunto de nós do GKE com SSDs locais associados, transmita o parâmetro de armazenamento efémero ou de armazenamento em bloco não processado quando chamar o comando
create cluster. A definição dos parâmetros do SSD local cria um conjunto de nós do GKE com o SSD local anexado e configurado como armazenamento efémero local ou armazenamento em bloco não processado, consoante os parâmetros que escolher. Para saber mais sobre as opções de aprovisionamento do SSD local, consulte os parâmetros do SSD local. - Aceda aos dados dos volumes de SSD local: para usar os dados dos volumes de SSD local, pode usar uma construção do Kubernetes, como emptyDir ou volume persistente local. Para saber mais sobre estas opções, consulte o artigo Acesso a SSD local.
Parâmetros de SSD local no GKE
A tabela seguinte resume os parâmetros recomendados que o GKE fornece para o aprovisionamento do armazenamento SSD local em clusters. Pode usar a CLI gcloud para transmitir estes parâmetros.
| Tipo de SSD local | Comando da CLI gcloud | Disponibilidade do GKE | Perfil de SSD local |
|---|---|---|---|
| SSD local de armazenamento temporário | gcloud container clusters create |
v1.25.3-gke.1800 ou posterior |
Tecnologia de armazenamento: NVMe Dados partilhados entre pods: não Ciclo de vida dos dados: Pod Tamanho e necessidade de configuração RAID: até 9 TiB. O GKE configura automaticamente o RAID de forma transparente. Formato: sistema de ficheiros (emptyDir do Kubernetes) Integração do programador do Kubernetes: totalmente integrada por predefinição. O programador do Kubernetes garante espaço no nó antes do posicionamento e dimensiona os nós, se necessário. Para saber como usar este parâmetro da API, consulte o artigo Aprovisione e use o armazenamento efémero suportado por SSD local. |
| Bloco SSD NVMe local | gcloud container clusters create |
v1.25.3-gke.1800 ou posterior |
Tecnologia de armazenamento: NVMe Dados partilhados entre pods: sim, através de PVs locais. Ciclo de vida dos dados: nó Tamanho e necessidade de configuração RAID: até 9 TiB. Tem de configurar manualmente o RAID para tamanhos maiores. Formato: bloco não processado Integração do programador do Kubernetes: não, por predefinição. Tem de garantir a capacidade nos nós e lidar com vizinhos ruidosos. Se ativar a PV local, a programação é integrada. Para saber como usar este parâmetro da API, consulte o artigo Aprovisione e use o armazenamento de blocos não processados suportado por SSDs locais. |
Suporte para parâmetros de SSD local existentes
A tabela seguinte resume estes parâmetros de SSD local existentes e os respetivos substitutos recomendados:
| Parâmetros de SSD local existentes | Comando da CLI gcloud | Perfil de SSD local | Versão do GA recomendada dos parâmetros de SSD local |
|---|---|---|---|
| Parâmetro de contagem de SSDs locais | gcloud container clusters create |
Tecnologia de armazenamento: SCSI Dados partilhados entre pods: sim, através de PVs locais Ciclo de vida dos dados: nó Tamanho e necessidade de configuração RAID: 375 GiB. Tem de configurar manualmente o RAID para tamanhos maiores. Formato: sistema de ficheiros (ext-4) Integração do programador do Kubernetes: não por predefinição. Tem de garantir a capacidade nos nós e lidar com vizinhos ruidosos. Se ativar as PVs locais, a programação é integrada. |
gcloud container clusters create |
| Parâmetro de armazenamento temporário (beta) | gcloud beta container clusters create |
Tecnologia de armazenamento: NVMe Dados partilhados entre pods: não Ciclo de vida dos dados: Pod Tamanho e necessidade de configuração RAID: até 9 TiB. O GKE configura automaticamente o RAID de forma transparente. Formato: sistema de ficheiros (emptyDir do Kubernetes) Integração do programador do Kubernetes: totalmente integrada por predefinição. O programador do Kubernetes garante espaço nos nós antes do posicionamento e dimensiona os nós, se necessário. |
gcloud container clusters create |
| Parâmetro de volumes de SSD local (alfa) | gcloud alpha container clusters create |
Tecnologia de armazenamento: NVMe ou SCSI Dados partilhados entre pods: não Ciclo de vida dos dados: nó Tamanho e necessidade de configuração RAID: 375 GiB. Tem de configurar manualmente o RAID para tamanhos maiores. Formato: sistema de ficheiros (ext-4) ou bloco não processado Integração do programador do Kubernetes: não por predefinição. Tem de garantir a capacidade nos nós e processar os vizinhos ruidosos. |
gcloud container clusters create |
Acesso ao SSD local
Pode aceder a volumes de SSD local com um dos seguintes métodos.
Volume emptyDir
Na versão v1.25.3-gke.1800 e posteriores do GKE, pode usar o armazenamento efémero como um volume emptyDir com base no SSD local através da opção --ephemeral-storage-local-ssd. Recomendamos esta abordagem para a maioria dos casos, incluindo aplicações que precisam de espaço temporário de elevado desempenho.
O GKE permite-lhe configurar um conjunto de nós para montar o armazenamento efémero de nós no SSD local com uma interface NVMe.
Para saber mais, consulte este exemplo.
Volume persistente local
Um volume persistente local representa um disco local associado a um único nó. Os volumes persistentes locais permitem-lhe partilhar recursos de SSD local entre pods. Uma vez que o disco local é um disco SSD local, os dados continuam a ser efémeros.
Recomendamos esta abordagem se qualquer um dos seguintes elementos for executado no seu cluster:
- Cargas de trabalho que usam StatefulSets e volumeClaimTemplates.
- Cargas de trabalho que partilham node pools. Cada volume de SSD local pode ser reservado através de um PersistentVolumeClaim, e os HostPaths específicos não são codificados diretamente na especificação do pod.
- Pods que requerem gravidade dos dados para o mesmo SSD local. Um pod é sempre agendado para o mesmo nó que o respetivo PersistentVolume local.
Para saber mais, consulte este exemplo e a documentação de volumes do Kubernetes de código aberto.
Restrições
A sua aplicação tem de processar corretamente a perda de acesso aos dados em volumes de SSD local. Os dados escritos num disco SSD local não persistem quando o pod ou o nó é eliminado, reparado, atualizado ou sofre um erro irrecuperável.
O parâmetro SSD local de armazenamento efémero configura os volumes de SSD local para terem um ciclo de vida dos dados baseado em pods, e o parâmetro de bloco de SSD local NVMe configura os volumes de SSD local para terem um ciclo de vida dos dados baseado em nós.
Se precisar de armazenamento persistente, recomendamos que use uma opção de armazenamento duradoura (como o Persistent Disk, o Filestore ou o Cloud Storage). Também pode usar réplicas regionais para minimizar o risco de perda de dados durante o ciclo de vida do cluster ou as operações do ciclo de vida da aplicação.
Não é possível modificar as definições de configuração do SSD local após a criação do conjunto de nós. Não pode ativar, desativar nem atualizar a configuração do SSD local para um conjunto de nós existente. Tem de eliminar o conjunto de nós e voltar a criar um novo para fazer alterações.
Os pods que usam o emptyDir usam o SSD local de forma transparente. No entanto, isto aplica-se a todos os pods em todos os nós nesse conjunto de nós. O GKE não suporta ter, no mesmo conjunto de nós, alguns pods que usam volumes emptyDir de SSD local suportados por SSD local e outros pods que usam volumes emptyDir suportados por um disco de arranque do nó. Se tiver cargas de trabalho que usem volumes emptyDir suportados por um disco de arranque do nó, agende as cargas de trabalho num conjunto de nós diferente.
Os clusters do Autopilot e a administração de contas automática de nós não são suportados para SSDs locais.
Recomendamos a utilização do SSD local como armazenamento efémero para cargas de trabalho executadas em VMs otimizadas para armazenamento (Z3). A migração em direto é suportada para VMs Z3 com menos de 88 vCPUs, mas as VMs Z3 com 88 ou mais vCPUs são terminadas durante os eventos de manutenção. Para mais informações, consulte o artigo Experiência de manutenção para instâncias Z3. Uma vez que as VMs Z3 com 88 ou mais vCPUs são terminadas, os dados no SSD local para os 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. Para mais informações, consulte o artigo Persistência de disco após a terminação da instância.
O que se segue?
- Aprovisione e use o armazenamento efémero suportado por SSD local.
- Aprovisione e use o armazenamento em blocos simples suportado por SSD local.