אוטומציה של העברת נתונים מ-Cloud Storage לנפח Hyperdisk ML באמצעות GKE Volume Populator

במאמר הזה מוסבר איך לטעון מראש מערכי נתונים מדלי של Cloud Storage לנפחי אחסון של Google Cloud Hyperdisk ML באמצעות Volume Populator של Google Kubernetes Engine ‏ (GKE) במהלך הקצאה דינמית. מידע נוסף זמין במאמר מידע על GKE Volume Populator.

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

המסמך הזה מיועד למהנדסי ML ולמומחי אחסון שיוצרים ומקצים אחסון, מנהלים את אבטחת הנתונים והגישה אליהם, ומתאימים אישית את תשתית האימון של AI/ML ב-GKE. מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהן בתוכן של Cloud de Confiance by S3NS , זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-GKE.

ניהול מאגר הצמתים ב-GKE Volume Populator עם Hyperdisk ML

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

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

מטרות

במדריך הזה תבצעו את המשימות הבאות:

לפני שמתחילים

חשוב לוודא שביצעתם את המשימות הבאות:

  1. מפעילים את ממשקי ה-API של GKE ו-Cloud Storage.

    הפעלת ממשקי ה-API

  2. מוודאים שהחיוב מופעל בCloud de Confiance by S3NS פרויקט.

  3. מורידים ומתקינים את כלי שורת הפקודה של Google Cloud CLI, או משתמשים ב-Cloud Shell כדי להריץ את הפקודות gcloud CLI ו-kubectl. ‫Cloud Shell היא סביבת מעטפת לניהול משאבים שמתארחים ב- Cloud de Confiance by S3NS. הוא מגיע עם כלי שורת הפקודה gcloud ו-kubectl שהותקנו מראש.

  4. הגדרת אזור ותחום כברירת מחדל.

  5. יוצרים קטגוריה של Cloud Storage או משתמשים בקטגוריה קיימת. במדריך הזה אנחנו יוצאים מנקודת הנחה שכבר יש לכם קטגוריה של Cloud Storage עם נתוני אימון המודל.

  6. מפעילים את מנהל ההתקן של CSI של דיסק מתמשך ב-Compute Engine באשכולות רגילים קיימים שבהם יכול להיות שמנהל ההתקן מושבת באופן מפורש. באשכולות חדשים של Autopilot ו-Standard, ‏ GKE מפעיל את הדרייבר כברירת מחדל. אחסון ה-Hyperdisk ML ביעד שאתם יוצרים צריך להיות מנוהל על ידי מנהל ההתקן של Compute Engine Persistent Disk CSI.

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

דרישות

כדי להעביר נתונים באמצעות GKE Volume Populator, צריך לעמוד בדרישות הבאות:

  • אשכול GKE צריך להיות בגרסה 1.33.2-gke.4780000 ואילך.
  • GCPDataSource המשאב המותאם אישית צריך להיות באותו מרחב שמות כמו עומס העבודה של GKE. אין תמיכה במקורות נתונים שמשתרעים על מרחבי שמות שונים.
  • בוחרים מכונה וירטואלית נתמכת כשיוצרים את סוג המחשוב. מוודאים שלפרויקט יש מכסה מספקת לסוג המכונה שבוחרים.
  • שם מחלקת המחשוב gcs-to-hdml-compute-class מוגדר מראש עבור העברת העבודה, וחובה לציין אותו בדיוק כשיוצרים את מחלקת המחשוב.

עלויות

