Acessar instâncias do Managed Lustre no GKE com o driver CSI do Managed Lustre

Este guia descreve como criar um novo volume do Kubernetes com suporte do driver CSI do Managed Lustre no GKE com provisionamento dinâmico. O driver CSI do Managed Lustre permite criar armazenamento com instâncias do Managed Lustre sob demanda e acessá-las como volumes para cargas de trabalho com estado.

Suporte a várias NICs para redes de alta performance

Para clusters do GKE que executam a versão 1.35.2-gke.1842000 ou mais recente, o driver CSI do Managed Lustre é ativado por padrão para usar todas as placas de interface de rede (NICs, na sigla em inglês) disponíveis para aumentar a capacidade de processamento. Esse suporte agrega largura de banda distribuindo o tráfego de armazenamento TCP nas interfaces de rede.

Para usar o suporte a várias NICs, os nós precisam atender aos seguintes requisitos:

  • NICs padrão para TCP: os nós precisam usar NICs padrão, como o Google Virtual NIC (gVNIC) ou o VirtIO-Net, para processar o tráfego de armazenamento TCP.
  • Mesma VPC: todas as NICs padrão precisam residir na mesma rede VPC.
  • Considerações sobre RDMA:os nós também podem ter NICs RDMA anexadas. No entanto, o driver CSI do Managed Lustre usa apenas as NICs padrão para tráfego de armazenamento TCP.

Se você quiser desativar o suporte a várias NICs, consulte Desativar várias NICs para o Lustre.

Portas de comunicação do Lustre

O driver CSI do GKE Managed Lustre usa portas diferentes para comunicação com instâncias do Managed Lustre, dependendo da versão do cluster do GKE e das configurações do Managed Lustre.

  • Porta padrão (recomendada) : para novos clusters do GKE que executam a versão 1.33.2-gke.4780000 ou mais recente, o driver usa a porta 988 para comunicação do Lustre por padrão.

  • Porta legada (descontinuada) : use a porta 6988 anexando a flag --enable-legacy-lustre-port aos comandos gcloud nos seguintes cenários:

    • Versões anteriores do GKE:se o cluster do GKE executar uma versão anterior à 1.33.2-gke.4780000, a flag --enable-legacy-lustre-port vai resolver um conflito de porta com o gke-metadata-server em nós do GKE.
    • Instâncias do Lustre atuais:se você estiver se conectando a uma instância do Managed Lustre criada com a flag gke-support-enabled, ainda é necessário incluir --enable-legacy-lustre-port nos comandos gcloud, independentemente da versão do cluster. Sem essa flag, o cluster do GKE não vai conseguir montar a instância do Lustre.

É possível configurar os clusters novos e atuais para usar a porta padrão 988 ou a porta legada 6988.

Antes de começar

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

  • Ative a API Google Cloud Managed Lustre e a API Google Kubernetes Engine.
    • Ativar APIs
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. 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.

Configurar variáveis de ambiente

Configure as seguintes variáveis de ambiente:

export CLUSTER_NAME=CLUSTER_NAME
export PROJECT_ID=PROJECT_ID
export NETWORK_NAME=LUSTRE_NETWORK
export IP_RANGE_NAME=LUSTRE_IP_RANGE
export FIREWALL_RULE_NAME=LUSTRE_FIREWALL_RULE
export LOCATION=ZONE
export CLUSTER_VERSION=CLUSTER_VERSION

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • PROJECT_ID: o ID do seu Google Cloud projeto.
  • LUSTRE_NETWORK: a rede de nuvem privada virtual (VPC) compartilhada em que o cluster do GKE e a instância do Managed Lustre residem.
  • LUSTRE_IP_RANGE: o nome do intervalo de endereços IP criado para o peering de rede VPC com o Managed Lustre.
  • LUSTRE_FIREWALL_RULE: o nome da regra de firewall para permitir o tráfego TCP do intervalo de endereços IP.
  • ZONE: a zona geográfica do cluster do GKE, por exemplo, us-central1-a.
  • CLUSTER_VERSION: a versão do cluster do GKE.

Configurar uma rede VPC

É necessário especificar a mesma rede VPC ao criar a instância do Managed Lustre e os clusters do GKE ou conectados pelo Network Connectivity Center se você estiver usando uma rede VPC com peering.

  1. Para ativar a rede de serviços, execute o seguinte comando:

    gcloud services enable servicenetworking.googleapis.com \
    --project=${PROJECT_ID}

  2. Criar uma rede VPC. Definir a flag --mtu como 8896 resulta em um ganho de performance de 10%.

    gcloud compute networks create ${NETWORK_NAME} \
    --subnet-mode=auto --project=${PROJECT_ID} \
    --mtu=8896

  3. Crie um intervalo de endereços IP.

    gcloud compute addresses create ${IP_RANGE_NAME} \
    --global \
    --purpose=VPC_PEERING \
    --prefix-length=20 \
    --description="Managed Lustre VPC Peering" \
    --network=${NETWORK_NAME} \
    --project=${PROJECT_ID}

  4. Receba o intervalo CIDR associado ao intervalo criado na etapa anterior.

    CIDR_RANGE=$(
  gcloud compute addresses describe ${IP_RANGE_NAME} \
      --global  \
      --format="value[separator=/](address, prefixLength)" \
      --project=${PROJECT_ID}
)

  5. Crie uma regra de firewall para permitir o tráfego TCP do intervalo de endereços IP criado.

    gcloud compute firewall-rules create ${FIREWALL_RULE_NAME} \
    --allow=tcp:988,tcp:6988 \
    --network=${NETWORK_NAME} \
    --source-ranges=${CIDR_RANGE} \
    --project=${PROJECT_ID}

  6. Para configurar o peering de rede do seu projeto, verifique se você tem as permissões necessárias do IAM, especificamente o papel compute.networkAdmin ou servicenetworking.networksAdmin.

    1. Acesse o Google Cloud console > IAM e administrador e pesquise a principal do proprietário do projeto.
    2. Clique no ícone de lápis e em + ADICIONAR OUTRO PAPEL.
    3. Selecione Administrador de rede do Compute ou Administrador de rede de serviços.
    4. Clique em Salvar.

  7. Conecte o peering.

    gcloud services vpc-peerings connect \
    --network=${NETWORK_NAME} \
    --project=${PROJECT_ID} \
    --ranges=${IP_RANGE_NAME} \
    --service=servicenetworking.googleapis.com

Configurar o driver CSI do Managed Lustre

Esta seção aborda como ativar e desativar o driver CSI do Managed Lustre.

Ativar o driver CSI do Managed Lustre em um novo cluster do GKE

As seções a seguir descrevem como ativar o driver CSI do Managed Lustre em um novo cluster do GKE.

Usar a porta padrão 988

Para ativar o driver CSI do Managed Lustre ao criar um novo cluster do GKE que executa a versão 1.33.2-gke.4780000 ou mais recente, execute o seguinte comando:

Autopilot

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver

Padrão

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver

Usar a porta legada 6988

Para ativar o driver CSI do Managed Lustre ao criar um novo cluster do GKE que executa uma versão anterior à 1.33.2-gke.4780000, execute o seguinte comando:

Autopilot

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver \
    --enable-legacy-lustre-port

Padrão

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver \
    --enable-legacy-lustre-port

Ativar o driver CSI do Managed Lustre em clusters do GKE atuais

As seções a seguir descrevem como ativar o driver CSI do Managed Lustre em clusters do GKE atuais.

Usar a porta padrão 988

Para ativar o driver CSI do Managed Lustre em um cluster do GKE atual que executa a versão 1.33.2-gke.4780000 ou mais recente, execute o seguinte comando:

  gcloud container clusters update ${CLUSTER_NAME} \
      --location=${LOCATION} \
      --update-addons=LustreCsiDriver=ENABLED

Usar a porta legada 6988

Para ativar o driver CSI do Managed Lustre em um cluster do GKE atual, talvez seja necessário usar a porta legada 6988 adicionando a flag --enable-legacy-lustre-port. Essa flag é necessária nos seguintes cenários:

  • Se o cluster do GKE executar uma versão anterior à 1.33.2-gke.4780000.

  • Se você pretende conectar esse cluster a uma instância do Managed Lustre criada com a gke-support-enabled flag.

    gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-legacy-lustre-port

Upgrade de nó necessário em clusters atuais

A ativação do driver CSI do Managed Lustre em clusters atuais pode acionar a recriação de nós para atualizar os módulos do kernel necessários para o cliente do Managed Lustre. Para disponibilidade imediata, recomendamos fazer upgrade manual dos pools de nós.

Os clusters do GKE em um canal de lançamento são atualizados de acordo com a implantação programada, que pode levar várias semanas, dependendo da sua janela de manutenção. Se você estiver em uma versão estática do GKE, será necessário fazer upgrade manual dos pools de nós.

Até que o upgrade do nó seja concluído, o pod do driver CSI poderá apresentar um loop de falhas nos nós pendentes de atualização. Se você encontrar um erro Operation not permitted nos registros do pod do driver CSI, isso indica que o upgrade ou a recriação do nó é necessária.

Após o upgrade do pool de nós, os nós da CPU poderão parecer estar usando uma imagem de GPU no Google Cloud console ou na saída da CLI. Esse comportamento é esperado. A imagem da GPU está sendo reutilizada em nós da CPU para instalar com segurança os módulos do kernel do Managed Lustre. Não haverá cobranças pelo uso da GPU.

(Opcional) Criar um pool de nós de várias NICs

Para usar redes de alta performance, é necessário criar um pool de nós com um tipo de instância que ofereça suporte a várias interfaces de rede. O suporte a várias NICs é ativado por padrão em clusters do GKE que executam a versão 1.35.2-gke.1842000 ou mais recente. Verifique se as interfaces de rede secundárias residem na mesma rede VPC que a interface principal.

Execute este comando:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --enable-gvnic \
    --additional-node-network network=NETWORK_NAME,subnetwork=SECONDARY_SUBNET

Substitua:

  • NODE_POOL_NAME: o nome do pool de nós.
  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: a região ou zona do cluster.
  • MACHINE_TYPE: o tipo de máquina do pool de nós, como a3-megagpu-8g, que geralmente é usado com várias NICs para alta performance. A multi-NIC é compatível com qualquer tipo de máquina.
  • NETWORK_NAME: o nome da rede VPC.
  • SECONDARY_SUBNET: o nome da sub-rede secundária.

Desativar várias NICs no Lustre

Embora o suporte a várias NICs seja recomendado para cargas de trabalho de alta performance, talvez seja necessário desativá-lo em cenários específicos. Por exemplo, talvez você não queira distribuir o tráfego do Lustre em todas as interfaces de hardware disponíveis ou precise isolar problemas de conectividade em um único caminho de rede para solução de problemas.

Observação: se você desativar o suporte a várias NICs em nós em execução, talvez seja necessário recriar ou fazer upgrade manual dos pools de nós para que essa mudança entre em vigor.

Para um cluster

Para desativar a rede de alta performance para todo o cluster, use a flag --disable-multi-nic-lustre ao criar ou atualizar o cluster. Exemplo:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --disable-multi-nic-lustre

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: a região ou zona do cluster.

Para um pool de nós

Para desativar a rede de alta performance para um pool de nós específico, atualize o pool de nós para definir o identificador lustre.csi.storage.gke.io/multi-nic como false:

gcloud container node-pools update NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--zone=LOCATION \
--node-labels=lustre.csi.storage.gke.io/multi-nic=false

Substitua:

  • NODE_POOL_NAME: o nome do pool de nós.
  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: a zona do cluster.

Desativar o driver CSI do Managed Lustre

É possível desativar o driver CSI do Managed Lustre em um GKEcluster atual usando a Google Cloud CLI.

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --update-addons=LustreCsiDriver=DISABLED

Depois que o driver CSI é desativado, o GKE recria automaticamente os nós e desinstala os módulos do kernel do Managed Lustre.

Criar um novo volume usando o driver CSI do Managed Lustre

As seções a seguir descrevem o processo típico de criação de um volume do Kubernetes com suporte de uma instância do Managed Lustre no GKE:

  1. Criar um StorageClass.
  2. Usar um PersistentVolumeClaim para acessar o volume.
  3. Criar uma carga de trabalho que consuma o volume.

