אופטימיזציה של הביצועים והעלויות של האחסון באמצעות מאגרי אחסון של Hyperdisk

במאמר הזה מוסבר איך לשפר את הביצועים של אחסון ב-Google Kubernetes Engine ‏ (GKE) ולצמצם את העלויות ב-GKE באמצעות מאגרי אחסון של Hyperdisk.

כדי לבצע אופטימיזציה של הביצועים והעלות של האחסון בעומסי עבודה עם שמירת מצב באשכולות GKE, משתמשים ב-GKE Hyperdisk Storage Pools. המאגרים האלה מאפשרים לכם לשתף ביעילות את קיבולת האחסון, קצב העברת הנתונים ופעולות הקלט/פלט בשנייה (IOPS) בין כמה אמצעי אחסון של Hyperdisk. התמיכה ב-Hyperdisk תלויה בסוגי המכונות של הצמתים. מידע נוסף זמין במאמר בנושא תמיכה בסדרות מכונות ב-Hyperdisk.

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

סקירה כללית

מאגרי אחסון מקבצים באופן לוגי התקני אחסון פיזיים, ומאפשרים לכם לפלח את המשאבים. אתם יכולים להקצות Google Cloud Hyperdisks בתוך מאגרי האחסון האלה, וכך ליצור בעצם מאגרי אחסון של Hyperdisk. ‫Hyperdisk Storage Pools מציעים קיבולת, תפוקה ו-IOPS שהוקצו מראש, והדיסקים של אשכול GKE יכולים לחלוק אותם.

אתם יכולים להשתמש ב-Hyperdisk Storage Pools כדי לנהל את משאבי האחסון בצורה יעילה יותר וחסכונית יותר. כך תוכלו ליהנות מטכנולוגיות יעילות כמו ביטול כפילויות והקצאת אחסון לפי צורך (Thin Provisioning).

במדריך הזה משתמשים באזור us-east4-c כדי ליצור את Hyperdisk Balanced Storage Pool ומשאבים אחרים.

שיקולים בתכנון

לפני שמקצים נפח אחסון ב-Hyperdisk Storage Pool ומשתמשים בו, חשוב לקרוא את הדרישות והמגבלות הבאות.

יצירה וניהול של מאגרי אחסון

הדרישות והמגבלות הבאות חלות:

• כל המגבלות של Compute Engine Hyperdisk Storage Pools חלות.
• כל המגבלות שחלות על יצירת דיסקים ב-Hyperdisk Storage Pool חלות גם כאן.
• סוג ה-Hyperdisk Storage Pool שיוצרים קובע את סוגי הדיסקים שאפשר ליצור במאגר האחסון. סוגי Hyperdisk Storage Pools

הקצאת דיסקים לאתחול במאגרי אחסון

הדרישות והמגבלות הבאות חלות:

• אין תמיכה בהקצאת דיסקים לאתחול במאגרי אחסון במאגרי צמתים שמופעל בהם Node Auto Provisioning.
• מוודאים שמיקומי הצמתים של האשכול ומיקומי הצמתים של מאגר הצמתים זהים בדיוק לאזורים של מאגר האחסון.
• מוודאים שסוג המכונה שמריץ את ה-Pod תומך בצירוף של Hyperdisk מסוג Balanced. אי אפשר להשתמש ב-Hyperdisk Throughput כבדיסק אתחול. מידע נוסף על תמיכה בסוגי מכונות של Hyperdisk
• אפשר להקצות דיסקים לאתחול במאגרי אחסון רק במאגרי צמתים שנוצרו או עודכנו באופן ידני.

הקצאת דיסק מצורף במאגרי אחסון

הדרישות והמגבלות הבאות חלות:

