Este guia mostra como resolver problemas comuns que surgem quando transfere dados para clusters do GKE através do GKE Volume Populator. Este artigo explica como depurar os problemas relacionados com a criação de PersistentVolumeClaim (PVC) e PersistentVolume (PV), o desempenho do disco e a execução de tarefas de transferência de dados.
Inspecione recursos temporários do Kubernetes
Veja como o GKE Volume Populator usa recursos temporários:
- É criado um PVC temporário no espaço de nomes
gke-managed-volumepopulator
. - Para cada zona envolvida na transferência, é criado um trabalho de transferência, PVs e PVCs no espaço de nomes do PVC.
- 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:
Armazene as variáveis de ambiente:
export PVC_NAME=PVC_NAME export NAMESPACE=NAMESPACE
Substitua os seguintes valores:
PVC_NAME
: o nome do seu recursoPersistentVolumeClaim
.NAMESPACE
: o espaço de nomes onde as suas cargas de trabalho são executadas.
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}
Inspecione o PVC temporário no espaço de nomes
gke-managed-volumepopulator
:kubectl describe pvc ${TEMP_PVC} -n gke-managed-volumepopulator
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
Inspecione os PVCs temporários:
kubectl describe pvc "${TEMP_PVC_LIST[0]}" -n $NAMESPACE
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
Inspecione a tarefa de transferência:
kubectl describe job $TRANSFER_JOB -n $NAMESPACE
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
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 deTEMP_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.
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 cluster.PROJECT_ID
: o ID do seu Google Cloud projeto.
Procure a seguinte saída no comando:
PROJECT_ID.svc.id.goog
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, useroles/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 a administração de contas automática de nós ativada, 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:
Descreva a 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
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:
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 cluster.
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
ouus-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.
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 cluster.
O resultado é semelhante ao seguinte:
{'maximum': '1000000000', 'resourceType': 'cpu'};{'maximum': '1000000000', 'resourceType': 'memory'};
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
ouus-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.
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
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.
Erro GCE quota exceeded
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.
Para inspecionar o pod de transferência, siga os passos em Inspecione recursos temporários do Kubernetes.
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:
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 recursoPersistentVolumeClaim
.NAMESPACE
: o espaço de nomes onde as suas cargas de trabalho são executadas.
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
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:
- Peça quota adicional para criar novos volumes de ML do Hyperdisk no seu projeto.
- 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.