Criar um StorageClass

Quando o driver CSI do Managed Lustre está ativado, o GKE cria automaticamente um StorageClass para provisionar instâncias do Managed Lustre. O StorageClass depende da camada de performance do Managed Lustre , e é um dos seguintes:

  • lustre-rwx-125mbps-per-tib
  • lustre-rwx-250mbps-per-tib
  • lustre-rwx-500mbps-per-tib
  • lustre-rwx-1000mbps-per-tib

O GKE fornece um StorageClass padrão para cada camada de performance do Managed Lustre com suporte. Isso simplifica o provisionamento dinâmico de instâncias do Managed Lustre, já que é possível usar os StorageClasses integrados sem precisar definir os próprios.

Para clusters zonais, o driver CSI provisiona instâncias do Managed Lustre na mesma zona do cluster. Para clusters regionais, ele provisiona a instância em uma das zonas da região.

O exemplo a seguir mostra como criar um StorageClass personalizado com requisitos de topologia específicos:

  1. Salve o manifesto em um arquivo chamado lustre-class.yaml:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: lustre-class
provisioner: lustre.csi.storage.gke.io
volumeBindingMode: Immediate
reclaimPolicy: Delete
parameters:
  perUnitStorageThroughput: "1000"
  network: LUSTRE_NETWORK
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - us-central1-a

    Para conferir a lista completa de campos aceitos no StorageClass, consulte a documentação de referência do driver CSI do Managed Lustre.

  2. Crie o StorageClass executando este comando:

    kubectl apply -f lustre-class.yaml

Usar um PersistentVolumeClaim para acessar o volume

Esta seção mostra como criar um recurso PersistentVolumeClaim que faz referência ao StorageClass do driver CSI do Managed Lustre.

  1. Salve o manifesto em um arquivo chamado lustre-pvc.yaml:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lustre-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 9000Gi
  storageClassName: lustre-class

    Para conferir a lista completa de campos aceitos no PersistentVolumeClaim, consulte a documentação de referência do driver CSI do Managed Lustre.

  2. Execute este comando para criar o PersistentVolumeClaim:

    kubectl apply -f lustre-pvc.yaml

Criar uma carga de trabalho para consumir o volume

Esta seção mostra um exemplo de como criar um pod que consome o recurso PersistentVolumeClaim criado anteriormente.

Vários pods podem compartilhar o mesmo recurso PersistentVolumeClaim.

  1. Salve o manifesto em um arquivo chamado my-pod.yaml.

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
      - name: lustre-volume
        mountPath: /data
  volumes:
  - name: lustre-volume
    persistentVolumeClaim:
      claimName: lustre-pvc

  2. Aplique o manifesto ao cluster.

    kubectl apply -f my-pod.yaml

  3. Verifique se o pod está em execução. O pod é executado depois que o PersistentVolumeClaim é provisionado. Essa operação pode levar alguns minutos para ser concluída.

    kubectl get pods

    O resultado será assim:

    NAME           READY   STATUS    RESTARTS   AGE
my-pod         1/1     Running   0          11s

Usar fsGroup com volumes do Managed Lustre

É possível mudar a propriedade do grupo do diretório raiz do sistema de arquivos montado para corresponder a um fsGroup solicitado pelo usuário e especificado no SecurityContext do pod. O fsGroup não vai mudar recursivamente a propriedade de todo o sistema de arquivos do Managed Lustre montado. Apenas o diretório raiz do ponto de montagem é afetado.

Solução de problemas

Para orientações sobre solução de problemas, consulte a página Solução de problemas na documentação do Managed Lustre.

Limpar

Para evitar cobranças na sua Google Cloud conta, exclua os recursos de armazenamento criados neste guia.

  1. Exclua o pod e o PersistentVolumeClaim.

    kubectl delete pod my-pod
kubectl delete pvc lustre-pvc

  2. Verifique o status do PersistentVolume.

    kubectl get pv

    O resultado será assim:

    No resources found

    Pode levar alguns minutos para que a instância do Managed Lustre subjacente seja totalmente excluída.

A seguir