• הגרסה המינימלית של GKE שנדרשת להקצאת דיסקים מצורפים ב-Storage Pools היא ‎1.29.2-gke.1035000 ואילך.
• מוודאים שמנהל התקן (driver) של CSI לדיסק לאחסון מתמיד ב-Compute Engine מופעל. הדרייבר של דיסק מתמשך ב-Compute Engine מופעל כברירת מחדל באשכולות חדשים במצב Autopilot ובמצב Standard, ואי אפשר להשבית או לערוך אותו באשכולות במצב Autopilot. הוראות להפעלת ה-Driver מופיעות במאמר בנושא הפעלת ה-CSI Driver של Persistent Disk ב-Compute Engine באשכול קיים.
• מוודאים שמאגר האחסון נמצא לפחות באחד ממיקומי הצמתים של האשכול ובמיקומי הצמתים של מאגר הצמתים.
• אפשר להקצות רק דיסקים מסוג Hyperdisk Throughput ו-Hyperdisk Balanced שמצורפים ל-Storage Pools. הסוג של הדיסק המצורף חייב להיות זהה לסוג של Storage Pool. מידע נוסף זמין במאמר בנושא סוגים של מאגרי אחסון של Hyperdisk.
• ב-StorageClass, מותר להשתמש רק ב-Storage Pool אחד לכל אזור.
• ב-StorageClass, לכל מאגרי האחסון צריך להיות סוג מאגר האחסון.
• חשוב לוודא שסוג המכונה שמריץ את ה-Pod תומך בחיבור סוג הדיסק שבו אתם משתמשים מ-Storage Pool. מידע נוסף זמין במאמר בנושא תמיכה בסוגי מכונות של Hyperdisk.

מכסה

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

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

אפשר להשתמש במסנני המכסות הבאים ל-Hyperdisk Balanced Storage Pools:

• ‫HDB-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: כדי להגדיל את הקיבולת באמצעות הקצאת קיבולת מתקדמת.
• ‫HDB-STORAGE-POOL-TOTAL-ADVANCED-IOPS-per-project-region: כדי להגדיל את ה-IOPS באמצעות הקצאת ביצועים מתקדמת.
• ‫HDB-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: כדי להגדיל את קצב העברת הנתונים באמצעות הקצאת משאבים מתקדמת לשיפור הביצועים.
• ‫HDB-TOTAL-GB-per-project-region: כדי להגדיל את הקיבולת באמצעות הקצאת קיבולת רגילה.
• ‫HDB-TOTAL-IOPS-per-project-region: כדי להגדיל את ה-IOPS באמצעות הקצאת ביצועים רגילה.
• ‫HDB-TOTAL-THROUGHPUT-per-project-region: כדי להגדיל את קצב העברת הנתונים באמצעות הקצאת משאבים לביצועים רגילים.

אפשר להשתמש במסנני המכסות הבאים ל-Hyperdisk Throughput Storage Pools:

• ‫HDT-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: כדי להגדיל את הקיבולת באמצעות הקצאת קיבולת מתקדמת.
• ‫HDT-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: כדי להגדיל את קצב העברת הנתונים באמצעות הקצאת משאבים מתקדמת לשיפור הביצועים.
• ‫HDT-TOTAL-GB-per-project-region: כדי להגדיל את הקיבולת באמצעות הקצאת קיבולת רגילה.
• ‫HDT-TOTAL-THROUGHPUT-per-project-region: כדי להגדיל את קצב העברת הנתונים באמצעות הקצאת משאבים לביצועים רגילים.

לדוגמה, אם רוצים להגדיל את הקיבולת הכוללת של מאגרי Hyperdisk Balanced עם הקצאת קיבולת מתקדמת, לכל פרויקט ולכל אזור, צריך לבקש מכסה גבוהה יותר עבור המסנן הבא:

hdb-storage-pool-total-advanced-capacity-per-project-region.

תמחור

פרטים על התמחור מופיעים במאמר תמחור של Hyperdisk Storage Pools .

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

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

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

• כדאי לעיין באזורים ובאזורי זמינות נתמכים כדי ליצור מאגר אחסון מאוזן של Hyperdisk.

יצירת Hyperdisk Storage Pool

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

חשוב לוודא שאתם יוצרים מאגרי אחסון באחד מהאזורים הנתמכים.

לדוגמה, משתמשים בפקודה הבאה כדי ליצור Hyperdisk Balanced Storage Pool עם קיבולת מתקדמת וביצועים מתקדמים, ולהקצות קיבולת של 10TB,‏ 10,000 IOPS/s וקצב העברת נתונים של 1,024MBps באזור us-east4-c:

export PROJECT_ID=PROJECT_ID
export ZONE=us-east4-c
gcloud compute storage-pools create pool-$ZONE \
  --provisioned-capacity=10tb --storage-pool-type=hyperdisk-balanced \
  --zone=$ZONE --project=$PROJECT_ID --capacity-provisioning-type=advanced \
  --performance-provisioning-type=advanced --provisioned-iops=10000 \
  --provisioned-throughput=1024

