Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Este guia descreve como se conectar a uma instância do Managed Lustre usando o driver CSI do Managed Lustre. Isso permite acessar instâncias do Managed Lustre como volumes para cargas de trabalho com estado, de maneira controlada e previsível.

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) 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 a 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 será 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ê já instalou a CLI gcloud, faça o download da versão mais recente executando o comando gcloud components update. Versões anteriores da CLI gcloud podem não oferecer suporte à execução dos comandos neste documento.
Observação: Em instalações prévias da CLI gcloud, defina a compute/region propriedade. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Para limitações e requisitos, consulte Sobre o driver CSI do Google Cloud Managed Lustre.
Certifique-se de ativar o driver CSI do Managed Lustre. Ele é desativado por padrão nos clusters Standard e Autopilot.

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 LOCATION=ZONE

Substitua:

CLUSTER_NAME: o nome do cluster.
PROJECT_ID: o ID do seu Google Cloud projeto.
LUSTRE_NETWORK: a rede de nuvem privada virtual compartilhada em que o cluster do GKE e a instância do Managed Lustre residem.
ZONE: a zona geográfica do cluster do GKE, por exemplo, us-central1-a.

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 a 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 a 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 na saída do Google Cloud console ou 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. O suporte a várias NICs está disponível em 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 redes 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 redes 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 cluster do GKE 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.

Acessar uma instância do Managed Lustre usando o driver CSI do Managed Lustre

Se você já provisionou uma instância do Managed Lustre na mesma rede que o cluster do GKE, siga estas instruções para provisionar estaticamente um PersistentVolume que se refere à instância.

As seções a seguir descrevem o processo típico de acesso a uma instância do Managed Lustre usando o driver CSI do Managed Lustre:

Crie um PersistentVolume que se refere à instância do Managed Lustre.
Usar um PersistentVolumeClaim para acessar o volume.
Criar uma carga de trabalho que consuma o volume.

Criar um PersistentVolume

Para localizar a instância do Managed Lustre, execute o seguinte comando.

gcloud lustre instances list \
    --project=${PROJECT_ID} \
    --location=${LOCATION}

A saída será parecida com esta: Antes de continuar para a próxima etapa, anote os campos Nome da instância do Managed Lustre, filesystem e mountPoint.

capacityGib: '9000'
createTime: '2025-04-28T22:42:11.140825450Z'
filesystem: testlfs
gkeSupportEnabled: true
mountPoint: 10.90.1.4@tcp:/testlfs
name: projects/my-project/locations/us-central1-a/instances/my-lustre
network: projects/my-project/global/networks/default
perUnitStorageThroughput: '1000'
state: ACTIVE
updateTime: '2025-04-28T22:51:41.559098631Z'

Salve o manifesto em um arquivo chamado lustre-pv.yaml.
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: lustre-pv
spec:
  storageClassName: "STORAGE_CLASS_NAME"
  capacity:
    storage: 9000Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
  claimRef:
    namespace: default
    name: lustre-pvc
  csi:
    driver: lustre.csi.storage.gke.io
    volumeHandle: "PROJECT_ID/LOCATION/INSTANCE_NAME"
    volumeAttributes:
      ip: IP_ADDRESS
      filesystem: FILESYSTEM