למרות שאין עלות ישירה לשימוש ב-GKE Volume Populator, אחסון והעברות נתונים כרוכים בחיובים. העלויות העקיפות שקשורות לשימוש כוללות את הפריטים הבאים:

  • ‫Compute Engine instances used by GKE: העלות של הצמתים שמשמשים להרצת משימות העברת הנתונים. ההשלכות על ניהול הצמתים והעלויות משתנות בהתאם לסוגי האשכולות. מידע נוסף זמין במאמר יצירת אשכול GKE בקטע על סוגי האשכולות.
  • גודל הצומת של העברת נתונים: כדי להשיג ביצועים אופטימליים בהעברת נתונים, כברירת מחדל, העברת נתונים מגדילה את הצומת עם 24 vCPU. ההגדרה הזו חלה על כל סוגי האשכולות. אם רוצים לשנות את הגודל והסוג של הצומת כדי לבצע אופטימיזציות ספציפיות של עלויות או ביצועים, אפשר לעשות זאת כשיוצרים את מחלקת המחשוב.
  • נפח האחסון שנעשה בו שימוש בקטגוריה של Cloud Storage: מידע נוסף זמין במאמר תמחור של Cloud Storage.
  • עלויות של נפח אחסון Hyperdisk ML: כולל קיבולת האחסון והביצועים (IOPS/throughput) של נפחי האחסון Hyperdisk ML שאתם יוצרים. מידע נוסף מופיע במאמר בנושא תמחור Hyperdisk.

הכנת הסביבה

בקטע הזה יוצרים את תשתית אשכול GKE עם חומרה מתאימה, ומגדירים את ההרשאות הנדרשות לגישה לנתונים ב-Cloud Storage.

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

איך פועלות מחלקות מחשוב עם סוגים שונים של אשכולות ב-Hyperdisk ML

הכלי GKE Volume Populator משתמש בסוג מחשוב מותאם אישית כדי לקבוע את סוגי הצמתים שבהם יש להשתמש עבור משימות העברת הנתונים. בטבלה הבאה מפורטת ההתנהגות של מחלקת המחשוב בהתאם להגדרות האשכול:

התעניינות ברכישה ‫GKE Autopilot ו-GKE Standard עם הקצאה אוטומטית של צמתים ‫GKE Standard ללא הקצאה אוטומטית של צמתים
הגדרת סוג המחשוב nodePoolAutoCreation הופעלו nodePoolAutoCreation מושבת
ניהול צמתים ‫GKE יוצר ומנהל צמתים באופן אוטומטי. אתם יוצרים ומנהלים את הצמתים באופן ידני.
שינוי גודל הצומת אוטומטי גלילה ידנית
Node labeling לא רלוונטי צריך לתייג את הצמתים באמצעות cloud.google.com/compute-class=gcs-to-hdml-compute-class
מידע נוסף הקצאת צמתים אוטומטית (NAP) וסוגי מחשוב הגדרה של מאגרי צמתים שנוצרו באופן ידני

מערכת GKE מתחילה את משימת העברת הנתונים אחרי הקצאת PersistentVolume עבור PersistentVolumeClaim. כדי לאכלס את נפח ה-ML של Hyperdisk, צריך להפנות את PersistentVolumeClaim אל GCPDataSource, שמגדיר את נתוני המקור ב-Cloud Storage.

יצירת אשכול GKE

אתם יכולים לבחור לפרוס את צינור העברת הנתונים באמצעות אשכול רגיל או אשכול במצב Autopilot עם GKE בגרסה 1.33.2-gke.4780000 ואילך. לכל סוג אשכול יש יתרונות משלו ומודלים שונים של תמחור.

  • כדאי לבחור באפשרות Autopilot כדי לנהל את האשכולות בקלות רבה יותר, לחסוך בעלויות ולהשתמש בהתאמת קנה מידה אוטומטית.
  • בוחרים באפשרות Standard עם node auto-provisioning מופעל אם אתם צריכים התאמה אוטומטית לעומס עם יותר שליטה בהקצאת צמתים.
  • אם אתם רוצים שליטה מקסימלית ונוח לכם לנהל את כל ההיבטים של הקצאת צמתים, שינוי גודל ותחזוקה, אתם יכולים לבחור באפשרות Standard without node auto-provisioning enabled.

טייס אוטומטי

באשכולות GKE Autopilot, ‏ GKE מטפל באופן אוטומטי ביצירה ובמחיקה של הצמתים שנדרשים למשימות העברת הנתונים. כשעבודת ההעברה מסתיימת, המשאבים של הצומת מצטמצמים אוטומטית. אין צורך למחוק באופן ידני את ה-Pods של ההעברה או את הצמתים שה-Pods פעלו בהם.