מחליפים את PROJECT_ID במזהה הפרויקט של Cloud de Confiance by S3NS החשבון.

בדיקת האזורים של Storage Pool

• באשכולות במצב Autopilot ובאשכולות רגילים שבהם מופעלת הקצאת צמתים אוטומטית (NAP), אפשר ליצור Storage Pool בכל תחום (zone) באזור של האשכול. אם אין מאגר צמתים באזור שבו יצרתם את Storage Pool, ה-Pods יישארו במצב Pending עד שהכלי לשינוי גודל האשכול ב-GKE יוכל להקצות מאגר צמתים חדש באזור הזה.

• באשכולות Standard ללא הקצאה אוטומטית של צמתים, צריך ליצור מאגרי אחסון באזורי הצמתים שמוגדרים כברירת מחדל באשכול, כי מאגרי אחסון הם משאבים אזוריים. אפשר להגדיר את אזורי הצמתים של האשכול באמצעות הדגל --node-locations.

  • במקרה של אשכולות אזוריים, אם לא מציינים את --node-locations, כל הצמתים נוצרים באזור הראשי של האשכול.
  • במקרה של אשכולות אזוריים, אם לא מציינים את --node-locations, ‏ GKE מחלקת את צמתי העובדים בשלושה אזורים שנבחרו באופן אקראי בתוך האזור.

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

gcloud container clusters describe CLUSTER_NAME | yq '.locations'

מחליפים את CLUSTER_NAME בשם של האשכול שרוצים ליצור בזמן הקצאת דיסק אתחול או דיסק מצורף.

הקצאת דיסק אתחול של GKE ב-Hyperdisk Storage Pool

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

• כשיוצרים אשכול GKE חדש
• כשיוצרים מאגר צמתים חדש
• כשמעדכנים מאגר צמתים קיים

כשיוצרים אשכול

כדי ליצור אשכול GKE עם דיסקים לאתחול שהוקצו ב-Storage Pool, משתמשים בפקודה הבאה:

gcloud container clusters create CLUSTER_NAME \
  --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
  --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
  --location=CONTROL_PLANE_LOCATION

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

• ‫CLUSTER_NAME: מזינים שם ייחודי לאשכול שיוצרים.
• ‫DISK_TYPE: מגדירים את הערך hyperdisk-balanced.. אם לא מציינים ערך, סוג הדיסק מוגדר כברירת מחדל ל-Hyperdisk Balanced.
• ‫STORAGE_POOL,[...]: רשימה מופרדת בפסיקים של נתיבי משאבים של Storage Pool (לדוגמה, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c) שבהם יוקצו דיסקי האתחול של האשכול. מוודאים שהאזורים בנתיבי המשאבים של Storage Pool זהים לאזורים ב---node-locations.
• ‫ZONE,[...]: רשימה מופרדת בפסיקים של אזורים שבהם צריך לשכפל את טביעת הרגל של הצומת. במקום זאת, אפשר לציין אזורים עבור אשכולות אזוריים. כל האזורים צריכים להיות באותו אזור כמו האשכול, כפי שמצוין בדגל --location.
• ‫MACHINE_TYPE: סוג המכונה הנתמך שרוצים להשתמש בו לצמתים.
• ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור לאשכולות אזוריים.

כשיוצרים מאגר צמתים

כדי ליצור מאגר צמתים של GKE עם דיסקים לאתחול שמוקצים ב-Storage Pool, משתמשים בפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
  --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
  --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
  --location=CONTROL_PLANE_LOCATION --cluster=CLUSTER_NAME

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

• ‫NODE_POOL_NAME: מציינים שם ייחודי למאגר הצמתים שיוצרים.
• ‫DISK_TYPE: מגדירים את הערך hyperdisk-balanced.. אם לא מציינים ערך, סוג הדיסק מוגדר כברירת מחדל ל-Hyperdisk Balanced.
• ‫STORAGE_POOL,[...]: רשימה מופרדת בפסיקים של נתיבי משאבים של Storage Pool (לדוגמה, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c) שבהם יוקצו דיסקים לאתחול של האשכול. מוודאים שהאזורים בנתיבי המשאבים של Storage Pool תואמים לערכים ב---node-locations.
• ‫ZONE,[...]: רשימה מופרדת בפסיקים של אזורים שבהם צריך לשכפל את טביעת הרגל של הצומת. כל האזורים צריכים להיות באותו אזור כמו האשכול, שמוגדר באמצעות הדגל -location.
• ‫MACHINE_TYPE: סוג המכונה הנתמך שרוצים להשתמש בו לצמתים.
• ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור לאשכולות אזוריים.
• ‫CLUSTER_NAME: אשכול קיים שבו יוצרים את מאגר הצמתים.

