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.

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. O armazenamento em cache e o processamento locais são cargas de trabalho adequadas para SSDs locais.

É possível criar pools de nós com SSDs locais dentro dos limites de tipo de máquina do cluster e das cotas do projeto.

Restrições

Esteja ciente das seguintes restrições ao usar SSDs locais:

  • Como os SSDs locais estão fisicamente anexados à instância da máquina virtual do host do nó, qualquer dado armazenado neles só existe nesse nó. Como os dados armazenados nos discos são locais, é preciso que o aplicativo seja resiliente se esses dados não estiverem disponíveis.
  • Os dados armazenados em SSDs locais são temporários. Um pod que grava em um SSD local pode perder o acesso aos dados armazenados no disco se for reprogramado para longe desse nó. Além disso, se o nó for encerrado, atualizado ou reparado, os dados serão apagados.
  • Não é possível adicionar SSDs locais a um pool de nós atual.

Como criar um cluster com SSDs locais

Crie um cluster com SSDs locais usando o Console do Google Cloud Platform ou a ferramenta de linha de comando gcloud.

gcloud

Para criar um cluster ou pool de nós com SSDs locais usando o gcloud, especifique a sinalização --local-ssd count.

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

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 existente:

gcloud beta container node-pools create [POOL_NAME] --cluster [CLUSTER_NAME] \
    --num-nodes 1 --local-ssd-count [NUMBER_OF_DISKS]

--local-ssd-count especifica o número de SSDs locais a serem criados por node. O número máximo varia por tipo de máquina e região. Consulte SSDs locais. Quando os nós são criados, os SSDs locais são automaticamente formatados e ativados no SO do host, no subdiretório /mnt/disks/. Cada SSD local é ativado em um diretório "ssd#".

Console

Crie um cluster ou pool de nós com SSDs locais no menu do GKE no Console do GCP.

Para criar um cluster em que o pool padrão usa discos SSD locais, siga as etapas a seguir:

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

    Acessar o menu do Google Kubernetes Engine

  2. Clique em Criar cluster.

  3. Em Pools de nós, clique em Edição avançada.

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

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

  6. Clique em Salvar e, em seguida, em Criar.

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

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

    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.

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.
  • Os PersistentVolumes locais (em inglês) estão disponíveis na versão Beta e 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.

Exemplo usando volumes hostPath

Se você criar um pool de nós com três SSDs locais, os discos serão ativados no SO do host em /mnt/disks/ssd0, /mnt/disks/ssd1 e /mnt/disks/ssd2. Os 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 faz referência 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"

Exemplo de uso de 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.

Advertências

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

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, em seguida, restaure os dados para um novo cluster ou pool de nós.

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 fazer referência a um SSD local em um nó específico. Por exemplo, veja a seguir uma especificação de PersistentVolume para um SSD local ativado em /mnt/disks/ssd0 no nó gke-test-cluster-default-pool-926ddf80-f166:

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"

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 download da especificação provisioner_generated_gce_ssd_count.yaml do repositório de armazenamento externo (em inglês) e modifique os campos namespace, 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. Vincule a conta do IAM ao papel de Administrador do cluster do Kubernetes. Isso é necessário para receber permissões de criação do ClusterRole.

  3. Implante o provisionador:

    kubectl apply -f provisioner_generated_gce_ssd_count.yaml

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

Como ativar a vinculação de volume atrasada

Para melhorar a programação, é recomendável também criar um StorageClass com volumeBindingMode: WaitForFirstConsumer. Isso atrasará 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.

Por exemplo, considere o manifesto StorageClass local_class.yaml a seguir:

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

Para criar um StorageClass com vinculação atrasada, execute o comando a seguir:

kubectl apply -f local_class.yaml

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine