Como usar SSDs locais


Nesta página, você encontra uma visão geral do suporte a SSDs locais no Kubernetes e como usá-los com o Google Kubernetes Engine (GKE).

Visão geral

Os SSDs locais fornecem armazenamento temporário de alto desempenho para cada node no cluster. Eles oferecem maior capacidade e menor latência que os discos padrão. Os SSDs locais funcionam bem em cargas de trabalho que fornecem armazenamento em cache e processamento 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.

  • Os dados gravados em um SSD local são temporários e não permanecem quando o nó é excluído, reparado, atualizado ou ocorre um erro irrecuperável.

  • Um 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 SSDs por tipo de máquina, consulte SSDs locais na documentação do Compute Engine.

Como criar um cluster com SSDs locais

É possível criar ou atualizar um cluster para usar SSDs locais usando o Console do Google Cloud ou a ferramenta de linha de comando gcloud.

Console

Você pode criar um cluster ou pool de nós com SSDs locais no menu do GKE no Console do Cloud.

Para criar um cluster em que o pool padrão usa SSDs locais:

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud.

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  3. Configure o cluster como quiser.

  4. No painel de navegação, em Pools de nós, clique em default-pool.

  5. No campo Número de nós digite 2.

  6. No painel de navegação, em default-pool, clique em Nós.

  7. Digite um número absoluto de discos SSD locais desejados por nó.

  8. Clique em Criar.

Para criar um pool de nós com discos SSD locais em um cluster atual:

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud.

    Acessar o Google Kubernetes Engine

  2. Na lista de clusters, clique no nome do cluster que você quer modificar.

  3. Clique em Adicionar pool de nós.

  4. No campo Número de nós digite 1.

  5. No painel de navegação, clique em Nós.

  6. Digite um número absoluto de discos SSD locais desejados por nó.

  7. Clique em Criar.

gcloud

Para criar um cluster ou pool de nós com SSDs locais usando gcloud, especifique a sinalização --local-ssd count. O --local-ssd-count especifica o número de SSDs locais a serem criados por nó. O número máximo varia por tipo de máquina e região. Quando os nós são criados, os SSDs locais são formatados e ativados automaticamente no sistema de arquivos do nó em pontos de ativação, como /mnt/disks/ssd0 para o primeiro disco, /mnt/disks/ssd1 para o segundo disco e assim por diante.

Para criar um cluster em que o pool padrão usa discos SSD locais, execute o comando abaixo:

gcloud container clusters create CLUSTER_NAME \
  --num-nodes 2 \
  --local-ssd-count NUMBER_OF_DISKS \
  --machine-type MACHINE_TYPE

Para criar um pool de nós com discos SSD locais em um cluster atual, execute o seguinte comando:

gcloud container node-pools create POOL_NAME \
  --cluster CLUSTER_NAME \
  --num-nodes 1 \
  --local-ssd-count NUMBER_OF_DISKS \
  --machine-type MACHINE_TYPE

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • POOL_NAME: o nome do novo pool de nós.
  • NUMBER_OF_DISKS: o número dos discos SSD locais a serem provisionados em cada nó.
  • MACHINE_TYPE: o tipo de máquina a ser usado, porque SSDs locais não podem ser usados com o tipo e2-medium padrão

Como criar um pool de nós usando armazenamento temporário em SSDs locais

A partir de 1.18, é possível configurar um pool de nós do GKE para usar o SSD local em armazenamento temporário.

Para criar um pool de nós usando o armazenamento temporário em SSDs locais, execute o comando a seguir:

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

Substitua:

  • POOL_NAME: o nome do novo pool de nós.
  • NUMBER_OF_DISKS: o número dos discos SSD locais a serem provisionados em cada nó. Esses SSDs são combinados em um único volume lógico durante a configuração do nó. O número máximo de discos varia por tipo de máquina e região.
  • MACHINE_TYPE: o tipo de máquina a ser usado, porque SSDs locais não podem ser usados com o tipo e2-medium padrão.

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

kubectl describe node NODE_NAME

Como formatar SSDs locais para clusters do Windows Server