כדי ליצור אשכול חדש של Autopilot, מריצים את הפקודה הבאה:

  gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=CLUSTER_VERSION

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

  • ‫CLUSTER_NAME: השם של האשכול שאתם יוצרים.
  • ‫LOCATION: האזור של שירותי המחשוב באשכול. לדוגמה, us-central1.
  • ‫CLUSTER_VERSION: גרסת GKE של האשכול. השימוש ב-1.33.2-gke.4780000 במדריך הזה.

רגילה (עם הקצאת צמתים אוטומטית)

באשכולות GKE Standard עם הקצאת משאבים אוטומטית של צמתים מופעלת, GKE מטפל באופן אוטומטי ביצירה ובמחיקה של הצמתים שנדרשים למשימות העברת הנתונים. כשעבודת ההעברה מסתיימת, המשאבים של הצומת מצטמצמים אוטומטית. אין צורך למחוק באופן ידני את ה-Pods של ההעברה או את הצמתים שה-Pods פעלו בהם.

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

  gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --location=LOCATION \
    --project=PROJECT_ID \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog \
    --enable-autoprovisioning \
    --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: השם של האשכול שאתם יוצרים עם הקצאת צמתים אוטומטית (NAP) מופעלת.
  • ‫CLUSTER_VERSION: גרסת GKE של האשכול. השימוש ב-1.33.2-gke.4780000 במדריך הזה.
  • ‫LOCATION: אזור או אזור מחשוב של האשכול. לדוגמה, us-central1-a או us-central1.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance by S3NS .
  • ‫MINIMUM_CPU: המספר המינימלי של מעבדי vCPU להקצאה אוטומטית. לדוגמה, 10.
  • ‫MINIMUM_MEMORY: כמות הזיכרון המינימלית ב-GiB להקצאה אוטומטית. לדוגמה, 200.
  • ‫MAXIMUM_CPU: המספר המקסימלי של מעבדי vCPU להקצאה אוטומטית. לדוגמה, 100. המגבלה הזו היא סך משאבי ה-CPU בכל מאגרי הצמתים הקיימים שנוצרו באופן ידני ובכל מאגרי הצמתים ש-GKE עשוי ליצור באופן אוטומטי.
  • ‫MAXIMUM_MEMORY: כמות הזיכרון המקסימלית להקצאה אוטומטית. לדוגמה, 1000. המגבלה הזו היא סך משאבי הזיכרון בכל מאגרי הצמתים הקיימים שנוצרו באופן ידני, ובכל מאגרי הצמתים ש-GKE עשוי ליצור באופן אוטומטי.

רגיל (ללא הקצאת צמתים אוטומטית)

כדי להשתמש ב-GKE Volume Populator באשכול רגיל שבו לא מופעלת הקצאת צמתים אוטומטית (NAP), אפשר להשתמש במאגר צמתים קיים או ליצור מאגר צמתים ייעודי להעברה. לצמתים צריכה להיות קיבולת להרצת משימות ההעברה ולתוויות שתואמות ל-compute-class.

מציינים את מחלקת המחשוב gcs-to-hdml-compute-class כתווית צומת כשיוצרים את האשכול ומאגר הצמתים. שימו לב ששם מחלקת המחשוב, gcs-to-hdml-compute-class, מוגדר מראש למשימת ההעברה, וחובה לציין אותו בדיוק.

כדי ליצור אשכול Standard חדש ללא הקצאת צמתים אוטומטית (NAP), ומאגר צמתים חדש באשכול הזה, מריצים את הפקודות הבאות:

  gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --location=LOCATION \
    --num-nodes=1 \
    --project=PROJECT_ID \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog

  gcloud container node-pools create NODE_POOL_NAME\
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --num-nodes=1 \
    --machine-type=c3-standard-44 \
    --node-labels="cloud.google.com/compute-class=gcs-to-hdml-compute-class" \
    --node-taints="cloud.google.com/compute-class=gcs-to-hdml-compute-class:NoSchedule"

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

  • ‫CLUSTER_NAME: השם של האשכול שאתם יוצרים בלי שהקצאת צמתים אוטומטית (NAP) מופעלת.
  • ‫CLUSTER_VERSION: גרסת GKE של האשכול. השימוש ב-1.33.2-gke.4780000 במדריך הזה.
  • ‫LOCATION: האזור של שירותי המחשוב באשכול. לדוגמה, us-central1-a או us-central1.
  • ‫PROJECT_ID מזהה הפרויקט ב- Cloud de Confiance by S3NS .
  • ‫NODE_POOL_NAME: השם של מאגר הצמתים שאתם יוצרים באשכול החדש. מאגר הצמתים הזה משמש את GKE Volume Populator לפריסת משימות העברת הנתונים הזמניות.

