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 nó 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

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

gcloud

Para criar um cluster ou pool de nós com SSDs locais usando a 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 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:

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

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. Consulte SSDs locais. Quando os nós são criados, os SSDs locais são formatados e ativados automaticamente no SO do host no subdiretório /mnt/disks/, com cada SSD local ativado em um diretório "ssd#".

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, siga as etapas a seguir:

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

    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 pretendido 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 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 pretendido 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 de como usar volumes hostPath

Se você criar um pool de nós com três SSDs locais, o SO do host ativará 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"

Exemplo de como usar PersistentVolumes locais

É possível especificar os SSDs locais como PersistentVolumes.

Crie PersistentVolumes a partir de SSDs locais gerando 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.

O upgrade de um cluster do GKE ou a reparação de nós exclui as instâncias do Compute Engine, que também remove 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.

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 mencionar um SSD local em um nó específico. Por exemplo, o exemplo 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, será necessário 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 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 sua conta do Cloud Identity and Access Management ao papel de administrador de 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, ele criará um objeto PersistentVolume para cada SSD local no cluster.

Como ativar a vinculação de volume atrasada

Para garantir uma programação aprimorada, é recomendável criar também 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 seguinte manifesto StorageClass, local_class.yaml:

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