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

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

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

Suporte a várias NICs para redes de alto desempenho

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 e aumentar a capacidade. Esse suporte agrega largura de banda espalhando o tráfego de armazenamento TCP pelas interfaces de rede.

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

NICs padrão para TCP:seus nós precisam usar NICs padrão, como NIC virtual do Google (gVNIC) ou VirtIO-Net, para processar o tráfego de armazenamento TCP.
Mesma VPC:todas as NICs padrão precisam estar na mesma rede VPC.
Considerações sobre RDMA:seus nós também podem ter placas de rede (NICs) RDMA anexadas. No entanto, o driver CSI do Managed Lustre usa apenas as placas de rede (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 Managed Lustre gerenciado pelo GKE 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 nos 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, independente da versão do cluster. Sem essa flag, o cluster do GKE não vai 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 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.
Observação:em instalações prévias da CLI gcloud, defina a propriedade compute/region. 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.
Ative o driver CSI do Managed Lustre. Ele é desativado por padrão nos clusters Standard e do 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 projeto do Google Cloud .
LUSTRE_NETWORK: a rede de nuvem privada virtual compartilhada em que residem o cluster do GKE e a instância do Managed Lustre.
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 cluster do GKE que executa a versão 1.33.2-gke.4780000 ou mais recente, execute o seguinte comando:

Piloto automático

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 cluster do GKE que executa uma versão anterior a 1.33.2-gke.4780000, execute o seguinte comando:

Piloto automático

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 atuais do GKE

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

Usar a porta padrão `988`

Para ativar o driver CSI do Managed Lustre em um cluster do GKE 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, talvez seja necessário usar a porta legada 6988 adicionando a flag --enable-legacy-lustre-port. Essa flag é obrigatória nos seguintes cenários:

Se o cluster do GKE estiver em 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 flag gke-support-enabled.

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

Upgrade de nós 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 o upgrade manual dos seus pools de nós.

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

Até que o upgrade do nó seja concluído, o pod do driver CSI poderá entrar em loop de falha 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 é necessário fazer upgrade ou recriar o nó.

Após o upgrade do pool de nós, os nós da CPU podem parecer estar usando uma imagem de GPU na saída do console ou da CLI Google Cloud . 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 multi-NIC

Para usar redes de alta performance, crie 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 estão na mesma rede VPC da 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 alto desempenho. Várias NICs são compatíveis com qualquer tipo de máquina.
NETWORK_NAME: o nome da rede VPC.
SECONDARY_SUBNET: o nome da sub-rede secundária.

Desativar a multi-NIC 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 espalhar o tráfego do Lustre por 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 em 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 em um pool de nós específico, atualize o pool para definir o rótulo 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 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 seus 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 à sua 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 refira à 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 sua 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 prosseguir 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 do volume.
  - PROJECT_ID: o ID do projeto do Google Cloud .
  - LOCATION: o local zonal da sua instância do Lustre. É necessário especificar uma zona compatível para o driver CSI do Managed Lustre.
  - INSTANCE_NAME: o nome da sua instância do Lustre.
- ip: o endereço IP da sua instância do Lustre. Você obtém isso do campo mountPoint na saída do comando anterior.
- filesystem: o nome do sistema de arquivos da sua instância do Managed Lustre.
Para conferir a lista completa de campos aceitos 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 recurso 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 seu 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 levar vários minutos para ser concluída.
Verifique se ele está em execução:
```
kubectl get pods
```
Pode levar alguns minutos para o pod atingir o estado Running.

O resultado será o seguinte:
```
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.

Solução de problemas

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

Limpar

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

Exclua o pod e o PersistentVolumeClaim.

Observação: quando você cria o PersistentVolume com uma persistentVolumeReclaimPolicy "Retain", a exclusão do PersistentVolumeClaim não remove o PersistentVolume nem a instância do Managed Lustre subjacente.
```
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á o seguinte:

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 ele está pronto para ser vinculado a um novo PersistentVolumeClaim. Verifique o status do PersistentVolume:
```
kubectl get pv
```
O resultado será o seguinte:
```
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 subjacente.

A seguir

Consulte a documentação do Managed Lustre.

Acessar instâncias gerenciadas do Lustre no GKE usando o driver CSI gerenciado do 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 alto desempenho

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

Piloto automático

Padrão

Usar a porta legada 6988

Piloto automático

Padrão

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

Usar a porta padrão 988

Usar a porta legada 6988

Upgrade de nós necessário em clusters atuais

(Opcional) Criar um pool de nós multi-NIC

Desativar a multi-NIC 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 gerenciadas do Lustre no GKE usando o driver CSI gerenciado do Lustre

Usar a porta padrão `988`

Usar a porta legada `6988`

Usar a porta padrão `988`

Usar a porta legada `6988`