Resolução de problemas de transferência de dados do GKE Volume Populator

O GKE Volume Populator ajuda a transferir dados para clusters do GKE. No entanto, podem surgir problemas durante o processo de transferência de dados que impedem a criação de PersistentVolumeClaims (PVCs) ou o preenchimento correto dos dados.

Use este documento para resolver problemas comuns encontrados ao usar o GKE Volume Populator. Saiba como resolver problemas de transferência de dados inspecionando o estado dos componentes, validando as configurações e resolvendo erros de recursos ou autorizações.

Estas informações são importantes para os programadores de aplicações e os administradores e operadores de plataformas que usam o GKE Volume Populator para preencher dados nos respetivos volumes do GKE. Para mais informações sobre as funções comuns e exemplos de tarefas a que fazemos referência no conteúdo, consulte o artigo Funções de utilizador e tarefas comuns do GKE. Google Cloud

Inspecione recursos temporários do Kubernetes

Veja como o GKE Volume Populator usa recursos temporários:

  1. É criado um PVC temporário no espaço de nomes gke-managed-volumepopulator.
  2. Para cada zona envolvida na transferência, é criado um trabalho de transferência, PVs e PVCs no espaço de nomes do PVC.
  3. Após a transferência de dados, o GKE Volume Populator remove automaticamente todos estes recursos temporários.

Para inspecionar os recursos temporários, siga estes passos:

  1. Armazene as variáveis de ambiente:

    export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE

    Substitua os seguintes valores:

    • PVC_NAME: o nome do seu recurso PersistentVolumeClaim.
    • NAMESPACE: o espaço de nomes onde as suas cargas de trabalho são executadas.

  2. Verifique o estado:

    export PVC_UID=$(kubectl get pvc ${PVC_NAME} -n ${NAMESPACE} -o jsonpath='{.metadata.uid}')
export TEMP_PVC=prime-${PVC_UID}
echo ${TEMP_PVC}

  3. Inspecione o PVC temporário no espaço de nomes gke-managed-volumepopulator:

    kubectl describe pvc ${TEMP_PVC} -n gke-managed-volumepopulator

  4. Obtenha os nomes dos PVCs temporários no seu espaço de nomes:

    export TEMP_PVC_LIST=($(kubectl get pvc -n "$NAMESPACE" -o json | grep -Eo "\"name\":\s*\"$TEMP_PVC[^\"]*\"" | awk -F'"' '{print $4}'))

for pvc in "${TEMP_PVC_LIST[@]}"; do
  echo "$pvc"
done

  5. Inspecione os PVCs temporários:

    kubectl describe pvc "${TEMP_PVC_LIST[0]}" -n $NAMESPACE

  6. O GKE Volume Populator cria uma tarefa de transferência em cada zona (uma no caso de um volume de ML do Hyperdisk de zona única e várias no caso de volumes de ML do Hyperdisk de várias zonas). Obtenha o nome da tarefa de transferência através do seguinte comando:

    export TRANSFER_JOB=$(kubectl get pvc "${TEMP_PVC_LIST[0]}" -n "$NAMESPACE" -o "jsonpath={.metadata.annotations['volume-populator\.datalayer\.gke\.io/pd-transfer-requestid']}")

echo $TRANSFER_JOB

  7. Inspecione a tarefa de transferência:

    kubectl describe job $TRANSFER_JOB -n $NAMESPACE

  8. Obtenha o nome do pod da tarefa de transferência:

    export TRANSFER_POD=$(kubectl get pods -n "$NAMESPACE" -l "job-name=$TRANSFER_JOB" -o jsonpath='{.items[0].metadata.name}')

echo $TRANSFER_POD

  9. Inspecione o Pod:

    kubectl describe pod $TRANSFER_POD -n $NAMESPACE

    Se criar um PVC em várias zonas, o GKE Volume Populator cria PVCs temporários distintos e os recursos de tarefas de transferência para cada zona especificada. Para inspecionar os recursos de cada zona envolvida na transferência, substitua o 0 do índice de TEMP_PVC_LIST por outros números.

Verifique se a Workload Identity Federation está ativada

