Provisionar e usar armazenamento temporário via SSD local

Nesta página, explicamos como provisionar armazenamento SSD local nos clusters do Google Kubernetes Engine (GKE) e como configurar cargas de trabalho para consumir dados do armazenamento temporário via SSD local anexado aos nós no cluster.

Para saber mais sobre o suporte ao SSD local no GKE, consulte Sobre o armazenamento SSD local.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

Criar um cluster ou pool de nós com armazenamento temporário via SSD local

Use a CLI do Google Cloud para criar um cluster ou pool de nós com armazenamento temporário via SSD local.

Use a opção --ephemeral-storage-local-ssd para anexar o armazenamento temporário local totalmente gerenciado por volumes SSD locais. Esse armazenamento é vinculado ao ciclo de vida dos pods. Quando os pods solicitam armazenamento temporário, o GKE programa-os para serem executados em nós que tenham volumes SSD locais configurados como armazenamento temporário. Se você quiser um controle mais especializado ou granular sobre os SSDs locais, recomendamos o uso do armazenamento em blocos bruto com suporte de SSD local.

Se o escalonamento automático de clusters estiver ativado, o GKE fará o escalonamento automático dos nós quando o cluster precisar de mais espaço de armazenamento temporário. Seus pods podem acessar dados em volumes SSD locais pelo volume emptyDir.

O comando da gcloud CLI que você executa para criar o cluster ou o pool de nós depende da geração da série do tipo de máquina selecionado. Por exemplo, os tipos de máquina N1 e N2 pertencem a uma série de primeira e segunda geração, respectivamente, enquanto os tipos de máquina C3 pertencem a uma série de terceira geração.

Criar um cluster com SSD local

1ª ou 2ª geração

Se você estiver usando um tipo de máquina com uma série de primeira ou segunda geração, crie seu cluster especificando a opção --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS. Essa opção provisiona o número especificado de volumes SSD locais em cada nó a ser usado para armazenamento temporário do kubelet.

Essas configurações se aplicam apenas ao pool de nós padrão. Se os pools de nós subsequentes precisarem de SSD local, especifique isso durante a criação do pool de nós.

Para criar um cluster em execução no GKE versão 1.25.3-gke.1800 ou posterior em que o pool padrão usa volumes SSD locais, execute o seguinte comando:

gcloud container clusters create CLUSTER_NAME \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS \
    --machine-type=MACHINE_TYPE \
    --release-channel CHANNEL_NAME

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • NUMBER_OF_DISKS: o número dos volumes SSD locais a serem provisionados em cada nó. Esses volumes são combinados em um único volume lógico durante a configuração do nó. O número máximo de volumes varia de acordo com o tipo de máquina e região. Lembre-se que uma parte da capacidade do SSD local é reservada para uso do sistema.
  • MACHINE_TYPE: o tipo de máquina a ser usado. Esse campo é obrigatório, já que o SSD local não pode ser usado com o tipo e2-medium padrão.
  • CHANNEL_NAME: um canal de lançamento que inclui versões do GKE posteriores à 1.25.3-gke.1800. Se preferir não usar um canal de lançamento, use a flag --cluster-version no lugar de --release-channel, especificando uma versão válida posterior à 1.25.3-gke.1800. Para determinar as versões válidas, use o comando gcloud container get-server-config.

3ª ou 4ª geração

Se você usar um tipo de máquina com uma série de terceira ou quarta geração, não precisará especificar uma opção de SSD local ao criar um cluster. O número de discos anexados a cada nó depende do tipo de máquina.

Para criar um cluster, execute o seguinte comando:

gcloud container clusters create CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --cluster-version CLUSTER_VERSION

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • MACHINE_TYPE: o tipo de máquina a ser usado com uma série de terceira ou quarta geração.
  • CLUSTER_VERSION: uma versão do cluster do GKE que permite SSD local em tipos de máquina com uma série de terceira ou quarta geração.

Criar um pool de nós com SSD local

1ª ou 2ª geração