Ao usar SSDs locais com seus clusters que executam pools de nós do Windows Server, é possível fazer login no nó e formatar o disco antes de usá-lo. No exemplo a seguir, o disco SSD local é formatado com o sistema de arquivos NTFS. Também é possível criar diretórios no disco. 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-ss

Como usar SSDs locais

Na seção a seguir, explicamos como usar os SSDs locais com o GKE.

É possível acessar SSDs locais com um dos seguintes métodos:

  • Usando volumes hostpath, que são recomendados para:

    • cargas de trabalho que usam DaemonSets;
    • cargas de trabalho que usam pools de nós dedicados. Todos os SSDs locais precisam ser acessados no mesmo caminho em todas as instâncias de um DaemonSet.
  • usando local PersistentVolumes, que são recomendados para:

    • cargas de trabalho que usam StatefulSets e volumeClaimTemplates;
    • cargas de trabalho que compartilham pools de nós. Cada SSD local pode ser reservado por meio de um PersistentVolumeClaim, e caminhos de host 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.
  • Usando armazenamento temporário como um volumeemptyDir (disponível em versão Beta no GKE versão 1.18 e posteriores), que é recomendado para:

    • Aplicativos que precisam de espaço transitório temporário de alto desempenho.

    Esse recurso configura um pool de nós para ativar o armazenamento temporário do nó no SSD local. 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. Não é possível que alguns pods usem volumes emptyDir SSD locais e outros usem emptyDir convencionais. Para cargas de trabalho que não podem usar volumes emptyDir convencionais, programe essas cargas de trabalho em um pool de nós diferente.

Exemplos com volumes hostPath

Nos exemplos a seguir, veja como usar os volumes do hostPath para Windows e Linux.

Linux

Se você criar um pool de nós com três SSDs locais, o SO host montará os discos em /mnt/disks/ssd0, /mnt/disks/ssd1 e /mnt/disks/ssd2. Seus contêineres do Kubernetes acessam os discos usando o parâmetro hostPath, definido no arquivo de configuração do objeto.

Este exemplo de arquivo de configuração de pod refere-se a um SSD local: /mnt/disks/ssd0:

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "shell"
    image: "ubuntu:14.04"
    command: ["/bin/sh", "-c"]
    args: ["echo 'hello world' > /test-ssd/test.txt && sleep 1 && cat /test-ssd/test.txt"]
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    hostPath:
      path: "/mnt/disks/ssd0"
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"

Windows

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "test"
    image: "mcr.microsoft.com/windows/servercore/iis"
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    hostPath:
      path: "d:\\test-ssd"
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"
    kubernetes.io/os: windows

Exemplos com PersistentVolumes locais

É possível especificar os SSDs locais como PersistentVolumes.

Crie PersistentVolumes a partir de SSDs locais fazendo manualmente um PersistentVolume ou executando o provisionador estático do volume local.

Limitações

  • No momento, o escalonamento automático de clusters e o provisionamento dinâmico não são compatíveis com PersistentVolumes locais.

  • A atualização de um cluster do GKE ou a reparação de nós exclui as instâncias do Compute Engine, que também exclui todos os dados nos SSDs locais.

  • Não ative upgrades automáticos ou reparos automáticos de nós em clusters ou pools de nós que usam SSDs locais para armazenar dados permanentes. Primeiro, faça backup dos dados do aplicativo e, só então, restaure os dados para um novo cluster ou pool de nós. Ao usar canais de lançamento, o upgrade automático e o reparo automático não podem ser desativados. Não é recomendado usar PersistentVolumes locais com clusters em um canal de lançamento.

  • Os objetos do PersistentVolume local não são limpos automaticamente quando um nó é excluído, atualizado, reparado ou reduzido. Recomendamos que você verifique e exclua periodicamente objetos obsoletos do PersistentVolume local associados a nós excluídos.

Como criar manualmente o PersistentVolume

Crie manualmente um PersistentVolume para cada SSD local em cada nó no cluster.

