פתרון בעיות בהעברת נתונים ב-GKE Volume Populator

GKE Volume Populator עוזר להעביר נתונים לאשכולות GKE. עם זאת, יכולות להיות בעיות במהלך תהליך העברת הנתונים שימנעו את היצירה של PersistentVolumeClaims (תביעות ל-PersistentVolume) או את האכלוס של הנתונים בצורה נכונה.

במאמר הזה מוסבר איך לפתור בעיות נפוצות שנתקלים בהן כשמשתמשים ב-GKE Volume Populator. כאן מוסבר איך לפתור בעיות בהעברת נתונים על ידי בדיקת סטטוס הרכיב, אימות ההגדרות ופתרון שגיאות שקשורות למשאבים או להרשאות.

המידע הזה חשוב למפתחי אפליקציות, לאדמינים ולמפעילים של פלטפורמות שמשתמשים ב-GKE Volume Populator כדי להזין נתונים בכרכים של GKE. מידע נוסף על התפקידים הנפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהם בתוכן של Google Cloud , זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-GKE.

בדיקת משאבים זמניים של Kubernetes

כך כלי האכלוס של נפח האחסון ב-GKE משתמש במשאבים זמניים:

  1. נפח אחסון זמני מתמשך (PVC) נוצר במרחב השמות gke-managed-volumepopulator.
  2. בכל אזור שמעורב בהעברה, נוצרים משימת העברה, PV ו-PVC במרחב השמות של ה-PVC.
  3. אחרי העברת הנתונים, כלי האכלוס של נפח האחסון ב-GKE מסיר באופן אוטומטי את כל המשאבים הזמניים האלה.

כדי לבדוק את המשאבים הזמניים, פועלים לפי השלבים הבאים:

  1. שומרים את משתני הסביבה:

    export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE

    מחליפים את הערכים הבאים:

    • ‫PVC_NAME: השם של משאב PersistentVolumeClaim.
    • ‫NAMESPACE: מרחב השמות שבו פועלים עומסי העבודה.

  2. בודקים את הסטטוס:

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

  3. בודקים את ה-PVC הזמני במרחב השמות gke-managed-volumepopulator:

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

  4. כדי לקבל את השמות של ה-PVC הזמניים במרחב השמות:

    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. בודקים את ה-PVC הזמניים:

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

  6. הכלי GKE Volume Populator יוצר משימת העברה בכל אזור (אחת במקרה של נפח Hyperdisk ML באזור יחיד, וכמה במקרה של נפחי Hyperdisk ML בכמה אזורים). מריצים את הפקודה הבאה כדי לקבל את השם של משימת ההעברה:

    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. בודקים את משימת ההעברה:

    kubectl describe job $TRANSFER_JOB -n $NAMESPACE

  8. משיגים את שם ה-Pod ממשימת ההעברה:

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

echo $TRANSFER_POD

  9. בודקים את ה-Pod:

    kubectl describe pod $TRANSFER_POD -n $NAMESPACE

    אם יוצרים PVC בכמה אזורים, GKE Volume Populator יוצר PVC זמניים נפרדים ומשאבי משימות העברה לכל אזור שצוין. כדי לבדוק את המשאבים של כל אזור שמעורב בהעברה, מחליפים את 0 של האינדקס של TEMP_PVC_LIST במספרים אחרים.

בדיקה אם איחוד שירותי אימות הזהות של עומסי עבודה מופעל

איחוד שירותי אימות הזהות של עומסי עבודה מאפשר לפודים של העברה לגשת לשירותים Google Cloud בצורה מאובטחת. אם ל-Pods של ההעברה אין אפשרות לבצע אימות ל- Google Cloud, צריך לוודא שאיחוד זהויות של עומסי עבודה ל-GKE מופעל באשכול.

  1. כדי לבדוק אם workloadIdentityConfig מופעל באשכול, מריצים את הפקודה הבאה:

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

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: השם של האשכול.
    • ‫LOCATION: אזור ה-Compute או האזור של האשכול.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

  2. מחפשים את הפלט הבא בפקודה:

    PROJECT_ID.svc.id.goog

  3. אם workloadIdentityConfig לא מופיע בפלט, צריך להפעיל איחוד זהויות של עומסי עבודה ל-GKE.

נתיב העברה לא תקין

אם מופיעה שגיאה דומה לשגיאה הבאה, נתיב ההעברה שצוין במשאב GCPDatasource שגוי וההעברה תיכשל.

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