כשמעדכנים מאגר צמתים

אפשר להשתמש בפקודה update כדי להוסיף מאגרי אחסון או להחליף אותם במאגר צמתים. אי אפשר להשתמש בפקודה הזו כדי להסיר מאגרי אחסון ממאגר צמתים.

כדי לעדכן מאגר צמתים של GKE כך שדיסקי האתחול שלו יוקצו ב-Storage Pool, משתמשים בפקודה הבאה.

gcloud container node-pools update NODE_POOL_NAME \
 --storage-pools=STORAGE_POOL,[...] \
 --location=CONTROL_PLANE_LOCATION --cluster=CLUSTER_NAME

• ‫NODE_POOL_NAME: השם של מאגר צמתים קיים שרוצים לעדכן כדי להשתמש ב-Storage Pool.
• ‫STORAGE_POOL,[...]: רשימה מופרדת בפסיקים של נתיבי משאבים קיימים של Storage Pool (לדוגמה, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c). חשוב לוודא שהאזורים בנתיבי המשאבים של Storage Pool תואמים לאזור של מאגר הצמתים שאתם מעדכנים.
• ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור לאשכולות אזוריים.
• ‫CLUSTER_NAME: השם של אשכול GKE שאליו שייך מאגר הצמתים הזה.

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

הקצאת דיסק מצורף ל-GKE ב-Hyperdisk Storage Pool

בקטע הזה:

• יוצרים אשכול GKE חדש עם דיסקים מצורפים שהוקצו ב-Storage Pool.
• יוצרים StorageClass כדי להקצות באופן דינמי PersistentVolume (PV) כשקבוצת Pod מבקשת אותו דרך PersistentVolumeClaim (PVC). כדי ש-PV ינצל את המשאבים המשותפים של Storage Pool, צריך לציין את Storage Pool באמצעות הפרמטר storage-pools ב-StorageClass. לאחר מכן, נעשה שימוש ב-StorageClass ב-PVC כדי להקצות את נפח האחסון המאוזן של Hyperdisk שבו ה-Pod ישתמש.
• יוצרים PVC כדי לבקש PV – חלק מאחסון Hyperdisk – בשביל Pod מאשכול GKE. כך תוכלו ליהנות מהמשאבים המשותפים של מאגר האחסון.
• יוצרים Deployment שמשתמש ב-PVC כדי לוודא שלאפליקציה יש גישה לאחסון מתמיד גם אחרי הפעלה מחדש של Pod ותזמון מחדש.

יצירת אשכול GKE

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

gcloud container clusters create-auto CLUSTER_NAME --location=CONTROL_PLANE_LOCATION

gcloud container clusters create CLUSTER_NAME --location=CONTROL_PLANE_LOCATION --project=PROJECT_ID --machine-type=MACHINE_TYPE --disk-type="DISK_TYPE"

יצירת StorageClass

ב-Kubernetes, כדי לציין שרוצים שה-PV ייצור בתוך Storage Pool, צריך להשתמש ב-StorageClass. מידע נוסף זמין במאמר בנושא StorageClasses.

כדי ליצור StorageClass חדש עם רמת התפוקה או ה-IOPS הרצויה:

• משתמשים ב-pd.csi.storage.gke.io בשדה של כלי ההקצאה.
• מציינים את סוג האחסון Hyperdisk Balanced.
• מציינים את הפרמטר storage-pools עם ערך בתור רשימה של מאגרי אחסון ספציפיים שרוצים להשתמש בהם. כל מאגר אחסון ברשימה צריך להיות בפורמט: projects/PROJECT_ID/zones/ZONE/storagePools/STORAGE_POOL_NAME.
• אופציונלי: מציינים את פרמטר הביצועים provisioned-throughput-on-create ואת הפרמטר provisioned-iops-on-create.

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

הנחיות לגבי הערכים המותרים של קצב העברת הנתונים או של פעולות קלט/פלט בשנייה זמינות במאמר תכנון רמת הביצועים של נפח Hyperdisk.