Para criar um pool de nós em execução no GKE versão 1.25.3-gke.1800 ou posterior que usa volumes SSD locais, execute o seguinte comando:

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS \
    --machine-type=MACHINE_TYPE

Substitua:

  • POOL_NAME: o nome do novo pool de nós.
  • CLUSTER_NAME: o nome do cluster.
  • NUMBER_OF_DISKS: o número dos volumes SSD locais a serem provisionados em cada nó. Esses volumes são combinados em um único volume lógico durante a configuração do nó. O número máximo de volumes varia de acordo com o tipo de máquina e região. Lembre-se que uma parte da capacidade do SSD local é reservada para uso do sistema.
  • MACHINE_TYPE: o tipo de máquina a ser usado. Esse campo é obrigatório, já que o SSD local não pode ser usado com o tipo e2-medium padrão.

3ª ou 4ª geração

Se você usar um tipo de máquina com uma série de terceira ou quarta geração, não precisará especificar uma opção de SSD local ao criar um pool de nós. O número de volumes anexados a cada nó depende do tipo de máquina.

Para criar um pool de nós, execute o comando a seguir:

gcloud container node-pools create POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --node-version NODE_VERSION

Substitua:

  • POOL_NAME: o nome do novo pool de nós.
  • CLUSTER_NAME: o nome do cluster.
  • MACHINE_TYPE: o tipo de máquina a ser usado com uma série de terceira ou quarta geração.
  • NODE_VERSION: uma versão do pool de nós do GKE que permite SSD local em tipos de máquina com uma série de terceira ou quarta geração.

Os nós no pool de nós são criados com um rótulo cloud.google.com/gke-ephemeral-storage-local-ssd=true. Você pode verificar os rótulos executando o seguinte comando:

kubectl describe node NODE_NAME

Usar armazenamento temporário com SSD local com clusters do Autopilot

É possível usar SSDs locais para armazenamento temporário ao configurar seus pods de uma das seguintes maneiras:

  • Você seleciona explicitamente uma série de máquinas para executar seus pods e especifica o nodeSelector cloud.google.com/gke-ephemeral-storage-local-ssd: "true" ou uma reserva de capacidade com SSDs locais. Para saber mais sobre a seleção de séries de máquinas no Autopilot, consulte Otimizar o desempenho do pod do Autopilot escolhendo uma série de máquinas.
  • Você solicita um tipo de GPU compatível com SSDs locais e especifica o nodeSelector cloud.google.com/gke-ephemeral-storage-local-ssd: "true" ou uma reserva de capacidade com SSDs locais. As GPUs NVIDIA H100 (80 GB) e NVIDIA A100 (80 GB) sempre usam SSDs locais para armazenamento temporário, e não é possível especificar o seletor de nós para essas GPUs. Para saber mais sobre como solicitar GPUs no Autopilot, consulte Solicitar GPUs nos seus contêineres.

Consulte Séries de máquinas que oferecem suporte a SSD local no Autopilot para conferir uma lista de séries de máquinas compatíveis com SSDs locais.

Solicitar SSDs locais diretamente nos manifestos de carga de trabalho

Se quiser usar o SSD local para armazenamento temporário, adicione o nodeSeletor da cloud.google.com/gke-ephemeral-storage-local-ssd: "true" ao seu manifesto de carga de trabalho. Por exemplo, o manifesto de pod a seguir seleciona SSDs locais como armazenamento temporário para pods de GPU:

apiVersion: v1
kind: Pod
metadata:
  name: l4-localssd-pod
spec:
  containers:
  - name: my-gpu-container
    image: nvidia/cuda:11.0.3-runtime-ubuntu20.04
    command: ["/bin/bash", "-c", "--"]
    args: ["while true; do sleep 600; done;"]
    resources:
      requests:
        cpu: 16
        memory: 64Gi
        ephemeral-storage: 800Gi
      limits:
       cpu: 16
       memory: 64Gi
       ephemeral-storage: 800Gi
       nvidia.com/gpu: 8
  nodeSelector:
    cloud.google.com/gke-accelerator: nvidia-l4
    cloud.google.com/gke-ephemeral-storage-local-ssd: "true"

