Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

טייס אוטומטי רגילה

GKE Volume Populator עוזר להעביר נתונים לאשכולות GKE. עם זאת, יכולות להתעורר בעיות במהלך תהליך העברת הנתונים שימנעו את היצירה של PersistentVolumeClaims (תביעות של נפח אחסון קבוע,‏ PVC) או את האכלוס של הנתונים בצורה נכונה.

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

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

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

כך הכלי GKE Volume Populator משתמש במשאבים זמניים:

נוצר PVC זמני במרחב השמות gke-managed-volumepopulator.
לכל אזור שמעורב בהעברה, נוצרת משימת העברה, PV ו-PVC במרחב השמות של ה-PVC.
אחרי העברת הנתונים, התוסף GKE Volume Populator מסיר באופן אוטומטי את כל המשאבים הזמניים האלה.

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

מאחסנים את משתני הסביבה:
```
export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE
```
מחליפים את הערכים הבאים:
- ‫PVC_NAME: השם של משאב PersistentVolumeClaim.
- ‫NAMESPACE: מרחב השמות שבו פועלים עומסי העבודה.

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

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

בודקים את ה-PVC הזמני במרחב השמות gke-managed-volumepopulator:
```
kubectl describe pvc ${TEMP_PVC} -n gke-managed-volumepopulator
```

כדי לקבל את השמות של ה-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

בודקים את ה-PVC הזמניים:

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

הכלי 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
```

בודקים את משימת ההעברה:

kubectl describe job $TRANSFER_JOB -n $NAMESPACE

אחזור שם ה-Pod ממשימת ההעברה:

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

echo $TRANSFER_POD

בודקים את ה-Pod:
```
kubectl describe pod $TRANSFER_POD -n $NAMESPACE
```
אם יוצרים PVC בכמה אזורים, התוסף GKE Volume Populator יוצר PVC זמני נפרד ומשאבי Job להעברה לכל אזור שצוין. כדי לבדוק את המשאבים של כל אזור שמעורב בהעברה, מחליפים את 0 של האינדקס של TEMP_PVC_LIST במספרים אחרים.

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

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

כדי לבדוק אם workloadIdentityConfig מופעל באשכול, מריצים את הפקודה הבאה:
```
gcloud container clusters describe CLUSTER_NAME
--location=LOCATION \
--project=PROJECT_ID \
--format="value(workloadIdentityConfig)"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫LOCATION: אזור ה-Compute או התחום של האשכול.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
חפשו את הפלט הבא בפקודה:
```
PROJECT_ID.svc.id.goog
```
אם 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 באשכול. השגיאה אמורה להיפתר תוך כמה דקות אחרי שהקצאת הצמתים האוטומטית של הצומת החדש תגדל.

העברת ה-Pod `Pending` מתוזמנת לזמן רב

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

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

תאר את ה-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

כדי לבדוק את ה-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:

אם מופיעה ההודעה NotTriggerScaleUp, צריך לבדוק אם באשכול מופעלת הקצאת צמתים אוטומטית (NAP):
```
gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(autoscaling.enableNodeAutoprovisioning)"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫LOCATION: אזור ה-Compute או התחום של האשכול.
אם הפלט הוא '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 עשוי ליצור באופן אוטומטי.
אם הקצאת צמתים אוטומטית מופעלת, צריך לוודא שהקצאת צמתים אוטומטית כוללת מספיק התאמה אוטומטית לעומס resourceLimits כדי להגדיל את קנה המידה של העברת העבודה. משימת ההעברה משתמשת ב-24 vCPU כברירת מחדל.
```
gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(autoscaling.resourceLimits)"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫LOCATION: אזור ה-Compute או התחום של האשכול.
הפלט אמור להיראות כך:
```
{'maximum': '1000000000', 'resourceType': 'cpu'};{'maximum': '1000000000', 'resourceType': 'memory'};
```
אם להקצאת צמתים אוטומטית (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 עשוי ליצור באופן אוטומטי.
במקרה של אשכולות רגילים ללא הקצאת צמתים אוטומטית (NAP) מופעלת, צריך לוודא שלצומת שיצרתם בשביל העברת העבודה יש את התווית הנדרשת של מחלקת המחשוב:
```
kubectl get node -l cloud.google.com/compute-class=gcs-to-hdml-compute-class
```
אם הפלט לא כולל את הצומת שיצרתם עבור משימת ההעברה, מוסיפים את התווית של מחלקת המחשוב gcs-to-hdml-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.

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

שגיאה: חריגה מ-Hyperdisk ML `HDML_TOTAL_THROUGHPUT`

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

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

מאחסנים את משתני הסביבה הרלוונטיים:
```
export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE
```
מחליפים את הערכים הבאים:
- ‫PVC_NAME: השם של משאב PersistentVolumeClaim.
- ‫NAMESPACE: מרחב השמות שבו פועלים עומסי העבודה.

בודקים את הסטטוס של ה-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

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

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

מבקשים מכסה נוספת כדי ליצור נפחי אחסון חדשים של Hyperdisk ML בפרויקט.
מוחקים את כל דיסקי ה-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 כדי להתחיל מחדש את תהליך ההעברה.

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

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

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