גישה למכונות Managed Lustre קיימות ב-GKE באמצעות מנהל התקן ה-CSI של Managed Lustre

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

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

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

  • מפעילים את Google Cloud Managed Lustre API ואת Google Kubernetes Engine API.
    • הפעלת ממשקי API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

הגדרה של משתני סביבה

מגדירים את משתני הסביבה הבאים:

export CLUSTER_NAME=CLUSTER_NAME
export PROJECT_ID=PROJECT_ID
export NETWORK_NAME=LUSTRE_NETWORK
export LOCATION=ZONE

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫PROJECT_ID: Google Cloud מזהה הפרויקט.
  • ‫LUSTRE_NETWORK: הרשת של הענן הווירטואלי הפרטי (VPC) המשותף שבה נמצאים גם אשכול GKE וגם מופע Managed Lustre.
  • ‫ZONE: האזור הגיאוגרפי של אשכול GKE, לדוגמה us-central1-a.

הגדרת מנהל התקן CSI של Managed Lustre

בקטע הזה מוסבר איך להפעיל ולהשבית את מנהל ההתקן של Managed Lustre CSI, אם צריך.

הפעלת הדרייבר המנוהל של Lustre CSI באשכול GKE חדש

כדי להפעיל את מנהל התקן CSI של Managed Lustre כשיוצרים אשכול GKE חדש, פועלים לפי השלבים הבאים:

טייס אוטומטי

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=1.33.2-gke.1111000 \
    --enable-lustre-csi-driver \
    --enable-legacy-lustre-port

רגילה

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=1.33.2-gke.1111000 \
    --addons=LustreCsiDriver \
    --enable-legacy-lustre-port

הפעלת הדרייבר המנוהל של Lustre CSI באשכול GKE קיים

אם רוצים להפעיל את מנהל התקן ה-CSI של Managed Lustre באשכול GKE קיים, משתמשים בפקודה הבאה:

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-legacy-lustre-port

נדרש שדרוג צמתים באשכולות קיימים

הפעלת מנהל התקן ה-CSI של Managed Lustre באשכולות קיימים יכולה להפעיל מחדש את הצומת כדי לעדכן את מודולי הליבה הנדרשים עבור לקוח Managed Lustre. כדי שהשדרוג יהיה זמין באופן מיידי, מומלץ לשדרג את מאגרי הצמתים באופן ידני.

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

עד שהשדרוג של הצומת יושלם, יכול להיות ש-Pod של מנהל התקן CSI יבצע לולאת קריסה בצמתים שממתינים לעדכון. אם מופיעה שגיאת Operation not permitted ביומני ה-Pod של מנהל ההתקן של CSI, צריך לשדרג את הצומת או ליצור אותו מחדש.

אחרי השדרוג של מאגר הצמתים, יכול להיות שצמתי CPU יופיעו כמשתמשים בתמונת GPU במסוףGoogle Cloud או בפלט של CLI. לדוגמה:

config:
  imageType: COS_CONTAINERD
  nodeImageConfig:
    image: gke-1330-gke1552000-cos-121-18867-90-4-c-nvda

זו התנהגות צפויה. קובץ האימג' של ה-GPU עובר שימוש חוזר בצמתי CPU כדי להתקין באופן מאובטח את מודולי הליבה של Managed Lustre. לא תחויבו על השימוש ב-GPU.

השבתה של מנהל התקן CSI של Managed Lustre

אפשר להשבית את מנהל ההתקן של Managed Lustre CSI באשכול GKE קיים באמצעות Google Cloud CLI.

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --update-addons=LustreCsiDriver=DISABLED

אחרי שמשביתים את מנהל ההתקן של CSI, הצמתים נוצרים מחדש באופן אוטומטי, ומודולי הליבה של Managed Lustre מוסרים מהצמתים של GKE.

גישה למכונה קיימת ב-Managed Lustre באמצעות מנהל התקן ה-CSI של Managed Lustre

אם כבר הקציתם מכונה ב-Managed Lustre באותה רשת כמו אשכול GKE, תוכלו לפעול לפי ההוראות האלה כדי להקצות באופן סטטי PersistentVolume שמפנה למכונה.

בקטעים הבאים מתואר התהליך האופייני לגישה למופע קיים של Managed Lustre באמצעות מנהל ההתקן של Managed Lustre CSI:

  1. יוצרים PersistentVolume שמפנה למכונת Managed Lustre.
  2. משתמשים ב-PersistentVolumeClaim כדי לגשת לנפח האחסון.
  3. יוצרים עומס עבודה שמשתמש בנפח האחסון.

יצירת PersistentVolume

  1. כדי לאתר את מכונת Managed Lustre, מריצים את הפקודה הבאה.

    gcloud lustre instances list \
    --project=${PROJECT_ID} \
    --location=${LOCATION}

    הפלט אמור להיראות כך: לפני שעוברים לשלב הבא, חשוב לרשום את שם המכונה ב-Managed Lustre, את מערכת הקבצים ואת השדה mountPoint.

    capacityGib: '9000'