כדי להימנע מעלויות מיותרות, מריצים את הפקודה gcloud container node-pools delete כדי למחוק את מאגרי הצמתים של העברת הנתונים שנוצרו באופן ידני אחרי שהעברת הנתונים מסתיימת.

יצירת מחלקת מחשוב

כדי ליצור מחלקת מחשוב שתגדיר ותקבע את סדר העדיפויות של סוגי המכונות הווירטואליות שאפשר להשתמש בהן כצמתים באשכול:

  1. שומרים את קובץ המניפסט הבא בשם computeclass.yaml:

    עם הקצאת צמתים אוטומטית (NAP)

    באשכולות במצב Autopilot ובאשכולות רגילים שבהם מופעלת הקצאת משאבים אוטומטית של צמתים, מגדירים את מחלקת המחשוב באמצעות הקטע nodePoolAutoCreation באופן הבא. כשהקצאת צמתים אוטומטית (NAP) מופעלת, GKE יוצר באופן אוטומטי מאגרי צמתים חדשים עם התווית gcs-to-hdml-compute-class של מחלקת המחשוב. 

      apiVersion: cloud.google.com/v1
  kind: ComputeClass
  metadata:
   name: gcs-to-hdml-compute-class
  spec:
   priorities:
   - machineFamily: c3
   - machineFamily: c3d
   nodePoolAutoCreation:
    enabled: true
   whenUnsatisfiable: DoNotScaleUp

    ללא הקצאת צמתים אוטומטית (NAP)

    באשכולות Standard שלא מופעלת בהם הקצאת צמתים אוטומטית (NAP), מגדירים את מחלקת המחשוב ללא הקטע nodePoolAutoCreation באופן הבא. מוודאים שכבר יצרתם מאגר צמתים עם התווית של מחלקת המחשוב gcs-to-hdml-compute-class.

      apiVersion: cloud.google.com/v1
  kind: ComputeClass
  metadata:
   name: gcs-to-hdml-compute-class
  spec:
   priorities:
   - machineFamily: c3
   - machineFamily: c3d
   whenUnsatisfiable: DoNotScaleUp

    אתם יכולים לציין כל machineFamily תואם כדי לענות על הצרכים שלכם להעברת נתונים. מידע נוסף על בחירת סוג מכונה מתאים זמין במאמר תמיכה בסדרות מכונות ב-Hyperdisk ML.

  2. כדי ליצור את מחלקת המחשוב, מפעילים את המניפסט: 
    kubectl apply -f computeclass.yaml

