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, 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

É possível 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 discos SSD locais:

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Clique no botão Criar cluster.

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

  4. Em Número de nós, insira 2.

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

  6. Expanda o menu Plataforma de CPU e GPU.

  7. Em Discos SSD locais, digite o número desejado de SSDs como um número absoluto.

  8. Clique em Criar.

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

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Selecione o cluster pretendido.

  3. Clique em Editar.

  4. Em Pools de nós, clique em Adicionar pool de nós.

  5. Em Tamanho, digite 1.

  6. Em Discos SSD locais (por nó), digite o número desejado de SSDs como um número absoluto.

  7. Clique em Salvar.

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

em que number-of-disks é o número pretendido de discos como um número absoluto.

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

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.

Para acessar os SSDs locais, use um destes dois métodos:

  • Os volumes Hostpath 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.
  • PersistentVolumes locais estão geralmente disponíveis (GA, na sigla em inglês) no GKE v1.14.x ou posterior.

    Eles 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 (PVC), 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.

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. Faça backup dos dados do aplicativo primeiro e restaure os dados para um novo cluster ou pool de nós.

  • Os objetos PersistentVolume locais 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 (PVC) 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 PVC 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 chamado storageclass-name 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

A seguir