createTime: '2025-04-28T22:42:11.140825450Z'
filesystem: testlfs
gkeSupportEnabled: true
mountPoint: 10.90.1.4@tcp:/testlfs
name: projects/my-project/locations/us-central1-a/instances/my-lustre
network: projects/my-project/global/networks/default
perUnitStorageThroughput: '1000'
state: ACTIVE
updateTime: '2025-04-28T22:51:41.559098631Z'

  2. שומרים את המניפסט הבא בקובץ בשם lustre-pv.yaml:

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: lustre-pv
spec:
  storageClassName: "STORAGE_CLASS_NAME"
  capacity:
    storage: 9000Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
  claimRef:
    namespace: default
    name: lustre-pvc
  csi:
    driver: lustre.csi.storage.gke.io
    volumeHandle: "PROJECT_ID/LOCATION/INSTANCE_NAME"
    volumeAttributes:
      ip: IP_ADDRESS
      filesystem: FILESYSTEM

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

    • ‫storageClassName: השם של StorageClass. הערך יכול להיות מחרוזת ריקה, אבל הוא צריך לעמוד בדרישות של PersistentVolumeClaim.
    • ‫volumeHandle: המזהה של אמצעי האחסון הזה.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫LOCATION: המיקום האזורי של מופע Lustre. צריך לציין אזור נתמך עבור מנהל התקן CSI של Managed Lustre.
      • ‫INSTANCE_NAME: השם של מופע Lustre.
    • ‫ip: כתובת ה-IP של מופע Lustre. מקבלים את הערך הזה מהשדה mountPoint בפלט של הפקודה הקודמת.
    • ‫filesystem: השם של מערכת הקבצים של מכונת Managed Lustre.

    רשימה מלאה של השדות שנתמכים באובייקט PersistentVolume מופיעה במסמכי העזר של מנהל התקן CSI של Managed Lustre.

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

    kubectl apply -f lustre-pv.yaml

שימוש ב-PersistentVolumeClaim כדי לגשת לנפח האחסון

אתם יכולים ליצור משאב PersistentVolumeClaim שמפנה אל StorageClass של מנהל ההתקן Lustre CSI המנוהל.

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

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

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: lustre-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: "STORAGE_CLASS_NAME"
  volumeName: lustre-pv
  resources:
    requests:
      storage: STORAGE_SIZE

    מחליפים את STORAGE_SIZE בגודל האחסון, לדוגמה, 9000Gi. היא צריכה להיות זהה למפרט ב-PersistentVolume.

  2. מריצים את הפקודה הבאה כדי ליצור את PersistentVolumeClaim:

    kubectl create -f lustre-pvc.yaml

יצירת עומס עבודה שמשתמש בנפח האחסון

בקטע הזה מוסבר איך ליצור Pod שמשתמש במשאב PersistentVolumeClaim שיצרתם קודם.

כמה Pods יכולים לחלוק את אותו משאב PersistentVolumeClaim.

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

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
      - name: lustre-volume
        mountPath: /data
  volumes:
  - name: lustre-volume
    persistentVolumeClaim:
      claimName: lustre-pvc

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

    kubectl apply -f my-pod.yaml

    ה-Pod ממתין עד ש-GKE יקצה את PersistentVolumeClaim לפני שהוא מתחיל לפעול. השלמת הפעולה עשויה להימשך כמה דקות.

  3. מוודאים שה-Pod פועל:

    kubectl get pods

    יכול להיות שיחלפו כמה דקות עד שה-Pod יגיע למצב Running.

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

    NAME           READY   STATUS    RESTARTS   AGE
my-pod         1/1     Running   0          11s

שימוש ב-fsGroup עם אמצעי אחסון של Managed Lustre

אפשר לשנות את הבעלות על הקבוצה של ספריית הרמה הבסיסית של מערכת הקבצים המצורפת כך שתתאים ל-fsGroup שצוין על ידי המשתמש ב-SecurityContext של ה-Pod.

פתרון בעיות

הנחיות לפתרון בעיות מופיעות בדף לפתרון בעיות במסמכי התיעוד של Managed Lustre.

הסרת המשאבים

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

  1. מוחקים את ה-Pod ואת PersistentVolumeClaim.

    kubectl delete pod my-pod
kubectl delete pvc lustre-pvc

  2. בודקים את הסטטוס של PersistentVolume. אחרי שמוחקים את ה-Pod ואת PersistentVolumeClaim, צריך לראות שהסטטוס של PersistentVolume הוא Released:

    kubectl get pv

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

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                 STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX            Retain        Released   default/preprov-pvc                           2m28s

  3. שימוש חוזר בנפח אחסון מתמיד. כדי לעשות שימוש חוזר בנפח האחסון המתמיד, מסירים את ההפניה ל-PersistentVolumeClaim ‏ (claimRef):

    kubectl patch pv lustre-pv --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'

    הסטטוס של PersistentVolume צריך להיות עכשיו Available (זמין), כלומר הוא מוכן לקישור ל-PersistentVolumeClaim חדש. בודקים את הסטטוס של PersistentVolume:

    kubectl get pv

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

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX           Retain         Available                                   19m

  4. מוחקים את ה-PersistentVolume אם הוא כבר לא נחוץ. אם אין יותר צורך ב-PersistentVolume, מוחקים אותו:

    kubectl delete pv lustre-pv

    מחיקה של PersistentVolume לא מסירה את המכונה הבסיסית של Managed Lustre.

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