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

Este guia descreve como criar um novo volume do Kubernetes com suporte do driver CSI do Lustre gerenciado 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.

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 CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. 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 Google Cloud ID do projeto.
  • LUSTRE_NETWORK: a rede de nuvem privada virtual (VPC) compartilhada em que residem o cluster do GKE e a instância gerenciada do Lustre.
  • LUSTRE_IP_RANGE: o nome do intervalo de endereços IP criado para o peering de rede VPC com o Lustre gerenciado.
  • 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 gerenciada do 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 de 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 Lustre gerenciado

Esta seção aborda como ativar e desativar o driver CSI do Lustre gerenciado, se necessário.

Portas de comunicação do Lustre

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

  • 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: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. Para informações sobre a flag gke-support-enabled, consulte a descrição das flags opcionais em Criar uma instância.

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

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

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

Usar a porta padrão 988

Para ativar o driver CSI do Lustre gerenciado 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 Lustre gerenciado 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 Lustre gerenciado em clusters atuais do GKE

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

Usar a porta padrão 988

Para ativar o driver CSI gerenciado do 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 gerenciado do 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 Lustre gerenciado em clusters atuais pode acionar a recriação de nós para atualizar os módulos do kernel necessários para o cliente do Lustre gerenciado. Para disponibilidade imediata, recomendamos fazer 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 usando uma versão estática do GKE, será necessário fazer upgrade manual dos pools de nós.

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 CLIGoogle Cloud . Exemplo:

config:
  imageType: COS_CONTAINERD
  nodeImageConfig:
    image: gke-1330-gke1552000-cos-121-18867-90-4-c-nvda

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 Lustre gerenciado. Não haverá cobranças pelo uso da GPU.

Desativar o driver CSI do Lustre gerenciado

É possível desativar o driver CSI do Lustre gerenciado 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 Lustre gerenciado.

Criar um novo volume usando o driver CSI do Lustre gerenciado

As seções a seguir descrevem o processo típico de criação de um volume do Kubernetes compatível com uma instância gerenciada do 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 Lustre gerenciado está ativado, o GKE cria automaticamente um StorageClass para provisionar instâncias do Lustre gerenciado. A StorageClass depende do nível de desempenho do Lustre gerenciado 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 Lustre gerenciado compatível. Isso simplifica o provisionamento dinâmico de instâncias gerenciadas do Lustre, já que é possível usar as StorageClasses integradas sem precisar definir as suas.

Para clusters zonais, o driver CSI provisiona instâncias gerenciadas do 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 Lustre gerenciado.

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

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

  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 muda recursivamente a propriedade de todo o sistema de arquivos Lustre gerenciado 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á assim:

    No resources found

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

A seguir