Esta página foi traduzida pela API Cloud Translation.

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

Autopilot Standard

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 seguintes tarefas:

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 gcloud CLI anteriormente, instale a versão mais recente executando gcloud components update.
Observação:para instalações atuais da CLI gcloud, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, você evita erros na CLI gcloud como este: 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 a visão geral do driver CSI.
Ative o driver CSI do Lustre gerenciado. Ele é desativado por padrão nos clusters Standard e do Autopilot.

Configure as 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

Substitua:

CLUSTER_NAME: o nome do cluster.
PROJECT_ID: o ID do projeto do Trusted Cloud by S3NS .
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 VPC Network Peering 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.

Configurar uma rede VPC

É preciso especificar a mesma rede VPC ao criar a instância do Lustre gerenciado e os clusters do GKE.

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

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

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

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}

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}
)

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}

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 Trusted Cloud console > 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.

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.

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

Para ativar o driver CSI do Lustre gerenciado ao criar um cluster do GKE, siga estas etapas:

Piloto automático

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

Padrão

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

Quando a flag enable-legacy-lustre-port é especificada, o driver CSI configura LNet (a camada de rede virtual para o módulo do kernel do Lustre gerenciado) para usar a porta 6988. Essa flag é necessária para contornar um conflito de porta com o gke-metadata-server em nós do GKE.

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

Para ativar o driver CSI do Lustre gerenciado em um cluster do GKE, use o seguinte comando:

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

A ativação do driver CSI do Lustre gerenciado 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 CLITrusted 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 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:

Crie um StorageClass.
Usar um PersistentVolumeClaim para acessar o volume.
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. GKE 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 um StorageClass personalizado com requisitos de topologia específicos:

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.

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.

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

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lustre-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 18000Gi
  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.

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.

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

Aplique o manifesto ao cluster.
```
kubectl apply -f my-pod.yaml
```
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 Trusted Cloud by S3NS , exclua os recursos de armazenamento criados neste guia.

Exclua o pod e o PersistentVolumeClaim.

Observação: se você criar o PersistentVolume com uma política persistentVolumeReclaimPolicy "Delete", a exclusão do PersistentVolumeClaim também vai excluir o PersistentVolume e a instância do Managed Lustre subjacente.
```
kubectl delete pod my-pod
kubectl delete pvc lustre-pvc
```
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

Consulte a documentação do Managed Lustre.