הגדרת ההרשאות הנדרשות

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

  1. יוצרים מרחב שמות של Kubernetes:

    kubectl create namespace NAMESPACE

    מחליפים את NAMESPACE במרחב השמות שבו רוצים שהעומסים יפעלו.

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

  2. יוצרים חשבון שירות ב-Kubernetes:

    kubectl create serviceaccount KSA_NAME \
  --namespace=NAMESPACE

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

    • ‫KSA_NAME: השם של חשבון השירות של Kubernetes שתציינו במשאב GCPDataSource. משימת ההעברה שנוצרה על ידי GKE Volume Populator משתמשת בחשבון השירות הזה כדי לבצע אימות ל- Cloud de Confiance by S3NS APIs.
    • ‫NAMESPACE: מרחב השמות של Kubernetes שיצרתם בשלב הקודם.

  3. נותנים לחשבון השירות ב-IAM את התפקיד המתאים כדי לגשת לקטגוריה של Cloud Storage:

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

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

    • ‫GCS_BUCKET: שם הקטגוריה שלכם ב-Cloud Storage.
    • ‫PROJECT_NUMBER: המזהה המספרי של Cloud de Confiance by S3NS הפרויקט שבו יצרתם את האשכול. הוראות לאיתור מספר הפרויקט מופיעות במאמר זיהוי פרויקטים.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance by S3NS .
    • ‫NAMESPACE: מרחב השמות שיצרתם קודם, שבו יפעלו עומסי העבודה.
    • ‫KSA_NAME: השם של חשבון השירות של Kubernetes שציינתם במשאב GCPDataSource. משימת ההעברה שנוצרה על ידי GKE Volume Populator משתמשת בחשבון השירות הזה כדי לבצע אימות ל- Cloud de Confiance by S3NS APIs.
    • ‫ROLE: תפקיד ה-IAM שרוצים להקצות לחשבון השירות. לצורך המדריך הזה, נותנים את התפקיד roles/storage.objectViewer כדי לאפשר קריאה מהמאגר.

    הערכים PROJECT_NUMBER,‏ PROJECT_ID,‏ NAMESPACE ו-KSA_NAME משמשים ליצירת מזהה העיקרון של איחוד זהויות של עומסי עבודה ל-GKE עבור הפרויקט שלכם.

יצירת נפח Hyperdisk ML עם נתונים שנטענו מראש

כדי להגדיר את התשתית וההגדרה של GKE שנדרשות ליצירת נפח אחסון של Hyperdisk ML, ולהפעיל ולנהל את תהליך העברת הנתונים האוטומטי באמצעות GKE Volume Populator, מבצעים את השלבים הבאים:

  1. יוצרים GCPDataSource משאב בהתאמה אישית כדי להגדיר את מקור הנתונים.
  2. יוצרים StorageClass כדי להגדיר את סוג האחסון המתמיד (נפח Hyperdisk ML) שבו ייעשה שימוש.
  3. יוצרים PersistentVolumeClaim כדי להפעיל הקצאה דינמית של האחסון ולאפשר גישה לנפח Hyperdisk ML שהוקצה לאחרונה.
  4. (אופציונלי) הצגת ההתקדמות של העברת הנתונים.
  5. יוצרים ומפריסים Pod שצורכת את נפח ה-ML של Hyperdisk.

יצירת GCPDataSource משאב בהתאמה אישית

יוצרים GCPDataSource משאב בהתאמה אישית ב-GKE כדי לציין את המיקום של קטגוריית המקור ב-Cloud Storage ואת חשבון השירות עם ההרשאות הנדרשות לגישה לקטגוריה הזו. ההגדרה המותאמת אישית (CRD) הזו ספציפית ל-GKE Volume Populator.

  1. שומרים את קובץ המניפסט הבא בשם gcpdatasource.yaml.

    apiVersion: datalayer.gke.io/v1
kind: GCPDataSource
metadata:
 name: GCP_DATA_SOURCE
 namespace: NAMESPACE
spec:
 cloudStorage:
  serviceAccountName: KSA_NAME
  uri: gs://GCS_BUCKET/

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

    • ‫GCP_DATA_SOURCE: השם של ה-CRD‏ GCPDataSource שמכיל הפניה לקטגוריה של Cloud Storage. מידע נוסף זמין במאמר בנושא הפניה ל-CRD של GCPDataSource.
    • ‫NAMESPACE: אותו מרחב שמות שבו פועלים עומסי העבודה. משאב מותאם אישית GCPDataSource נוצר במרחב השמות הזה.
    • ‫KSA_NAME: השם של חשבון השירות של Kubernetes שציינתם במשאב GCPDataSource. משימת ההעברה שנוצרה על ידי GKE Volume Populator משתמשת בחשבון השירות הזה כדי לבצע אימות ל- Cloud de Confiance by S3NS APIs. הערך של cloudStorage.serviceAccountName הוא חשבון השירות של Kubernetes שהגדרתם עבור איחוד הזהויות של עומסי העבודה ב-GKE בקטע הגדרת ההרשאות הנדרשות.
    • ‫GCS_BUCKET: שם הקטגוריה שלכם ב-Cloud Storage. השדה uri מציין את נתוני המקור.
    • כדי להעתיק את כל הקטגוריה, משתמשים בפקודה gs://GCS_BUCKET/.
    • כדי להעתיק נתונים מתיקייה ספציפית בתוך הדלי, משתמשים בפורמט gs://GCS_BUCKET/PATH_INSIDE_BUCKET/. לדוגמה, כדי להעתין נתונים מהתיקייה gemma/v1.0/weights/ בתוך קטגוריית my-project-llm-models, ה-URI יהיה gs://my-project-llm-models/gemma/v1.0/weights/. חשוב לוודא שהנתיב מסתיים בלוכסן כדי לציין תיקייה.

  2. כדי ליצור את משאב GCPDataSource, מפעילים את המניפסט:

    kubectl apply -f gcpdatasource.yaml