אפשר להשתמש במניפסט הבא כדי ליצור StorageClass בשם storage-pools-sc ולהחיל אותו לצורך הקצאה דינמית של PV ב-Storage Pool projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c:

kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: storage-pools-sc
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
 type: hyperdisk-balanced
 provisioned-throughput-on-create: "140Mi"
 provisioned-iops-on-create: "3000"
 storage-pools: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c
EOF

אם משתמשים ב-volumeBindingMode: WaitForFirstConsumer ב-StorageClass הזה, הקישור וההקצאה של PVC מתעכבים עד שנוצר Pod שמשתמש ב-PVC. הגישה הזו עוזרת לוודא שה-PV לא מוקצה מוקדם מדי, ושיש התאמה בין האזור של ה-PV לבין הפוד שמשתמש בו. אם האזורים לא תואמים, ה-Pod נשאר במצב Pending.

יצירת בקשה לנפח אחסון מתמיד (PVC)

יוצרים PVC שמפנה אל storage-pools-sc StorageClass שיצרתם.

משתמשים במניפסט הבא כדי ליצור PVC בשם my-pvc, עם 2,048 GiB כקיבולת האחסון של יעד הנפח המאוזן של Hyperdisk:

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 storageClassName: storage-pools-sc
 accessModes:
 - ReadWriteOnce
 resources:
  requests:
   storage: 2048Gi
EOF

יצירת פריסה שמשתמשת ב-PVC

כדי לוודא שאפשר לתזמן Pods במאגר צמתים עם סדרת מכונות שתומכת ב-Hyperdisk Balanced, צריך להגדיר Deployment עם cloud.google.com/machine-familynode selector. מידע נוסף זמין במאמר בנושא תמיכה בסוגי מכונות ל-Hyperdisks. בדוגמה הבאה של פריסה נעשה שימוש בסדרת מכונות c3.

יוצרים את קובץ המניפסט הבא ומחילים אותו כדי להגדיר Pod לפריסת שרת אינטרנט של Postgres באמצעות ה-PVC שנוצר בקטע הקודם:

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: postgres
spec:
 selector:
  matchLabels:
   app: postgres
 template:
  metadata:
   labels:
    app: postgres
  spec:
   nodeSelector:
    cloud.google.com/machine-family: c3
    cloud.google.com/compute-class: Performance
   containers:
   - name: postgres
    image: postgres:14-alpine
    args: [ "sleep", "3600" ]
    volumeMounts:
    - name: sdk-volume
     mountPath: /usr/share/data/
   volumes:
   - name: sdk-volume
    persistentVolumeClaim:
     claimName: my-pvc
EOF

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: postgres
spec:
 selector:
  matchLabels:
   app: postgres
 template:
  metadata:
   labels:
    app: postgres
  spec:
   nodeSelector:
    cloud.google.com/machine-family: c3
   containers:
   - name: postgres
    image: postgres:14-alpine
    args: [ "sleep", "3600" ]
    volumeMounts:
    - name: sdk-volume
     mountPath: /usr/share/data/
   volumes:
   - name: sdk-volume
    persistentVolumeClaim:
     claimName: my-pvc
EOF

מוודאים שהפריסה נוצרה בהצלחה:

 kubectl get deployment

יכול להיות שיחלפו כמה דקות עד שהקצאת המשאבים של מופעי Hyperdisk תושלם ויוצג סטטוס READY.

בדיקה אם הוקצה נפח אחסון לדיסק המצורף

1. בודקים אם ה-PVC בשם my-pvc נקשר בהצלחה ל-PV:

   kubectl get pvc my-pvc
   

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

   
   NAME     STATUS  VOLUME                   CAPACITY  ACCESS MODES  STORAGECLASS    AGE
   my-pvc    Bound  pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  2Ti    RWO      storage-pools-sc  2m24s
   

2. בודקים אם נפח האחסון הוקצה כמו שצוין ב-StorageClass וב-PVC:

   gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
   

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

   NAME                   STATUS PROVISIONED_IOPS PROVISIONED_THROUGHPUT SIZE_GB
   pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 READY  3000       140           2048
   

יצירת תמונת מצב ושחזור של דיסקים מצורפים ב-Storage Pools

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

בקטע הזה:

• כותבים קובץ בדיקה לדיסק שהוקצה ב-Pod.
• יוצרים קובץ snapshot של אמצעי האחסון ומוחקים את קובץ הבדיקה מהדיסק.
• משחזרים את ה-snapshot לדיסק חדש באותו Storage Pool, וכך משחזרים את הנתונים שנמחקו.

יצירת קובץ בדיקה

כדי ליצור ולאמת קובץ בדיקה:

1. מאחזרים את שם ה-Pod של פריסת Postgres:

   kubectl get pods -l app=postgres
   

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

   NAME             READY  STATUS  RESTARTS  AGE
   postgres-78fc84c9ff-77vx6  1/1   Running  0     44s
   

2. יוצרים קובץ בדיקה hello.txt ב-Pod:

   kubectl exec postgres-78fc84c9ff-77vx6 \
    -- sh -c 'echo "Hello World!" > /usr/share/data/hello.txt'
   

3. מוודאים שקובץ הבדיקה נוצר:

   kubectl exec postgres-78fc84c9ff-77vx6 \
    -- sh -c 'cat /usr/share/data/hello.txt'
   Hello World!
   

יצירת קובץ snapshot של נפח ומחיקת קובץ בדיקה

כדי ליצור ולאמת snapshot:

1. יוצרים VolumeSnapshotClass שמציין איך צריך לצלם ולנהל את התמונות של נפחי האחסון:

   kubectl apply -f - <<EOF
   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshotClass
   metadata:
    name: my-snapshotclass
   driver: pd.csi.storage.gke.io
   deletionPolicy: Delete
   EOF
   

2. יוצרים VolumeSnapshot ומצלמים את ה-snapshot מהנפח שמקושר ל-my-pvc PersistentVolumeClaim:

   kubectl apply -f - <<EOF
   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
    name: my-snapshot
   spec:
    volumeSnapshotClassName: my-snapshotclass
    source:
     persistentVolumeClaimName: my-pvc
   EOF
   

3. מוודאים שנוצר תוכן של ה-snapshot של אמצעי האחסון:

   kubectl get volumesnapshotcontents
   

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

   NAME                        READYTOUSE  RESTORESIZE   DELETIONPOLICY  DRIVER         VOLUMESNAPSHOTCLASS  VOLUMESNAPSHOT  VOLUMESNAPSHOTNAMESPACE  AGE
   snapcontent-e778fde2-5f1c-4a42-a43d-7f9d41d093da  false    2199023255552  Delete      pd.csi.storage.gke.io  my-snapshotclass   my-snapshot   default          33s
   

4. מוודאים שקובץ ה-snapshot מוכן לשימוש:

   kubectl get volumesnapshot \
    -o custom-columns='NAME:.metadata.name,READY:.status.readyToUse'
   

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

   NAME     READY
   my-snapshot  true
   

5. מוחקים את קובץ הבדיקה המקורי hello.txt שנוצר ב-Pod postgres-78fc84c9ff-77vx6:

   kubectl exec postgres-78fc84c9ff-77vx6 \
     -- sh -c 'rm /usr/share/data/hello.txt'
   

שחזור תמונת המצב של אמצעי האחסון

כדי לשחזר את תמונת המצב של עוצמת הקול והנתונים:

1. יוצרים PVC חדש שמשחזר נתונים מתמונת מצב, ומוודאים שהנפח החדש מוקצה באותו מאגר אחסון (storage-pools-sc) כמו הנפח המקורי. מחילים את קובץ המניפסט הבא:

   kubectl apply -f - <<EOF
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
    name: pvc-restore
   spec:
    dataSource:
     name: my-snapshot
     kind: VolumeSnapshot
     apiGroup: snapshot.storage.k8s.io
    storageClassName: storage-pools-sc
    accessModes:
     - ReadWriteOnce
    resources:
     requests:
      storage: 2048Gi
   EOF
   

2. מעדכנים את הפריסה הקיימת שנקראת postgres כך שהיא תשתמש ב-PVC החדש ששוחזר זה עתה. מחילים את קובץ המניפסט הבא:

   kubectl apply -f - <<EOF
   apiVersion: apps/v1
   kind: Deployment
   metadata:
    name: postgres
   spec:
    selector:
     matchLabels:
      app: postgres
    template:
     metadata:
      labels:
       app: postgres
     spec:
      nodeSelector:
       cloud.google.com/machine-family: c3
      containers:
      - name: postgres
       image: google/cloud-sdk:slim
       args: [ "sleep", "3600" ]
       volumeMounts:
       - name: sdk-volume
        mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
       persistentVolumeClaim:
        claimName: pvc-restore
   EOF
   