Solicitar SSDs locais com reservas de capacidade

Se você usar uma reserva de capacidade do Compute Engine para reservar máquinas com SSDs locais, o Autopilot vai anexar os SSDs locais disponíveis da reserva aos seus nós. Não é necessário selecionar explicitamente os SSDs locais no manifesto da carga de trabalho. Para saber mais sobre como usar reservas com o Autopilot, consulte Consumir reservas de capacidade em clusters do Autopilot.

Por exemplo, o manifesto de pod a seguir seleciona uma reserva específica com SSDs locais:

apiVersion: v1
kind: Pod
metadata:
  name: local-ssd-pod
spec:
  nodeSelector:
    cloud.google.com/machine-family: MACHINE_SERIES
    cloud.google.com/reservation-name: localssd-count-reservation
    cloud.google.com/reservation-affinity: "specific"
  containers:
  - name: my-container
    image: "k8s.gcr.io/pause"
    resources:
      requests:
        cpu: 6
        memory: "25Gi"
        ephemeral-storage: "100Gi"
      limits:
        cpu: 12
        memory: "50Gi"
        ephemeral-storage: "200Gi"

Substitua MACHINE_SERIES por uma série de máquinas compatível que também ofereça suporte a SSDs locais. Se a série de máquinas especificada não oferecer suporte a SSDs locais, a implantação falhará com um erro.

Séries de máquinas que oferecem suporte a SSD local no Autopilot

Os clusters do Autopilot oferecem suporte ao uso de SSDs locais para armazenamento temporário com as seguintes séries de máquinas:

(somente com reserva de capacidade)
(somente com reserva de capacidade)
(somente com reserva de capacidade)
(somente com reserva de capacidade)
(somente com reserva de capacidade)
(sempre em pacote)
(somente com reserva de capacidade)
(sempre em pacote)
(sempre em pacote)

Como usar o parâmetro de API legada

A opção --local-ssd-count é um parâmetro de API legada compatível com o SSD local SCSI. A série de máquina de terceira geração do Compute Engine não é compatível com SCSI e só permite NVMe. Use essa opção somente com clusters do Windows Server. Se você estiver usando o parâmetro de API legada em clusters do Linux, recomendamos que use a opção --ephemeral-storage-local-ssd.

SSD local em clusters do Windows Server

Ao usar SSD local com seus clusters que executam pools de nós do Windows Server, é possível fazer login no nó e formatar o volume antes de usá-lo. No exemplo a seguir, o volume SSD local é formatado com o sistema de arquivos NTFS. Também é possível criar diretórios no volume. Neste exemplo, os diretórios estão no disco D.

PS C:\> Get-Disk | Where partitionstyle -eq 'raw' | Initialize-Disk -PartitionStyle MBR -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem ntfs -Confirm:$false
PS C:\> mkdir D:\test-ssd

Acessar volumes SSD locais

O exemplo a seguir mostra como acessar o armazenamento temporário via SSD local.

Armazenamento temporário como um volume emptyDir

Um pool de nós do GKE pode ser configurado para usar o SSD local para armazenamento temporário, incluindo volumes emptyDir.

O manifesto do pod a seguir usa um emptyDir e um seletor de nós de cloud.google.com/gke-ephemeral-storage-local-ssd. Aplique uma técnica semelhante aos manifestos de implantação ou aos manifestos StatefulSet.

Ao escolher a solicitação de recurso de armazenamento temporário, considere a capacidade do SSD local reservada para uso do sistema.

apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
spec:
  containers:
    - name: CONTAINER_NAME
      image: "registry.k8s.io/pause"
      resources:
        requests:
          ephemeral-storage: "200Gi"
      volumeMounts:
        - mountPath: /cache
          name: scratch-volume
  nodeSelector:
    cloud.google.com/gke-ephemeral-storage-local-ssd: "true"
  volumes:
    - name: scratch-volume
      emptyDir: {}

Solução de problemas

Para instruções sobre solução de problemas, consulte Como resolver problemas de armazenamento no GKE.

A seguir