יצירת Hyperdisk ML StorageClass

יוצרים StorageClass שמשתמש ב-provisioner‏ pd.csi.storage.gke.io כדי להקצות נפח אחסון של Hyperdisk ML באזור שבחרתם. אם רוצים שהעותקים של הנתונים יהיו נגישים ביותר מאזור אחד, אפשר ליצור StorageClass של כמה אזורים. דוגמה ל-StorageClass עם כמה אזורים

  1. שומרים את קובץ המניפסט הבא בשם hdml-class.yaml.

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: hyperdisk-ml-single-zone
parameters:
 type: hyperdisk-ml
 provisioned-throughput-on-create: "2400Mi"
provisioner: pd.csi.storage.gke.io
allowVolumeExpansion: false
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowedTopologies:
- matchLabelExpressions:
 - key: topology.gke.io/zone
  values:
  - ZONE

    מחליפים את ZONE בתחום היעד שבו רוצים ליצור את נפח ה-Hyperdisk ML:

    • באשכול GKE Standard ללא הקצאת משאבים אוטומטית של צמתים, הערך של ZONE צריך להיות המיקום שבו יצרתם את הצמתים.
    • באשכולות GKE Autopilot או באשכולות רגילים עם הקצאת משאבים אוטומטית של צמתים, הערך של ZONE צריך להיות המיקום שבו האשכול יכול להגדיל את הקיבולת וליצור צמתים חדשים אם נדרש.

  2. (אופציונלי) כדי להציג את מיקומי הצמתים של האשכול, מריצים את הפקודה הבאה:

    gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(locations)"

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

    • ‫CLUSTER_NAME: השם של האשכול.
    • ‫LOCATION: אזור או אזור מחשוב של האשכול. לדוגמה, us-central1-a או us-central1.

  3. כדי ליצור את StorageClass, מפעילים את המניפסט :

    kubectl apply -f hdml-class.yaml

יצירת דרישת נפח אחסון מתמיד (PersistentVolumeClaim) כדי לגשת לנפח האחסון

במניפסט הבא מוצגת דוגמה ליצירת PersistentVolumeClaim במצב גישה ReadOnlyMany שמפנה אל StorageClass שיצרתם קודם.

  1. שומרים את קובץ המניפסט הבא בשם volume-populator-pvc.yaml:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: PVC_NAME
 namespace: NAMESPACE
