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

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 projeto do Google Cloud .
  • LUSTRE_NETWORK: a rede de nuvem privada virtual (VPC) compartilhada em que residem o cluster do GKE e a instância do Managed Lustre.
  • 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

Você precisa especificar a mesma rede VPC ao criar a instância do Managed Lustre e os clusters do GKE ou se conectar pelo Network Connectivity Center se 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 desempenho 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 que você criou.

    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 no seu projeto, verifique se você tem as permissões necessárias do IAM, especificamente a função compute.networkAdmin ou servicenetworking.networksAdmin.

    1. Acesse o console do Google Cloud > IAM e administrador e pesquise o principal 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 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.

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 compatível com uma instância do Managed Lustre no GKE:

  1. Crie 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. A StorageClass depende do nível de desempenho do Managed Lustre e é uma das seguintes opções:

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

O GKE fornece uma StorageClass padrão para cada nível de desempenho do Managed Lustre compatível. Isso simplifica o provisionamento dinâmico de instâncias do Managed Lustre, já que é possível usar as StorageClasses integradas sem precisar definir as suas.

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 uma StorageClass personalizada 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

Nesta seção, mostramos 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á 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. O fsGroup não muda recursivamente a propriedade de todo o sistema de arquivos 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 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.

  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á o seguinte:

    No resources found

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

A seguir