כדי לפתור את הבעיה, צריך למחוק את המשאב GCPDatasource, לעדכן את השדה uri בערך הנכון וליצור מחדש את המשאב.

אין הרשאה מספקת לגשת לקטגוריה

אם לחשבון השירות של Kubernetes אין גישה ל-URI של מאגר הנתונים שצוין במשאב GCPDatasource, עבודת ההעברה תיכשל. השגיאה עשויה להיראות כך:

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.

כדי לפתור את הבעיה, צריך לתת את ההרשאות הנדרשות להעברת נתונים מהקטגוריה לדיסק.

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"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫GCS_BUCKET: השם של הקטגוריה שלכם ב-Cloud Storage.
  • ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud .
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫NAMESPACE: מרחב השמות שבו פועלים עומסי העבודה.
  • ‫KSA_NAME: השם של חשבון השירות של Kubernetes.
  • ‫ROLE: תפקיד ה-IAM שמספק את ההרשאות הנדרשות לגישה לקטגוריה. לדוגמה, משתמשים ב-roles/storage.objectViewer כדי להעניק הרשאת קריאה בלבד לקטגוריה.

שגיאה: error generating accessibility requirements

יכול להיות שתופיע השגיאה הזמנית הבאה כשתבדקו את ה-PVC במרחב השמות gke-managed-volumepopulator:

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

אם אתם משתמשים באשכול GKE Autopilot או באשכול Standard עם הקצאה אוטומטית של צמתים, יכול להיות שהשגיאה הזו תופיע כי אין צמתים Ready באשכול. השגיאה אמורה להיפתר מעצמה תוך כמה דקות אחרי שהקצאת הצמתים האוטומטית (NAP) תרחיב אנכית צומת חדש.

העברת ה-Pod Pending מתבצעת במשך זמן רב

יכול להיות שבאירוע ה-PVC יוצג הסטטוס Pending של ה-Pod להעברה במשך זמן רב.

כדי לבדוק את האירועים של העברת העבודות ולוודא שהתזמון של העבודה נכשל, פועלים לפי השלבים הבאים:

  1. תאר את ה-PVC:

    kubectl describe pvc $PVC_NAME -n $NAMESPACE

    הפלט אמור להיראות כך:

    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. כדי לבדוק את ה-Pod של ההעברה, פועלים לפי השלבים במאמר בנושא בדיקה של משאבים ב-Kubernetes זמניים.

    הפלט אמור להיראות כך:

    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. אם מופיעה ההודעה NotTriggerScaleUp, צריך לבדוק אם הקצאת צמתים אוטומטית מופעלת באשכול:

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

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: השם של האשכול.
    • ‫LOCATION: אזור ה-Compute או האזור של האשכול.

  4. אם הפלט הוא False, מפעילים את הקצאת צמתים אוטומטית (NAP) באמצעות הפקודה הבאה:

    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

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: השם של האשכול שאתם מעדכנים כדי להפעיל הקצאת צמתים אוטומטית.
    • ‫LOCATION: אזור או אזור מחשוב של האשכול. לדוגמה, us-central1-a או us-central1.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫MINIMUM_CPU: מספר ה-vCPU המינימלי להקצאה אוטומטית. לדוגמה, 10.
    • ‫MINIMUM_MEMORY: הכמות המינימלית של זיכרון ב-GiB להקצאת משאבים אוטומטית. לדוגמה, 200.
    • ‫MAXIMUM_CPU: המספר המקסימלי של מעבדי vCPU להקצאה אוטומטית. לדוגמה, 100. המגבלה הזו היא סך כל משאבי ה-CPU בכל מאגרי הצמתים הקיימים שנוצרו באופן ידני ובכל מאגרי הצמתים ש-GKE עשוי ליצור באופן אוטומטי.
    • ‫MAXIMUM_MEMORY: הכמות המקסימלית של זיכרון להקצאת משאבים אוטומטית. לדוגמה, 1000. המגבלה הזו היא סך משאבי הזיכרון בכל מאגרי הצמתים הקיימים שנוצרו באופן ידני, ובכל מאגרי הצמתים ש-GKE עשוי ליצור באופן אוטומטי.

  5. אם הקצאת צמתים אוטומטית מופעלת, ודאו שלהקצאת צמתים אוטומטית יש מספיק התאמה אוטומטית לעומס resourceLimits כדי להרחיב אנכית את עבודת ההעברה. משימת ההעברה משתמשת ב-24 vCPU כברירת מחדל.

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

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: השם של האשכול.
    • ‫LOCATION: האזור או התחום של האשכול.

    הפלט אמור להיראות כך:

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

  6. אם להקצאת צמתים אוטומטית (NAP) אין מגבלות מספיקות של התאמה אוטומטית לעומס, צריך לעדכן את האשכול עם ההגדרה הנכונה.

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

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: השם של האשכול שאתם מעדכנים כדי להפעיל הקצאת צמתים אוטומטית.
    • ‫LOCATION: אזור או אזור מחשוב של האשכול. לדוגמה, us-central1-a או us-central1.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫MAXIMUM_CPU: המספר המקסימלי של מעבדי vCPU להקצאה אוטומטית. לדוגמה, 100. המגבלה הזו היא סך כל משאבי ה-CPU בכל מאגרי הצמתים הקיימים שנוצרו באופן ידני ובכל מאגרי הצמתים ש-GKE עשוי ליצור באופן אוטומטי.
    • ‫MAXIMUM_MEMORY: הכמות המקסימלית של זיכרון להקצאת משאבים אוטומטית. לדוגמה, 1000. המגבלה הזו היא סך משאבי הזיכרון בכל מאגרי הצמתים הקיימים שנוצרו באופן ידני, ובכל מאגרי הצמתים ש-GKE עשוי ליצור באופן אוטומטי.

  7. באשכולות Standard שלא מופעלת בהם הקצאת צמתים אוטומטית, מוודאים שלצומת שיצרתם בשביל משימת ההעברה יש את התווית הנדרשת של סוג המכונה:

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

  8. אם הפלט לא כולל את הצומת שיצרתם עבור משימת ההעברה, מוסיפים את התווית gcs-to-hdml-compute-class compute class לצומת:

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

    מחליפים את NODE_NAME בשם הצומת שרוצים להוסיף לו את התווית של מחלקת המחשוב.