spec:
 accessModes:
 - ReadOnlyMany
 storageClassName: hyperdisk-ml-single-zone
 resources:
  requests:
   storage: DISK_SIZE
 dataSourceRef:
  apiGroup: datalayer.gke.io
  kind: GCPDataSource
  name: GCP_DATA_SOURCE

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

    • ‫PVC_NAME: השם של PersistentVolumeClaim שאליו רוצים להעביר את הנתונים.
    • ‫NAMESPACE: מרחב השמות שבו יפעלו עומסי העבודה.
    • ‫DISK_SIZE: גודל הדיסק, בגיגה-בייט, שייווצר כדי לאכלס נתונים. כדי לאכלס את הנתונים בהצלחה, צריך לוודא שגודל הדיסק שנדרש גדול יותר מגודל הנתונים של המודל שנמצאים בקטגוריה של Cloud Storage. כדי שהערך של DISK_SIZE יהיה בטווח הנתמך של נפחי ה-Hyperdisk ML, הוא צריך להיות גדול מ-4 Gi. מידע נוסף זמין במאמר בנושא מגבלות הגודל של נפחי Hyperdisk.
    • ‫GCP_DATA_SOURCE: השם של GCPDataSource CRD שמכיל הפניה לקטגוריה שלכם ב-Cloud Storage.

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

    • ‫volume-populator.datalayer.gke.io/cpu-request: משתמשים בהערה הזו כדי לציין בקשה אחרת למשאבי CPU להעברה Job. אם לא מציינים בקשה אחרת למשאבי CPU, ה-PVC מבקש כברירת מחדל 24 vCPU כדי לבצע אופטימיזציה לביצועי ההעברה.

    • ‫volume-populator.datalayer.gke.io/transfer-path: משתמשים בהערה הזו כדי לציין את נתיב היעד בתוך הנפח החדש שבו יישמרו הנתונים שהועתקו מהמשאב GCPDataSource. אם לא מציינים נתיב אחר, הנתונים מועתקים לנתיב הבסיס בנפח Hyperdisk ML.

  2. כדי ליצור את ה-PVC, מפעילים את המניפסט:

    kubectl apply -f volume-populator-pvc.yaml

חשוב לשים לב לנקודות הבאות:

  • אם מגדירים את השדה volumeBindingMode ב-StorageClass לערך immediate, העברת הנתונים מופעלת מיד אחרי הפריסה של ה-PVC.
  • אם מגדירים את השדה volumeBindingMode ב-StorageClass ל-WaitForFirstConsumer, העברת הנתונים מופעלת רק אחרי פריסת Pod שמבקש את ה-PVC, ואחרי שה-Pod הזה מתוזמן בהצלחה לצומת. אפשר לתזמן את ה-Pod, אבל הקונטיינרים ימתינו עד להשלמת העברת הנתונים ועד שהנפח יהיה מוכן לשימוש.

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

(אופציונלי) צפייה בהתקדמות העברת הנתונים

בקטע הזה מוסבר איך לעקוב אחרי ההתקדמות וההצלחה של העברות נתונים מקטגוריה ב-Cloud Storage לנפח אחסון של Hyperdisk ML.

  1. כדי לאמת את הסטטוס של PersistentVolumeClaim, מריצים את הפקודה הבאה. אפשר להריץ את הפקודה הזו גם אם פעולת הקישור של PersistentVolumeClaim נמשכת יותר מדי זמן.

    kubectl describe pvc PVC_NAME -n NAMESPACE

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

  2. בפלט, בודקים את האירועים של PersistentVolumeClaim כדי לעקוב אחרי התקדמות העברת הנתונים. יומני GKE מתעדכנים בערך פעם בדקה. הפלט אמור להיראות כך:

    Name:     vp-pvc
Namespace:   default
StorageClass: hyperdisk-ml-single-zone
Status:    Bound
Volume:    pvc-f7ae2ee2-106d-4b87-b458-481a3ff82b62
Labels:    <none>
Annotations:  pv.kubernetes.io/bind-completed: yes
       pv.kubernetes.io/bound-by-controller: yes
       volume.beta.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
       volume.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
Finalizers:  [kubernetes.io/pvc-protection]
Capacity:   200Gi
Access Modes: ROX
VolumeMode:  Filesystem
DataSource:
 APIGroup: datalayer.gke.io
 Kind:   GCPDataSource
 Name:   vp-gds
Used By:   verify-data-665cfd4dbf-mwc7t
      verify-data-665cfd4dbf-n7xw9
