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

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

המדריך הזה מיועד למומחי אחסון שיוצרים ומקצים אחסון, ומנהלים את אבטחת מידע והגישה אליהם. מידע נוסף על תפקידים נפוצים ודוגמאות למשימות שאנחנו מתייחסים אליהן ב 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 של Persistent Disk ב-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
מידע נוסף ניהול הקצאות אוטומטי של צמתים וסוגי מחשוב הגדרה של מאגרי צמתים שנוצרו באופן ידני

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

יצירת אשכול GKE

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

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

טייס אוטומטי

באשכולות 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, מוגדר מראש למשימת ההעברה, וחובה לציין אותו בדיוק.

כדי ליצור אשכול סטנדרטי חדש ללא הקצאת צמתים אוטומטית (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)

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

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

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

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