A Workload Identity Federation permite que os pods de transferência acedam em segurança aos Google Cloud serviços. Se os pods de transferência não conseguirem autenticar-se em Google Cloud, verifique se a Workload Identity Federation para o GKE está ativada no seu cluster.

  1. Para verificar se o workloadIdentityConfig está ativado no seu cluster, execute o seguinte comando:

    gcloud container clusters describe CLUSTER_NAME
--location=LOCATION \
--project=PROJECT_ID \
--format="value(workloadIdentityConfig)"

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: a região ou a zona de computação do seu cluster.
    • PROJECT_ID: o ID do seu Google Cloud projeto.

  2. Procure o seguinte resultado no comando:

    PROJECT_ID.svc.id.goog

  3. Se workloadIdentityConfig estiver em falta na saída, ative a federação de identidades da carga de trabalho para o GKE.

Caminho de transferência inválido

Se encontrar um erro semelhante ao seguinte, o caminho de transferência especificado no recurso GCPDatasource está incorreto e a transferência falha.

ERROR: (gcloud.storage.cp) The following URLs matched no objects or files:
gs://datasets-pd/llama2-7b-hfa/

Para resolver este problema, elimine o recurso GCPDatasource, atualize o campo uri com o valor correto e recrie o recurso.

Autorização insuficiente para aceder ao contentor

Se a conta de serviço do Kubernetes não tiver acesso ao URI do contentor especificado no recurso GCPDatasource, a tarefa de transferência falha. O erro pode ter um aspeto semelhante ao seguinte:

ERROR: (gcloud.storage.cp) [test-gke-dev.svc.id.goog] does not have permission to access b instance [small-bucket-7] (or it may not exist): Caller does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist). This command is authenticated as test-gke-dev.svc.id.goog which is the active account specified by the [core/account] property.

Para resolver o problema, conceda as autorizações necessárias para transferir dados do contentor para o disco.

gcloud storage buckets \
    add-iam-policy-binding gs://GCS_BUCKET \
     --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
    --role "ROLE"

Substitua o seguinte:

  • GCS_BUCKET: o nome do seu contentor do Cloud Storage.
  • PROJECT_NUMBER: o número do seu Google Cloud projeto.
  • PROJECT_ID: o ID do seu Google Cloud projeto.
  • NAMESPACE: o espaço de nomes onde as suas cargas de trabalho são executadas.
  • KSA_NAME: o nome da sua conta de serviço do Kubernetes.
  • ROLE: a função de IAM que fornece as autorizações necessárias para aceder ao contentor. Por exemplo, use roles/storage.objectViewer para conceder acesso só de leitura ao contentor.

Erro: error generating accessibility requirements

Pode ver o seguinte erro transitório quando verifica o PVC no espaço de nomes gke-managed-volumepopulator:

Error: error generating accessibility requirements: no available topology found.

Se usar um cluster do GKE Autopilot ou um cluster Standard com o aprovisionamento automático de nós ativado, este erro pode ocorrer porque pode não haver nós Ready no seu cluster. O erro deve resolver-se automaticamente no espaço de alguns minutos após o aprovisionamento automático de nós aumentar a escala de um novo nó.

O Transfer Pod está a ser agendado há muito tempo: Pending

O evento PVC pode mostrar que o estado do contentor de transferência é Pending durante muito tempo.

Para verificar os eventos de tarefas de transferência para confirmar se o agendamento falhou para a tarefa, siga estes passos:

  1. Descreva o PVC:

    kubectl describe pvc $PVC_NAME -n $NAMESPACE

    O resultado é semelhante ao seguinte:

    Events:
  Type     Reason             Age                From                Message
  ----     ------             ----               ----                -------