Events:
 Type   Reason             Age           From                                               Message
 ----   ------             ----          ----                                               -------
 Warning ProvisioningFailed       9m8s          persistentvolume-controller                                    Error saving claim: Operation cannot be fulfilled on persistentvolumeclaims "vp-pvc": the object has been modified; please apply your changes to the latest version and try again
 Normal  Provisioning          9m5s          pd.csi.storage.gke.io_gke-f110123a1cbd44cdaa7a-921b-b1f4-vm_1a100bd9-5231-4f20-8e65-1f8e995a03c0 External provisioner is provisioning volume for claim "default/vp-pvc"
 Normal  Provisioning          9m5s          external-provisioner                                       Assuming an external populator will provision the volume
 Normal  PopulateOperationStartSuccess 8m58s          gkevolumepopulator-populator                                   populateFn: Populate operation started for zone us-central1-c
 Normal  TransferInProgress       8m58s (x2 over 8m58s)  gkevolumepopulator-populator                                   populateCompleteFn: For PVC vp-pvc in namespace default, transfer job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f in zone us-central1-c waiting for pod to get created
 Normal  TransferInProgress       6m10s (x14 over 8m57s) gkevolumepopulator-populator                                   populateCompleteFn: For PVC vp-pvc in namespace default, transfer job in zone us-central1-c with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f is still active with pod status as - Phase: Pending
 Normal  ExternalProvisioning      3m35s (x24 over 9m5s)  persistentvolume-controller                                    Waiting for a volume to be created either by the external provisioner 'pd.csi.storage.gke.io' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.
 Normal  TransferJobCompleted      3m24s (x2 over 3m26s)  gkevolumepopulator-populator                                   populateCompleteFn: For PVC vp-pvc in namespace default, job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f for zone us-central1-c completed successfully
 Normal  TransferJobCompleted      3m24s (x2 over 3m26s)  gkevolumepopulator-populator                                   populateCompleteFn: For PVC vp-pvc in namespace default, transfer job for all zones have completed successfully
 Normal  PopulateOperationFinished   3m24s (x2 over 3m26s)  gkevolumepopulator-populator                                   Populate operation finished
 Normal  PopulatorFinished       3m19s (x3 over 3m20s)  gkevolumepopulator-populator                                   Populator finished

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

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

יצירה ופריסה של Pod שמשתמש בנפח האחסון

כדי ליצור Pod ולאמת את התוכן של PVC שאוכלס בנתונים:

  1. שומרים את קובץ המניפסט הבא בשם verify-data.yaml:

    apiVersion: v1
kind: Pod
metadata:
 name: verify-data
 namespace: NAMESPACE
spec:
 nodeSelector:
  cloud.google.com/compute-class: gcs-to-hdml-compute-class
 containers:
 - name: verify-data
  image: busybox
  command:
  - sleep
  - infinity
  volumeMounts:
   - mountPath: /models
    name: mypvc
 volumes:
 - name: mypvc
  persistentVolumeClaim:
   claimName: PVC_NAME

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

  2. יוצרים את ה-Pod באמצעות הפקודה הבאה:

    kubectl create -f verify-data.yaml

  3. כדי להציג את רשימת הקבצים, מריצים את הפקודה הבאה:

    kubectl exec -it verify-data -- /bin/sh
# cd /models && ls

אם הפקודה תצליח, תוכלו למצוא את הנתונים שהוזנו בספרייה /models בקטגוריה של Cloud Storage.

הסרת המשאבים

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

מחיקת ה-PersistentVolumeClaim במהלך הקצאה דינמית

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

במהלך תהליך המחיקה, מחליפים את המשתנים הרלוונטיים הבאים:

  1. מחיקת ה-Pod של עומס העבודה:

    kubectl delete pod POD_NAME -n NAMESPACE

  2. מאתרים את השם של PersistentVolumeClaim הזמני:

    # Store the relevant environment variables
export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE

    # Check the status
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 שנוצר במרחב השמות:

    kubectl delete pvc PVC_NAME -n NAMESPACE

  4. יכול להיות שה-PVC תקוע במצב Terminating:

    NAME      STATUS    VOLUME  CAPACITY  ACCESS MODES  STORAGECLASS        VOLUMEATTRIBUTESCLASS  AGE
vp-pvc  Terminating                   hyperdisk-ml  <unset>         7m23s

    אם כן, צריך לנקות את ה-PVC באופן ידני על ידי הסרת ה-finalizers שלו:

    kubectl patch pvc PVC_NAME -n NAMESPACE -p '{"metadata":{"finalizers":null}}'

  5. מוחקים את המשאב GCPDataSource רק אחרי שמוחקים את ה-PVC. אם מוחקים קודם את המשאב GCPDataSource, מחיקת ה-PVC נתקעת.

    kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE

  6. בודקים שהמשאבים הזמניים נמחקו.

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