Use o campo nodeAffinity em um objeto PersistentVolume para referir-se a um SSD local em um nó específico. Por exemplo, o exemplo a seguir do Linux é uma especificação PersistentVolume para um SSD local ativado em /mnt/disks/ssd0 no nó gke-test-cluster-default-pool-926ddf80-f166:

Linux

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - "ReadWriteOnce"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "/mnt/disks/ssd0"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values: "gke-test-cluster-default-pool-926ddf80-f166"

Windows

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ssd-local-pv
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: "d:\\test-ssd"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - gke-gke-cluster-windows-dds-2263bc7c-wq6m
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: ssd-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: local-storage
  resources:
    requests:
      storage: 37Gi

Agora é possível criar um pod para acessar o disco. Para garantir que seus pods sejam programados corretamente nos nós do Windows Server, você precisa adicionar um seletor de nós às especificações do pod:

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "test"
    image: "mcr.microsoft.com/windows/servercore/iis"
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    persistentVolumeClaim:
      claimName: ssd-local-claim
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"
  tolerations:
  - key: "node.kubernetes.io/os"
    value: "windows"
    operator: "Equal"
    effect: "NoSchedule"

Se você excluir o PersistentVolume, precisará apagar os dados manualmente do disco.

Como executar o provisionador estático do volume local

Crie PersistentVolumes para SSDs locais automaticamente usando o provisionador estático do volume local. O provisionador é um DaemonSet que gerencia os SSDs locais em cada nó, cria e exclui os PersistentVolumes deles e limpa os dados no SSD local quando o PersistentVolume é liberado.

Para executar o provisionador estático do volume local:

  1. Faça o download da especificação do gke.yaml no sig-storage-local-static-provisioner repo e modifique os campos namespace da especificação, conforme necessário.

    A especificação inclui:

    • a ServiceAccount do provisionador
    • ClusterRole e ClusterRoleBindings para permissões para:
      • criar e excluir objetos PersistentVolume
      • receber objetos Get Node
    • ConfigMap com configurações do provisionador para o GKE
    • DaemonSet para executar o provisionador
  2. Implante o provisionador:

    kubectl apply -f gke.yaml
    

Depois que o provisionador estiver em execução, ele criará um objeto PersistentVolume para cada SSD local no cluster.

Como ativar a vinculação de volume atrasada

Para uma programação aprimorada, recomenda-se criar também um StorageClass com volumeBindingMode: WaitForFirstConsumer. Isso atrasa a vinculação do PersistentVolumeClaim até a programação do pod. Assim, um SSD local será escolhido em um nó apropriado que possa executar o pod. Esse comportamento de programação aprimorado significa que as solicitações de CPU e memória do pod, afinidade do nó, afinidade e antiafinidade do pod e várias solicitações de PersistentVolumeClaim são consideradas com os nós que têm SSDs locais disponíveis, ao selecionar um nó para um pod executável.

Neste exemplo, é usado o modo de vinculação de volume atrasada:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "local-scsi"
provisioner: "kubernetes.io/no-provisioner"
volumeBindingMode: "WaitForFirstConsumer"

Ao usar clusters com pools de nós do Windows Server, você precisa criar um StorageClass porque o StorageClass padrão usa ext4 como o tipo de sistema de arquivos que só funciona para contêineres do Linux.

O arquivo YAML a seguir usa um disco permanente do Compute Engine com NTFS como o tipo de armazenamento de arquivos. Use esse StorageClass ao trabalhar com clusters do Windows.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storageclass-name
parameters:
  type: pd-standard
  fstype: NTFS
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Para criar um StorageClass com vinculação atrasada, salve o manifesto YAML em um arquivo local e aplique-o ao cluster usando o seguinte comando:

kubectl apply -f filename

Exemplo de uso do armazenamento temporário como volume emptyDir

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

Veja um exemplo de arquivo YAML para um pod que usa um emptyDir e um seletor de nó de cloud.google.com/gke-ephemeral-storage-local-ssd. É possível aplicar uma técnica semelhante para implantações ou StatefulSets.

apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
spec:
  containers:
    - name: CONTAINER_NAME
      image: "k8s.gcr.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: {}

A seguir