שגיאה מסוג GCE quota exceeded

יכול להיות שתופיע הודעת שגיאה דומה לזו כשבודקים את ה-Pod של משימת ההעברה:

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. כדי לבדוק את ה-Pod של ההעברה, פועלים לפי השלבים במאמר בנושא בדיקה של משאבים ב-Kubernetes זמניים.

  2. כדי לפתור את השגיאה, צריך להגדיל את המכסה או למחוק משאבים קיימים שעלולים למנוע את ההרחבה. מידע נוסף מופיע במאמר פתרון בעיות שקשורות למכסות.

שגיאה שקשורה לחריגה מ-Hyperdisk ML‏ HDML_TOTAL_THROUGHPUT

אם הקצאת הנפח של Hyperdisk ML לא מצליחה ב-PVC הזמני במרחב השמות gke-managed-volumepopulator, יכול להיות שהמכסה האזורית ליצירת נפח חדש של Hyperdisk ML להעברת הנתונים שלכם חורגת מהמגבלה.

כדי לוודא שההקצאה של נפח Hyperdisk ML נכשלה בגלל בעיה במכסה האזורית, בודקים את יומני האירועים שמשויכים ל-PVC הזמני שנוצר על ידי GKE Volume Populator. איך לעשות את זה?

  1. שומרים את משתני הסביבה הרלוונטיים:

    export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE

    מחליפים את הערכים הבאים:

    • ‫PVC_NAME: השם של משאב PersistentVolumeClaim.
    • ‫NAMESPACE: מרחב השמות שבו פועלים עומסי העבודה.

  2. בודקים את הסטטוס של ה-PVC הזמני:

    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. בודקים את האירועים של ה-PVC כדי למצוא את QUOTA_EXCEEDED error, שדומה לזה:

    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

כדי לפתור את הבעיה:

  1. מבקשים מכסה נוספת כדי ליצור נפחי Hyperdisk ML חדשים בפרויקט.
  2. מוחקים מהפרויקט דיסקים של Hyperdisk ML שלא נמצאים בשימוש.

אין יותר מקום במכשיר

אם הודעת השגיאה No space left on device מופיעה ב-PVC, סימן שנפח האחסון של Hyperdisk ML מלא ואי אפשר לכתוב בו יותר נתונים. השגיאה עשויה להיראות כך:

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

כדי לפתור את הבעיה, צריך למחוק את ה-PVC, להגדיל את הערך של השדה spec.resources.requests.storage במניפסט ה-PVC וליצור מחדש את ה-PVC כדי להתחיל מחדש את תהליך ההעברה.

המאמרים הבאים

  • אם לא מצאתם פתרון לבעיה במסמכי התיעוד, אפשר לעיין במאמר בנושא קבלת תמיכה.