Normal   TransferInProgress              1s (x2 over 2s)    gkevolumepopulator-populator                                                                      populateCompleteFn: For PVC pd-pvc79 in namespace default, job with request ID populator-job-0b93fec4-5490-4e02-af32-15b16435d559 is still active with pod status as - Phase: Pending

  2. Para inspecionar o pod de transferência, siga os passos em Inspecione recursos temporários do Kubernetes.

    O resultado é semelhante ao seguinte:

    Events:
  Type     Reason             Age                From                Message
  ----     ------             ----               ----                -------
  Warning  FailedScheduling   2m50s              default-scheduler   0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had volume node affinity conflict. preemption: 0/3 nodes are available: 1 No preemption victims found for incoming pod, 2 Preemption is not helpful for scheduling.
  Warning  FailedScheduling   37s (x2 over 39s)  default-scheduler   0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had volume node affinity conflict. preemption: 0/3 nodes are available: 1 No preemption victims found for incoming pod, 2 Preemption is not helpful for scheduling.
  Normal   NotTriggerScaleUp  2m40s              cluster-autoscaler  pod didn't trigger scale-up:

  3. Se vir a mensagem NotTriggerScaleUp, verifique se o aprovisionamento automático de nós está ativado no cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(autoscaling.enableNodeAutoprovisioning)"

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: a região ou a zona de computação do seu cluster.

  4. Se o resultado for apresentado como "Falso", ative o aprovisionamento automático de nós através do seguinte comando:

    gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --location=LOCATION \
    --project=PROJECT_ID \
    --min-cpu MINIMUM_CPU \
    --min-memory MINIMUM_MEMORY \
    --max-cpu MAXIMUM_CPU \
    --max-memory MAXIMUM_MEMORY \
    --autoprovisioning-scopes=https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/devstorage.read_only

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster que está a atualizar para ativar o aprovisionamento automático de nós.
    • LOCATION: a zona de computação ou a região do cluster. Por exemplo, us-central1-a ou us-central1.
    • PROJECT_ID: o ID do seu Google Cloud projeto.
    • MINIMUM_CPU: o número mínimo de vCPUs a aprovisionar automaticamente. Por exemplo, 10.
    • MINIMUM_MEMORY: a quantidade mínima de memória em GiB para o aprovisionamento automático. Por exemplo, 200.
    • MAXIMUM_CPU: o número máximo de vCPUs a aprovisionar automaticamente. Por exemplo, 100. Este limite é o total dos recursos da CPU em todos os conjuntos de nós criados manualmente existentes e em todos os conjuntos de nós que o GKE pode criar automaticamente.
    • MAXIMUM_MEMORY: a quantidade máxima de memória a aprovisionar automaticamente. Por exemplo, 1000. Este limite é o total dos recursos de memória em todos os node pools existentes criados manualmente e em todos os node pools que o GKE pode criar automaticamente.

  5. Se o aprovisionamento automático de nós estiver ativado, verifique se o aprovisionamento automático de nós tem escalabilidade automática suficiente resourceLimits para aumentar a escala da tarefa de transferência. A tarefa de transferência usa 24 vCPUs por predefinição.

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(autoscaling.resourceLimits)"

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: a região ou a zona de computação do seu cluster.

    O resultado é semelhante ao seguinte:

    {'maximum': '1000000000', 'resourceType': 'cpu'};{'maximum': '1000000000', 'resourceType': 'memory'};

  6. Se a administração de contas automática de nós não tiver limites de dimensionamento automático suficientes, atualize o cluster com a configuração correta.

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --max-cpu MAXIMUM_CPU \
    --max-memory MAXIMUM_MEMORY

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster que está a atualizar para ativar o aprovisionamento automático de nós.
    • LOCATION: a zona de computação ou a região do cluster. Por exemplo, us-central1-a ou us-central1.
    • PROJECT_ID: o ID do seu Google Cloud projeto.
    • MAXIMUM_CPU: o número máximo de vCPUs a aprovisionar automaticamente. Por exemplo, 100. Este limite é o total dos recursos da CPU em todos os conjuntos de nós criados manualmente existentes e em todos os conjuntos de nós que o GKE pode criar automaticamente.
    • MAXIMUM_MEMORY: a quantidade máxima de memória a aprovisionar automaticamente. Por exemplo, 1000. Este limite é o total dos recursos de memória em todos os node pools existentes criados manualmente e em todos os node pools que o GKE pode criar automaticamente.

  7. Para clusters padrão sem o aprovisionamento automático de nós ativado, verifique se o nó que criou para a tarefa de transferência tem a etiqueta de classe de computação necessária:

    kubectl get node -l cloud.google.com/compute-class=gcs-to-hdml-compute-class

  8. Se o resultado não listar o nó que criou para a tarefa de transferência, adicione a etiqueta da classe de computação gcs-to-hdml-compute-class ao nó:

    kubectl label node NODE_NAME cloud.google.com/compute-class=gcs-to-hdml-compute-class

    Substitua NODE_NAME pelo nome do nó onde quer adicionar a etiqueta da classe de computação.