```
Substitua:
- storageClassName: o nome do StorageClass. O valor pode ser uma string vazia, mas precisa atender à especificação do PersistentVolumeClaim.
- volumeHandle: o identificador desse volume.
  - PROJECT_ID: o Google Cloud ID do projeto.
  - LOCATION: o local zonal da instância do Lustre. É necessário especificar uma zona com suporte para o driver CSI do Managed Lustre.
  - INSTANCE_NAME: o nome da instância do Lustre.
- ip: o endereço IP da instância do Lustre. Você o recebe do campo mountPoint na saída do comando anterior.
- filesystem: o nome do sistema de arquivos da instância do Managed Lustre.
Para conferir a lista completa de campos com suporte no objeto PersistentVolume, consulte a documentação de referência do driver CSI do Managed Lustre.
Execute este comando para criar o PersistentVolume:
```
kubectl apply -f lustre-pv.yaml
```

Usar o PersistentVolumeClaim para acessar o volume

É possível criar um PersistentVolumeClaim que faz referência ao StorageClass do driver CSI do Managed Lustre.

O arquivo de manifesto a seguir mostra um exemplo de como criar um PersistentVolumeClaim no ReadWriteMany modo de acesso , que faz referência ao StorageClass criado anteriormente.

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

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: lustre-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: "STORAGE_CLASS_NAME"
  volumeName: lustre-pv
  resources:
    requests:
      storage: STORAGE_SIZE

Substitua STORAGE_SIZE pelo tamanho de armazenamento. Por exemplo, 9000Gi. Ele precisa corresponder à especificação no PersistentVolume.

Execute este comando para criar o PersistentVolumeClaim:
```
kubectl create -f lustre-pvc.yaml
```

Criar uma carga de trabalho que consuma o volume

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

Vários pods podem compartilhar o mesmo recurso PersistentVolumeClaim.

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

Execute o comando a seguir para aplicar o manifesto ao cluster:
```
kubectl apply -f my-pod.yaml
```
O pod aguarda até que o GKE provisione o PersistentVolumeClaim antes de começar a ser executado. Essa operação pode demorar vários minutos para ser concluída.
Verifique se ele está em execução:
```
kubectl get pods
```
Pode levar alguns minutos para que o pod atinja o estado Running.

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 alterar 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.

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.

Exclua o pod e o PersistentVolumeClaim.

Observação: ao criar o PersistentVolume com uma persistentVolumeReclaimPolicy "Retain", a exclusão do PersistentVolumeClaim não remove o PersistentVolume ou a instância do Managed Lustre.
```
kubectl delete pod my-pod
kubectl delete pvc lustre-pvc
```

Verifique o status do PersistentVolume. Depois de excluir o pod e o PersistentVolumeClaim, o PersistentVolume vai informar um estado "Released":

kubectl get pv

O resultado será assim:

NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                 STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX            Retain        Released   default/preprov-pvc                           2m28s

Reutilize o PersistentVolume. Para reutilizar o PersistentVolume, remova a referência de reivindicação (claimRef):

kubectl patch pv lustre-pv --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'

O PersistentVolume agora vai informar um status "Available", indicando que está pronto para ser vinculado a um novo PersistentVolumeClaim. Verifique o status do PersistentVolume:

kubectl get pv

O resultado será assim:

NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX           Retain         Available                                   19m

Exclua o PersistentVolume se ele não for mais necessário. Se o PersistentVolume não for mais necessário, exclua-o:
```
kubectl delete pv lustre-pv
```
A exclusão do PersistentVolume não remove a instância do Managed Lustre.

A seguir

Consulte a documentação do Managed Lustre.

Acessar instâncias do Managed Lustre no GKE usando o driver CSI do Managed Lustre Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Suporte a várias NICs para redes de alta performance

Portas de comunicação do Lustre

Antes de começar

Configurar variáveis de ambiente

Configurar o driver CSI do Managed Lustre

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

Usar a porta padrão 988

Autopilot

Padrão

Usar a porta legada 6988

Autopilot

Padrão

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

Usar a porta padrão 988

Usar a porta legada 6988

Upgrade de nó necessário em clusters atuais

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

Desativar várias NICs no Lustre

Para um cluster

Para um pool de nós

Desativar o driver CSI do Managed Lustre

Acessar uma instância do Managed Lustre usando o driver CSI do Managed Lustre

Criar um PersistentVolume

Usar o PersistentVolumeClaim para acessar o volume

Criar uma carga de trabalho que consuma o volume

Usar fsGroup com volumes do Managed Lustre

Solução de problemas

Limpar

A seguir

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

Usar a porta padrão `988`

Usar a porta legada `6988`

Usar a porta padrão `988`

Usar a porta legada `6988`