3. מקבלים את השם של ה-Pod החדש שנוצר כחלק מפריסת postgres:

   kubectl get pods -l app=postgres
   

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

   NAME             READY  STATUS    RESTARTS  AGE
   postgres-59f89cfd8c-42qtj  1/1   Running    0     40s
   

4. מוודאים שהקובץ hello.txt, שנמחק קודם, נמצא עכשיו ב-Pod החדש (postgres-59f89cfd8c-42qtj) אחרי שחזור הנפח מתמונת המצב:

   kubectl exec postgres-59f89cfd8c-42qtj \
    -- sh -c 'cat /usr/share/data/hello.txt'
   Hello World!
   

   כך מוודאים שתהליך יצירת תמונת המצב והשחזור הושלם בהצלחה, ושהנתונים מתמונת המצב שוחזרו ל-PV החדש שאליו יש גישה ל-Pod.

5. מוודאים שהנפח שנוצר מקובץ ה-snapshot נמצא במאגר האחסון:

   kubectl get pvc pvc-restore
   

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

   NAME     STATUS  VOLUME                   CAPACITY  ACCESS MODES  STORAGECLASS    AGE
   pvc-restore  Bound  pvc-b287c387-bc51-4100-a00e-b5241d411c82  2Ti    RWO      storage-pools-sc  2m24s
   

6. בודקים אם הנפח החדש הוקצה כמו שצוין ב-StorageClass וב-PVC:

   gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
   

   הפלט אמור להיראות כך, עם נפח האחסון החדש pvc-b287c387-bc51-4100-a00e-b5241d411c82שהוקצה באותו מאגר אחסון.

   
   NAME                   STATUS PROVISIONED_IOPS PROVISIONED_THROUGHPUT SIZE_GB
   pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 READY  3000       140           2048
   pvc-b287c387-bc51-4100-a00e-b5241d411c82 READY  3000       140           2048
   

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

העברה של נפחי אחסון קיימים ל-Storage Pool

אפשר להשתמש ב-snapshot ובשחזור כדי להעביר נפחי אחסון שנמצאים מחוץ ל-Storage Pool, אל תוך Storage Pool.

צריך לוודא שהתנאים הבאים מתקיימים:

• ה-PVC החדש pvc-restore מפנה אל StorageClass שמציין את הפרמטר storage-pools, ומצביע על מאגר האחסון שאליו רוצים להעביר את הווליום.
• ה-PV של המקור שממנו מצלמים תמונת מצב צריך להיות משויך ל-PVC עם StorageClass שלא מצוין בו הפרמטר storage-pools.

אחרי שמשחזרים מתמונת מצב לנפח חדש, אפשר למחוק את ה-PVC ואת ה-PV של המקור.

הסרת המשאבים

כדי להימנע מחיובים בחשבון Cloud de Confiance by S3NS , מוחקים את משאבי האחסון שיצרתם במדריך הזה. קודם מוחקים את כל הדיסקים ב-Storage Pool ואז מוחקים את ה-Storage Pool.

מחיקת דיסק האתחול

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

למידע נוסף:

• שינוי הגודל של מאגר צמתים.
• מחיקת מאגר צמתים
• מחיקת מקבץ

מחיקת הדיסק המצורף

כדי למחוק את הדיסק המצורף שהוקצה ב-Hyperdisk Storage Pool:

1. מוחקים את ה-Pod שמשתמש ב-PVC:

   kubectl delete deployments postgres
   

2. מוחקים את ה-PVC שמשתמש ב-StorageClass של Hyperdisk Storage Pool.

   kubectl delete pvc my-pvc
   

   מוודאים ש-PVC pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 נמחק:

   gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
   

מחיקת Hyperdisk Storage Pool

מוחקים את Hyperdisk Storage Pool באמצעות הפקודה הבאה:

gcloud compute storage-pools delete pool-us-east4-c --zone=us-east4-c --project=my-project

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

• אפשר לעיין במאמר בנושא פתרון בעיות באחסון ב-GKE.
• מידע נוסף על Persistent Disk CSI driver ב-GitHub