GCE quota exceeded erro

Pode encontrar uma mensagem de erro semelhante à seguinte quando verifica o pod da tarefa de transferência:

Node scale up in zones us-west1-b associated with this pod failed: GCE quota exceeded. Pod is at risk of not being scheduled.

  1. Para inspecionar o pod de transferência, siga os passos em Inspecione recursos temporários do Kubernetes.

  2. Para resolver o erro, aumente a quota ou elimine os recursos existentes que possam estar a impedir o aumento da escala. Para mais informações, consulte o artigo Resolva problemas de quotas.

Erro de HDML_TOTAL_THROUGHPUT excedido do Hyperdisk ML

Se o PVC temporário no espaço de nomes gke-managed-volumepopulator não conseguir aprovisionar o volume de ML do Hyperdisk, é possível que a quota regional para criar o novo volume de ML do Hyperdisk para a sua transferência de dados tenha sido excedida.

Para confirmar que o aprovisionamento do volume de ML do Hyperdisk falhou devido a um problema de quota regional, inspecione os registos de eventos associados ao PVC temporário criado pelo GKE Volume Populator. Siga estes passos:

  1. Armazene as variáveis de ambiente relevantes:

    export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE

    Substitua os seguintes valores:

    • PVC_NAME: o nome do seu recurso PersistentVolumeClaim.
    • NAMESPACE: o espaço de nomes onde as suas cargas de trabalho são executadas.

  2. Verifique o estado do PVC temporário:

    export PVC_UID=$(kubectl get pvc ${PVC_NAME} -n ${NAMESPACE} -o jsonpath='{.metadata.uid}')
export TEMP_PVC=prime-$PVC_UID
echo $TEMP_PVC
kubectl describe pvc $TEMP_PVC -n gke-managed-volumepopulator

  3. Verifique os eventos de PVC para encontrar o QUOTA_EXCEEDED error, que é semelhante ao seguinte:

    Events:
  Type     Reason                Age                 From                                                                                              Message
  ----     ------                ----                ----                                                                                              -------
  Warning  ProvisioningFailed    105s                pd.csi.storage.gke.io_gke-3ef909a7688d424b94a2-d0d9-b185-vm_6a77d057-54e3-415a-8b39-82b666516b6b  failed to provision volume with StorageClass "pd-sc": rpc error: code = Unavailable desc = CreateVolume failed: rpc error: code = Unavailable desc = CreateVolume failed to create single zonal disk pvc-73c69fa8-d23f-4dcb-a244-bcd120a3c221: failed to insert zonal disk: unknown error when polling the operation: rpc error: code = ResourceExhausted desc = operation operation-1739194889804-62dc9dd9a1cae-9d24a5ad-938e5299 failed (QUOTA_EXCEEDED): Quota 'HDML_TOTAL_THROUGHPUT' exceeded.  Limit: 30720.0 in region us-central1

Para resolver este problema:

  1. Peça quota adicional para criar novos volumes de ML do Hyperdisk no seu projeto.
  2. Elimine todos os discos Hyperdisk ML não usados no seu projeto.

Não existe espaço no dispositivo

Se vir a mensagem de erro No space left on device no seu PVC, significa que o volume de ML do Hyperdisk está cheio e não é possível escrever mais dados no mesmo. O erro pode ter um aspeto semelhante ao seguinte:

Events:
  Type     Reason                   Age   From                          Message
  ----     ------                   ----  ----                          -------
  Warning  TransferContainerFailed  57m   gkevolumepopulator-populator  populateCompleteFn: For PVC vp-pvc in namespace default, job with request ID populator-job-c2a2a377-6168-4ff1-afc8-c4ca713c43e2 for zone us-central1-c has a failed pod container with message:  on device
ERROR: Failed to download one or more components of sliced download.
ERROR: [Errno 28] No space left on device

Para resolver este problema, elimine o PVC, aumente o valor do campo spec.resources.requests.storage no manifesto do PVC e recrie o PVC para iniciar novamente o processo de transferência.

O que se segue?

  • Se não conseguir encontrar uma solução para o seu problema na documentação, consulte a secção Obter apoio técnico.